Feature request: allow mev-geth to accept full blocks

[thegostep]

Accepting full blocks would allow to move some of the computational heavy bundle merging off of the miner's node, thus saving resources.

The implementation is potentially very simple: create a new rpc called eth_proposeBlock which accepts a block header and transaction array, validates the block, and inserts it into the the multi-worker which is in charge of profit-switching.

Issue: flashbots/mev-geth#34

[thegostep]

v0.2 proposal

v0.2 adds a new method to mev-geth for accepting a block header and transaction array, validates the block, and inserts it into the multi-worker in charge of profit-switching. This method would be restricted to being used by the flashbots relay for the duration of the alpha, and will allow experimentation around moving some of the extra computation required for bundle merging off of the miner's node.

This feature will allow to eventually reintroduce the ability to pay for the bundles using gasprice.

[thegostep]

v0.4 proposal

mev-geth currently has a single rpc method for bundle submission, eth_sendBundle. This rpc makes use of a bundle scoring function and multi-worker architecture to generate blocks with multiple bundles and compare them for profitability. However, the scoring function used is known to have a bias for smaller bundles.

This proposal brings back a feature excluded from the v0.2 release which provides the ability to insert large bundles directly into the multi-worker architecture. eth_sendMegaBundle would effectively be an implementation of full block scoring. Megabundles will help experiment with new approaches to bundle scoring and bundle merging and produce more profitable blocks for the miners while also increase the inclusion rate and the ability for searchers to land large bundles.

Because producing a full block for every bundle is a computationally expensive task, the relays are expected to send very few mega-bundles every block. To help the miner manage the load, mev-geth will have a new config parameter megabundlerelays which accepts an array of addresses. This allows for a separate worker to be dedicated for the verification of bundles from each relay. For performance reasons, the number of relays being accepted should be kept to a minimum and not exceed the number of cores on the machine.

mev-geth makes the assumptions that a relay only sends an updated megabundle if it is more profitable than the previous bundle. As such, mev-geth only retains the latest bundle received and the bundle currently being processed. To process a bundle, mev-geth builds a block with the megabundle at the top, and the remainder filled with transactions from the txpool. The block is then inserted in the multi-worker in charge of profit-switching. It is TBD if megabundles will provide elements of the block header.

Discussion: #52