EPF - Second Update

In my initial update I briefly talked about the beginning of my research. Some of it was getting up to date with the Eth PoS structure and the Consensus Layer and MEV in this new stage of the protocol.

This update will be entirely focused on MEV, how it’s structured, what has been done until now and what issues are still to be worked on.

MEV In Ethereum PoS

Some Ethereum PoS aspects that differ from Ethereum PoW:

• The PoW Ethereum Blockchain no longer manages consensus. It is now called Execution Layer (EL), it processes blocks, maintains transaction pools, and manages and sync state. If you run an EL client and stake 32 ETH, you can become a validator.
• It has been merged with the Beacon Chain, which handles PoS consensus. The Beacon Chain clients track the chain’s head, gossip and attest to blocks, and receive validator rewards.
• These two chains run concurrently, with their own networking stack.

And, what is MEV?

MEV (Maximal Extractable Value) is all the possible value that can be reaped by a block proposer from the re-ordering, censorship or insertion of transactions within the block they are proposing.

MEV comprises a much higher share of validator rewards since staking issuance is far lower than the inflation that was given to miners. In any case, since the EL handles transaction ordering, Why shouldn’t MEV be the same as in Eth PoW?

After the merge, there are no more mining pools, so the best for the protocol would be that at-home validators are able to operate effectively, instead of hedge funds capturing all the MEV, for being able to perform complex strategies. This would centralize the validator set.

A possible solution to this is the proposer/builder separation.

Proposer/Builder Separation (PBS)

The exact PBS implementation is still being discussed, but the main ideas are:

• Block proposers rely on a market where outside actors (block-builders) produce bundles consisting of complete block contents and a fee for the proposer.
• The block proposer chooses the bundle with the highest fee (simple algorithm).

PBS will eventually be implemented in-protocol, but for the time being we rely on mev-boost, a solution built by Flashbots in collaboration with the Ethereum Foundation and client teams, aiming to be a neutral infrastructure.

MEV-Boost is a new middleware in which validators can sell their blockspace to not just Flashbots but other builders as well. This opens up the market to more builders and creates competition between them, leading to more revenue and choice for validators, and better censorship-resistance for Ethereum.

While it is estimated that in-protocol PBS to be ready in ~2 years, mev-boost can serve as an interim solution. However, this structure could still lead to centralization.

Builder Centralization

A block builder needs to win the mev-boost auction to have it’s block selected and earn the rewards. To win the auction and still be profitable, the builder should have the highest-fee transactions included, but that’s up to the MEV searchers to provide them to it.

Searchers run complex algorithms on blockchain data to detect profitable MEV opportunities and have bots to automatically submit those profitable transactions to the network. The searchers will send the bundle to a block builder with high chances to win the auction, or that has been winning past auctions frequently. This creates a positive feedback loop for the builders, receiving more transactions than their peers and keep out-bidding them.

This centralization could lead to censorship or other forms of economic exploitation. Two possible solutions to builder centralization can be seen in this post, which are:

• Inclusion Lists: a proposer provides an inclusion list, a list of transactions that they demand must be included in the block, unless the builder can fill a block completely with other transactions.
  
• Proposer Suffixes: the proposer creates a suffix for the block. The builder would see no information about the proposer’s intentions when they build a block, and the proposer would be able to add to the end any transactions that the builder missed.
  

Conclusion

It’s clear that MEV is a topic that should be taken into account in the design of the protocol. The issues it could have though, are not tied to MEV-Boost or PBS not being implemented in-protocol, so even if that’s not the case and we’re working with a temporary solution, there are still improvements being worked on today that could eventually take place when the protocol implementation is built.

References

• https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725
• https://ethresear.ch/t/two-slot-proposer-builder-separation/10980
• https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers
• https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177
• https://simbro.medium.com/mev-driven-centralization-in-ethereum-ec829a214f18
• https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/
• https://writings.flashbots.net/why-run-mevboost/
• https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance
• https://github.com/ethereum/builder-specs
• https://github.com/flashbots/mev-boost-relay