3 Reasons why the MEV Problem is a Protocol Designer’s Dream Nightmare

and what we are doing about it

Julian Ma

Robust Incentives Group, EF

Reason 1: MEV has many effects

• Protocol Side (Consensus Security)
• Returns to sophistication encourage validator centralization
• Spikes in MEV encourage staking pools
• High MEV blocks encourage re-org attacks
• MEV encourages timing games
• User Side
• Users getting extracted might not return
• Many different forms of users and extraction

​

How does one credibly neutral protocol address all of these problems?

Reason 2: Limits of the protocol

• The protocol can only protect what the protocol can see
• We don’t have consensus on anything else than the canonical chain
• Mempool
• Block ordering
• Timing games
• Additional consensus tasks complicate the protocol

From Seeing like a protocol by Barnabé Monnot

Reason 3: To enshrine or not to enshrine?

• Enshrining some version of PBS (ePBS) on-chain is possible
• But, is this the optimal mechanism?
• PEPC (Protocol-enforced proposer commitments)
• Partial vs whole block
• Block vs. slot auctions (my research)
• FCFS ordering
• Protocol upgrades take time and are difficult to undo

​

The option to enshrine is worth something! (The nuclear button)

What are we doing about it?

The current state of affairs

• No mempool or ordering sequence consensus
• Validators can insert, reorder and censor transactions for MEV profit
• MEV-boost allows all validators to reach same amount of sophistication

Effects

✅ Preserve decentralization of validator set

❌ Solve user side of MEV and introduces trust assumptions about the relay

“We get a chain where block production is still centralized, but block validation is trustless and highly decentralized, and specialized anti-censorship magic prevents the block producers from censoring” - Vitalik (Endgame Post)

Enshrined Proposer-Builder Separation (ePBS)

• Fundamental idea: remove responsibilities from the relay
• Possibility: go through iterations of the Optimistic Relay (Mike Neuder and Justin Drake) proposal to gradually remove relay responsibility by slight modifications to MEV-boost

Effects

✅ Remove relay trust assumptions and decrease latency for block submission

✅ Enable further protocol development that put more load on block production while keeping validator set decentralized

Note: not all latency reductions are made equal!

User side of MEV

• Order Flow Auctions: searchers could compete to execute user transactions by rebating MEV to the user
• Shifts the monopoly position from the validator to the user
• MEV Aware Applications: applications can be designed in such a way as to minimize the MEV exposed, e.g., CoWSwap
• Protocol Solution: Only reveal block contents when block is canonical through encrypted mempools

Effects

✅ Users do not get extracted from as is currently the case

❌ Pushing user MEV solutions to application layer provides fewer guarantees

Consensus bids: who receives the MEV

• Even with all this, there are still incentives for staking pools, re-org attacks and timing games
• Consensus bids form a potential solution: force the validator to choose highest PBS bid and then smooth this bid out over next N validators (MEV smoothing) or burn it (MEV burn)
• MEV burn also means validators do not get MEV reward anymore, hence protocol pays less for security and can use leftover MEV for fiscal policy

✅ Tentatively, this reduces or removes all of the abovementioned incentives

❌ Philosophical question: makes validator a ‘dumb-pipe’

Cool features we can get along the way

• Block vs. Slot Auctions
• Cross-domain “atomic” transactions
• Reducing execution uncertainty through latency reductions
• Inclusion lists
• Reduce incentive to censor by allowing validator to build a partial block
• The “anti-censorship magic” Vitalik mentioned
• Incentives are uncertain, currently under study

​

Cool features we can get along the way

• Block vs. Slot Auctions
• Cross-domain “atomic” transactions
• Reducing execution uncertainty through latency reductions
• Inclusion lists
• Reduce incentive to censor by allowing validator to build a partial block
• The “anti-censorship magic” Vitalik mentioned
• Incentives are uncertain, currently under study

These examples turn the MEV problem nightmare into a protocol designer’s dream

​

Thank you!

Julian

Robust Incentives Group, EF

julian.ma@ethereum.org

@_julianma