Improve Tx submission: handling evictions

[cmwaters]

Summary

The tools we provide users to assist in tx submission has come a long way and we're starting to see a more production grade system that can be relied upon by rollup sequencers or RaaS providers.

As to date, we now have:

• Local tracking of nonce to allow multiple transactions in a single block
• Multiple accounts so a single light node can submit on behalf of multiple rollups
• A TxStatus endpoint that is more lightweight and gives us more information on the lifecycle of a transaction [In progress].

Problem Definition

There are still a few missing areas where we can improve robustness. One important one is handling evictions which cause nonce mismatches for an entire batch of transactions. We also can't rely on the consensus node we submit to for the new nonces because they could lie and cause us to break replay protection.

Proposal

What I'm proposing is a little more elaborate. Some of the ideas I took from maelstrom which focused a lot on reliable tx submission. Essentially, the txClient needs to have a small pool (like a mempool) that tracks the transactions over their lifecycle and only discards them once they have been confirmed on chain. As transactions can potentially live forever, all transactions must have a TimeoutHeight which defaults to 5 blocks above the current height. That way as we track the blockchain we can always reach a conclusive result as to whether a transaction has failed or been successful. I propose a default of 5 that can be configured by the user.

Now, when it comes to handling nonce mismatches, if the client knows all the unconfirmed transactions they have submitted, they can replay the transactions that they have signed to the receiving node up to the current transaction. If a transaction is evicted or times out, the other transactions can all have their nonces update accordingly (they may also need to wait past their expiration date to avoid double execution). Having the user set the expiration time also allows the user to resubmit sooner with a higher fee (although I think pricing holistically should be solved elsewhere).