MEV Stealing Proofs

This section looks at the potential of proving MEV stealing with the help of the beacon block root proposed in EIP4788. It appears to be possible to provide merkle proofs against the beacon root to objectively determine how MEV was handled in a block.

Data and Proofs

The beacon block root would give access to:

• The proposer_index contained in the BeaconBlock itself

• validators in BeaconState linking indices to pubkey and withdrawal_credentials

• fee_recipient, transactions, and state_root contained in the ExecutionPayload in BeaconBlockBody

With that it would for example be possible to prove that:

• a block was produced by a specific validator index (using the proposer_index)

• that validator index belongs to a specific minipool (using validators)

• the node operator owning that minipool was opted in to the smoothing pool for that block (using the state_root)

• the fee_recipient wasn't the smoothing pool

• the last transaction in the block did not transfer ETH to the smoothing pool (using transactions)

Proofs like that could be the basis for a trustless fraud proof system: Instead of relying on trusted oracles to monitor MEV stealing, anyone can prove stealing on chain and trigger a penalty to be applied. The limitations on beacon chain withdrawals serve as a challenge period (see Fraud Proof Challenge Period). However there are limitations what rules can be verified in this manner.

Ruleset

Loose

This is effectively the Phase 2 ruleset currently in place and the one suggested in the new penalty system draft: A block can come from one of the trusted relays or can be built locally as long as the correct fee recipient is used.

This rule set could be implemented with the beacon root and a way to link validator indices to pubkeys: To show that a penalty should be applied, a proof could be provided that a block did not use the smoothing pool or the node fee distributor and the last transaction in the block did not go there either.

However this version is vulnerable to node operators running their own searcher and extracting MEV without sharing it.

Middle (currently proposed)

The current plan for MEV is to eventually require MEV Boost in Phase 3, but allow local block building if relays don't produce a block. With a trusted oracle, it would be possible to query relay APIs to determine if a MEV boost block was available for a certain slot and detect NOs that build their own blocks instead.

With purely on chain data, it would not be possible to distinguish between a block that was legitimately built locally because no MEV boost block was available and those that ignored relay blocks to sidechannel MEV.

Strict

Only blocks from trusted relays are allowed. If none are available, the node operator must not propose a block. Locally built blocks that set the fee recipient to smoothing pool or node fee distributor are no longer allowed.

Just as above, this one could be implemented on chain in a post EIP4788 world by providing a proof that the last transaction did not go to smoothing pool or node distributor.

This version would introduce a strong dependency on MEV Boost and might lead to slightly lower returns because of missed blocks.

Both the loose and the strict rule set are far from ideal. One approach would be to implement both and give the pDAO the ability to switch between the two with a settings change. We could start out with using the loose one and continue to monitor if anyone is exploiting the system and switch to the strict rule set if necessary. The ability to switch might serve as a deterrent in and of itself.