Feature request: bundle merging

[thegostep]

In the current implementation there can only be one bundle included per block.

This means bundles that need to be at the top of a block compete with bundles that do not need to be at the top of a block.

Merging multiple bundles per block could significantly increase searcher hit rate and miner profitability.

A simple proposal would be to add a boolean field in the flashbots bundle request that specifies if the bundle can be merged / included after other bundles.

[Code0x2]

Yes please lol, its a pain when you're tryna send a bundle totally unrelated to somebody elses and they get included and kicks you out.

[fifikobayashi]

How would the final miner payment logic look like for a multi-bundle? Would it still be 'pay miner via block.coinbase if all the preceding TXs from all searchers in the bundle succeeds"? And if one Tx fail, the entire bundle fails?

If so, hoping we can have some meaningful ways of troubleshooting who's the culprit so we don't have to needlessly pull apart our own code thinking it's reverting due to something on our end.

Having said that, the most likely culprit to cause the whole bundle to revert will probably be me...

[Code0x2]

I think bundles should be sent the same way they are now, but on the node side have it loop through the bundles to see if it can be added (boot out if already included/nonce too low, or if reverts), and add if the gas price is higher than the tailing price

[thegostep]

v0.2 proposal

In v0.1, at most a single bundle was included in a block. In v0.2 we implement bundle merging whereby many bundles can coexist in a block. The merging of bundles is done at the MEV-geth level, using the following algorithm.

What this procedure does is, after sorting the bundles by their "raw" scores as obtained when applied at the head of the block, applies the most profitable one and checks whether the "corrected" score after this application for the following one is above a certain threshold. It includes it as the next bundle if it is, discards it if it isn't, and continues with the iteration. This finally produces a candidate block, which is filled up with regular transactions according to their gas price. As in v0.1, the candidate Flashbots block is ultimately compared with the vanilla geth block for miner profitability.

The chosen threshold is taken as $g_{tail}$, the gas price of the last included transaction in the prior block. This serves as a heuristic for cheaply assessing bundle profitability, as it would be prohibitive for us to compute the actual block profit for all possible bundle orderings. Asking for the corrected $q$ for the bundle to be as high as the original score would be too restrictive, as bundles can still yield significant profit without satisfying this condition. On the other extreme, asking simply for $q\geq0$ would result in a large number of Flashbots blocks losing out to their vanilla geth counterparts. The chosen threshold is an intermediate setting that ensures miners are compensated for the opportunity cost of including the bundles as opposed to regular transactions[^1].

Finally, we note that for $n$ bundles, this algorithm entails an extra $n-1$ simulation rounds on top of the $n$ already required for initial scoring. We believe that the delay introduced is small enough to avoid any significant increase in miner uncle rates while significantly increasing profits per block, which we will test before releasing the update.

ref:

[MicahZoltu]

I think you'll get a much bigger win at much lower cost by simply fixing the bundle profitability algorithm. By having an incentive compatible profitability algorithm you will incentivize searchers to actually bundle themselves rather than the current optimal strategy which is to submit multiple bundles, one for each opportunity the searcher fines. The current profitability algorithm not only discourages submitting multiple bundles, but it also discourages devoting R&D into actually finding second tier opportunities because it is more valuable to get my best opportunity included (optimize that code path) than to find lesser opportunities that will just be beat out by my own primary opportunity.

MVP Proposal

For each submitted bundle, build and execute a full block, filling it from the pending pool like normal. Compare the total coinbase balance at the end of each simulated block to determine which bundle is most profitable.

If you also want to add bundle merging, you can use the output of this profitability algorithm as the input for the aforementioned merged block construction.

v2 Proposal

You could further offload this work to searchers by having them submit their bundle with some additional metadata and a bond:

• bundle_transactions: full transactions that are important to the searcher
• stuffed_transactions: transaction hashes for transactions pulled from the mempool and used to fill out the block
• parent_state_root: the state root of the block that this bundle should be an immediate child of
• bundle_coinbase_reward: the coinbase balance change after executing bundle_transactions
• total_coinbase_reward: the total coinbase balance change after executing bundle_transactions + stuffed_transactions
• signature: signature over above data and an attestation that parent_state_root + exec(bundle_transactions) + exec(stuffed_transactions) yields total_coinbase_reward and parent_state_root + exec(bundle_transactions) yields bundle_coinbase_reward. If the attestation is proven false, then the recovered address has its bond slashed.

The bundle merger can then spot check or lazily check (not inline) that searchers are not lying about the coinbase_reward field and thus can avoid having to execute anything prior to constructing the merged bundle. The merger can focus on deduping transactions in the bundle_transactions and sorting by profitability (total_coinbase_reward) and filtering out bundles that fail to achieve their profitability target when included not-at-head.