Nonce management strategies

[meetmangukiya]

Wondering if this is something we can build into this lib and also ignite some discussion around the same.

What is the nonce management strategy that you are using with flashbots? When I think about it there are some challenges:

1. If you discover multiple opportunities / bundles to send at same block, if you set nonces x, x + 1, if x bundle doesn't get included because a conflicting bundle outbid, then x + 1 won't be a valid bundle because correct nonce for next tx to land on chain would be x.
2. If your bundle don't gets included you have to either keep retrying(but only if the bundle is still valid, so maybe there even needs some way to check if the opportunity still exists), again the nonce problem remains, more bundles may have landed in your queue and you would need their nonces to be correct and land in same order.

I think the simple fix here is:

1. Use multiple EOAs, so if you have 10 EOAs, you can at max have 10 bundles you can keep trying, so a queue with number of EOAs equal to servers and everything more than that falls in the queue, which maybe limiting because the ones in queue may be non-competitive and could've landed in first try, etc. Multiple EOAs are not ideal because now you'd need to have more complicated RBAC auth on chain.

The middleware for the above alternative would probably queue bundles whenever send_transaction or send_bundle gets called? Watch for blocks and every new block, check if any previously sent block got confirmed and remove them from queue if they did, check if the tx is valid(maybe closures? or just drop this for now), set relevant nonce and sign them with nth EOA and submit all of the bundles. Repeat.

[onbjerg]

This library does not currently do anything about nonces. We just assume that you provide a nonce, or have another middleware that does that.

I don't personally use the library currently, so I can't chip in much on a nonce management strategy, but my 2 cents is that bundles can contain multiple transactions, so the nonce management strategy is really up to the end user. I think it could make sense to provide some middleware that implements a couple of common cases, but as mentioned, there is no guarantee that a bundle contains just one transaction.

I'll think more about this and loop back once I have some more time. I'm curious to hear if others have thoughts on this in the meantime.

[rkrasiuk]

Use multiple EOAs, so if you have 10 EOAs, you can at max have 10 bundles you can keep trying, so a queue with number of EOAs equal to servers and everything more than that falls in the queue, which maybe limiting because the ones in queue may be non-competitive and could've landed in first try, etc. Multiple EOAs are not ideal because now you'd need to have more complicated RBAC auth on chain.

@meetmangukiya There is no easy solution for parallel bundle submission because you have to either submit them with conflicting nonces or optimistically increase it. One improvement that I can suggest is retry + fanout for next n blocks for a single signer & nonce combination. Given a single opportunity, the implementation would be the following:

1. Lock the signer and get its current nonce
2. Get the base fee for the current block number x and calculate the max base fee for the range {x, x + n}
3. Populate transactions with calculated base fees and locked nonce
4. Sign n bundles and submit them
5. Retry, if all failed

I agree though that it seems out of scope of this package.