Idea: Making transaction nonce checking more flexible

[MitchK]

I hope this is the right place to discuss the feasibility of an idea that could improve performance and reliability of applications and services writing data in high frequency to the Blockchain.

We are currently working on a service where we write hash values in a storage smart contract on behalf of users (document notarization use case).

The problem that we are currently facing is that because of our transaction volume and the transaction pool limits, we have to cache and queue signed transactions. It occasionally happens that one transaction in the sequence is non-executable for various reasons (e.g. gas price too low). This means that all following transactions will not go through either and have to be signed again by the issuer. We managed to automate this process, but it creates too many moving parts for us.

It would be great if transactions of an account could be optionally executed without the nonce checking. This obviously creates the risk of replay attacks. But what if a transaction is fully idempotent, such as simply setting a variable in a contract to a value?

A possible way of doing it (but not sure if it would work) could be to set the transaction nonce to a static value "implicit", meaning, that the number of the transaction could be derived from a previous transaction and/or determined by the miner (probably necessary if more than one "implicit" transactions would go into a block.

Another way could be to make use of account abstraction, as proposed in #86 and #208. The transaction sender could then perhaps define his own rules to validate the transaction and (hopefully) under awareness of possible consequences, can disable nonce checking.

Assuming the transaction itself is fully idempotent, the only risk that I see is that an account's Ether balance could be depleted accidentally. I would however see the developer of the Dapp in the responsibility to make sure that this can't happen.

[nicksavers]

Bitcoin has something called Child Pays For Parent (CPFP) - That could work by adding it into miner software and as an option for the users in wallets. Basically you'd send a new transaction with nonce of the unconfirmed transaction + 1 and pay a higher gas price that pays for both. Miners will see the new transaction and include both in a block to receive a reward. It might be a bit tricky for code executions, because it's not easily calculated whether the price covers the parent without running the transactions.

[shrugs]

Not sure if the ETH protocol requires that nonce must be prev + 1 or whether it allows nonce to just be > prev. But it may be possible to sign nonces "10", "20", and "30" and then if one fails you only need to sign a single transaction as "11" instead of all of them (assuming correct order).

[MitchK]

It actually allows you to submit a transaction prev + 2 but it will stick in the transaction pool and will not be mined until prev + 1 was submitted and mined. Transactions that stick in the transaction pool for too long will eventually time out.

[shrugs]

Gotcha, so not a real solution, then. Taking myself out of the convo 😄

[nateawelch]

You can always just resubmit a tx with the same nonce with a higher gas price to get it mined faster. Nodes will only keep one in the transaction pool, and they'll favor the one with a higher gas price.

[MitchK]

@flygoing That's true! However, how would you detect that I need to overwrite a nonce? Wouldn't I need to wait for some time? And wouldn't I lose a transaction?

[nateawelch]

If the tx isn't mined yet, get the estimated recommended gas price and if estimated time for the pending tx to be mined is longer than you'd like, replace it. What do you mean "lose a transaction"? You can replace the tx with only the gas price differing.

[golra03]

@flygoing, we are also facing the same problem. As mentioned, we can submit the transaction with same nonce. Question is, what is the safest way at the application level to identify whether some transaction is missed or not? so that we can resubmit it.
We are thinking about wait for event triggered per transaction but making it full proof is the challenge. Any comment?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.