Thread by @lightclients

After the merge, there will be a much larger faction of "at home" block producers than we've seen under proof-of-work. In order for these independent stakers to extract MEV, we need to think differently about our approach to block production (thread).

First, let's recap how MEV is extracted today.

There are many actors in this game, but we can roughly distill the interaction down to three: searchers, builders, and miners.

The searcher's goal is to extract MEV from txs. When they find a vulnerable tx, they package it with their own tx that does the extraction. This bundle is often referred to as a "fragment". The searcher sends their fragments to the builder to be aggregated.

The builder aggregates the fragments into a block. This provides a layer of DoS protection for the miner. The miner could do the building themselves, but allowing this to be a specialized role means the builder can focus on providing good service to searchers and users.

Once the builder has produced a block, it forwards the block to the miners who can create a seal for the block (e.g. mine it).

The system ends up looking something like the diagram below. Imagine also that multiple builders are providing this service in parallel.

That's roughly what MEV extraction looks like today. Searchers send txs to the builder in plaintext, builders send blocks to the miner in plaintext, and the miner extends the chain. Each actor trusting the next actor to not steal their MEV.

This is more-or-less works today. Searchers tend to have a 1:1 relationship with builders, so it's straightforward to know if a builder is stealing searcher MEV. Builders are incentivized not to do this, because they could quickly lose business if they are suspected of theft.

Builders/miner relationships are typically one-to-many. This makes it more difficult to track theft, but there are still plausible solutions (see: iterated games). We accept this, because builders are sophisticated and should be able to combat adversarial miners.

Stealing MEV could also be extremely detrimental to mining pools' profits, because they risk being blocked by builders. MEV is a non-negligible portion of their revenue, so that will directly result in reduced earnings.

It will be interesting if, as we approach the merge, miners will become more hostile to builders. The expected value of the relationship will continue to decrease as the transition closes in. This would be a more realistic scorched-earth policy than previously anticipated.

And this is really the crux of the transition. Post-merge, there will be many more entities proposing blocks than today (just a few pools vs. thousands of validators) - meaning - builders have many relationships, but of lower value.

This becomes a problem when the MEV in a block is worth more than the relationship a validator has with a builder. If the relationship is worth X over the next 5 years and the MEV in the block is worth 2X, the validator could get 10 years of returns in a single block!

Builders will almost certainly not allow themselves to get in this situation, so the most likely outcome is that small validators will not be eligible to get MEV blocks. This will lead to large validators earning more proportionally for their stake than small validators.

This is not a desirable property. Fortunately, we can fix this. The long-term solution is in-protocol proposer-builder separation (PBS). However, this is a problem immediately after the merge. PBS is still under research & development. We need an interim solution.

The interim solution is the External Builder Protocol. It flips the trust assumption from validators not stealing to builders not withholding data. This subtle difference allows for constructions where the validator blindly signs the block w/o seeing the underlying txs.

The full exchange would look something like this:

There is a bit more setup that I've omitted for simplicity, but basically the validator needs to register with the builder their fee recipient address and preferred gas limit.

You can find the full list of endpoints at ethereum.github.io/builder-specs/ (see screenshot below).

This also isn't even the full picture. The protocol only describes a direct communication between the validator and builder. Whereas it's actually expected that validators will use additional software (see: mev-boost) to multiplex the communication with many builders.

The full interaction, including mev-boost, actually ends up looking more like the diagram below. Roughly the same as the 1:1 relation, but with the flexibility to interact with many validators.

You can find the two mev-boost implementations here:
* github.com/flashbots/mev-…
* github.com/ralexstokes/me…

This scheme gets the job done, but it isn't perfect. If you recall, we flipped the trust assumption from the validator to builder. So the question is: how does this protocol break down when a builder breaks this trust?

In this case, the validator signs the blinded beacon block and sends it to the builder requesting the full block. The builder can withhold the information and say "they didn't receive the request". There is no way to attribute the fault to either party.

This causes the validator to unduly lose out on the revenue from producing a block in their slot. What's worse, they have no recourse because the fault was not attributable.

A possible workaround that is still under research is using a bonded committee to attest to the availability of protocol message. Combine this with an unconditional payment from the builder to make false-negatives unprofitable and now the system is a bit more robust.

There is still a lot more work to be done to make the external builder protocol + mev-boost robust in the interim. I recommend following #block-construction on the Eth R&D discord or the github.com/ethereum/build… repository for the latest information.