[builder] Handle "replacement transaction underpriced"

[dancoombs]

Describe the feature The following can happen:

In round 0:

• Rundler submits a bundle transaction (Tx0) with (maxFeePerGas, maxPriorityFeePerGas) = (A, B)
• Gas price moves, and Tx0 is now underpriced
• Rundler tries to build a new bundle by increasing (A,B) , but it prices out all UOs in the mempool.
• Rundler gives up the current round of processing.

In round 1:

• Bundle transaction (Tx0) is still pending
• Rundler estimates fees at (2A, B) (i.e. the base fee moved considerably)
• A UO has been submitted that pays sufficient fees
• Rundler tries to submit a bundle transaction at (2A, B). However this fails because maxPriorityFeePerGas hasn't been increased by 10%.

This situation needs to be handled.

Potential steps:

• Remember submitted transactions, even across rounds of processing, such that we never submit a UO that doesn't have a price at least 10% higher in both dimensions.
• However, we can get in the scenario where base fee has gone up, but priority fees have gone down (rare, but can happen). Thus submitted UOs are unlikely to have a high enough priority fee to be part of the resubmitted bundle transaction. Thus we can't build a valid replacement bundle transaction that contains UOs.
• At this point, the only valid thing to do is "cancel" the pending transaction by submitting a zero value transaction with higher fees.

This is complicated by:

1. We can't always know what fees are needed to replace, especially across restarts. The eth_ API doesn't have a way to query the fees of a pending transaction (why not?).
2. This cancellation transaction will charge fees, unless using an RPC that supports cancellations, like flashbots.

How this works on various networks:

Arbitrum: not a problem, no priority fees Ethereum: use flashbots cancelations Optimism/Polygon: pay for cancellation (is there something else we can do here?)

[0xfourzerofour]

I think we should look further into how reth deals with this information within the pool. They separate ops in the pool based on different transaction statuses. e.g ones that are prices too low, ones that are pending etc. This would mean that we would not need to loop through everything in each round of processing and a different process can manage the bundle sending, overall I think that could speed up our bundle submission.

https://github.com/paradigmxyz/reth/blob/main/crates/transaction-pool/src/pool/txpool.rs#L63

Here they hold a constantly updated map of ops that are currently violating the dynamic fee requirements and need external updates to move into the pending block

[dancoombs]

This specific problem is not applicable to Reth. The issue is that we need a way to cancel bundles if our bundles don't land right away and they are blocking us from sending new bundles.

This generally isn't possible on most chains, so we may need to send a single transaction that flushes our bundle from the pool.