Bundle merging

TL;DR + code script: https://gist.github.com/taarushv/36f783aea9b28a725c5f5300d27f926a

Note: Just thinking outloud with this, probably missing a bunch of improvements/probable attack vectors, do comment and lmk!

Goals:

• Enable pursuit of multiple MEV opportunities within the same block. For example, if there's a position on aave that can be liquidated and an arbitrage opportunity on ETHUSD across DEXs, currently searchers can send two bundles to the relay but only one of them will be chosen and mined based on the seal bid. The other opportunity could persist to the next block and be captured by the next miner or it could simply be sniped by a tx in the same block but originating from the regular TxPool.
• Create two classes of bundles
  • bundles that indicate that they would like to be on the top of the block (and bid appropriately) or be pruned/rolled over if they don't get that index
  • bundles that are fine with being included at any index (with the assumption that they'll revert if the opportunity doesn't exist anymore)
• Create a block template without n! operations to find the most profitable combination.
• Handle cases such as MEV opportunity no longer being available due to bundle in the previous index of the block taking it + multiple bundles using the same transactions within (such as a sandwich tx) + bundle opportunity no longer being profitable due to say natural change in pool reserves etc gracefully.
• Preserve fairness (?) by ordering with optimizing max revenue for miner at every step in mind (net profit w/ merging > net profit w/o merging > net profit w/ vanilla geth)
  • i.e if there are 5 bundles but 2 of them have net gasPrice less than that of the top 2 txs in the public txPool, the order in the block should be first 3 bundles sorted by gasPrice, first 2 txs of the public txPool, and then the other 2 bundles should be placed appropriately based on their gasPrice relative to other txs in the mempool.
  • to put it another way, a bundle shouldn't be prioritized or subsidized over a higher paying tx in the public mempool solely because of merging (unless we find a way to optimze and check to see if ordering all or few bundles in a particular way adds more net profit to the miner)
  • what happens if 2 bundles are mutually exclusive (say pursue the same liquidation) and pay the exact amount in bribe to the miner? FIFO based on time tx was seen by client, just like geth

How does it work?

Example (all units in gwei, assume block limit is 100k)

• Let's say we loop over all the bundles to calculate their effective gas price, we also Peek to get the highest paying tx in the public mempool.
• We then use that as a reference as we loop over the bundle net gas fee and start constructing the block template.
• We have a gasUsed counter to ensure we break out of the loop once we hit the gasLimit (why the 0.1 and 0.25 gwei txs are excluded from the final block)
• If we encounter an instance where the bundle pays less than the top tx, we insert the top tx and keep looping.
• Note: while adding bundles, we ensure it does not try to add the txs already used by other bundles by ensuring coinbase reward goes through (which would not happen if the MEV is taken by a bundle or a higher paying tx in the local mempool that grabs the op).
  • It seems counterintuitive to give access to txs from the public mempool over other bundles while merging but my thinking is that a) the opportunity will still exist unless the other local txs ahead pursue it b) at which point the miner doesn't care who pays them for the MEV
  • High gas txs are unlikely to disrupt sandwich attacks even if they get a better index, assuming the searcher uses %'s to dynamically calculate prices + miner bribe.
  • ^Need to think how this'll play out more, esp with malicious spam etc.
  • This pattern intuitively seems like it'd allow multiple bundles (that pursue MEV, meta txs that go from ERC20=>ETH w/o gas, and other abstract relayer protocols that might use flashbots) seamlessly.

• Before we start new work, we check to see if the profit of this ordering is > profit w/o merging (>> profit w/o bundles), also make sure tx that insisted on #1 index either got it or disregarded if they bid too low.

• Converting above example into vars + running them through the merging algo returns: