Exploring the Relationship Between MEV-Boost and Ethereum's Consensus Mechanism

On April 2, a malicious attacker exploited a vulnerability in a certain relay platform to steal 20 million dollars. In the following days, developers released multiple patches to fix the issue, but combined with network latency and validator strategies, it resulted in a brief instability in the Ethereum network on April 6. Chain reorganization can reduce block production rates and settlement guarantees, which is detrimental to network health.

This article aims to explore the interaction between MEV-Boost and the Consensus Mechanism, revealing some subtleties in Ethereum's proof of stake, and listing possible directions for improvement.

Introduction to MEV-Boost

MEV-Boost is a protocol designed to mitigate the negative impact of Maximum Extractable Value ( MEV ) on the Ethereum network. It includes three roles:

• Relay: A trusted intermediary that connects proposers and block builders.
• Builder: A complex entity that constructs blocks to maximize MEV.
• Proposer: Ethereum PoS Validator

The general process of MEV-Boost is: builders create blocks and submit them to relays; relays verify the blocks and calculate the payment amount; proposers choose the highest bid and sign; relays publish the blocks and distribute rewards.

MEV-Boost is an important infrastructure because it allows all proposers to fairly access MEV without establishing a trust relationship with builders, which is beneficial for the long-term decentralization of Ethereum.

Ethereum's fork choice rule

The fork choice rule determines how the network reaches consensus on the chain head. Its relationship with time has a significant impact on block production.

Ethereum PoS divides time into 12-second slots. In each slot, a validator is randomly designated as the proposer, while other validators vote to support the chain head. Each slot is divided into three 4-second phases, with the proof cutoff time at t=4 seconds being the most critical.

From a network health perspective, the optimal block release time is t=0. However, since the value of the block increases over time, proposers are incentivized to delay the release to capture more MEV.

To encourage timely releases, the "proposer boost" and "honest restructuring" mechanisms have been introduced:

• Proposer Boost: Grants the proposer a fork choice boost equivalent to 40% of the proof weight, lasting for one slot.
• Honest Restructuring: Allows honest proposers to force the restructuring of blocks with proof weights below 20%.

Repair of Relay and Beacon Nodes

After the attack on April 2, the relay and core development teams released multiple patches:

1. The relay checks for malicious proposers, whether the block has been published, and introduces random delays.
2. The beacon node verifies the validity of the block and checks if there are equivalent blocks on the network.

These changes have increased the delay in block publishing, which may result in blocks being broadcast after the proof deadline. Combined with honest reorganization, this has led to a sharp increase in the number of forked blocks.

Future Direction

In light of this, the research community should assess the "acceptable" number of reorganizations and consider the risks of equivalent attacks. Some possible directions for improvement include:

• Implement "headlock" to prevent equivalence attacks
• Increase MEV-Boost vulnerability bounty
• Expand simulation software research sub-slot timing
• Optimize relay block publishing path
• Incorporate MEV-Boost into the Consensus Client (ePBS)
• Add more test cases
• Encourage diversity of relay clients
• Adjust equivalent penalty measures

Overall, split attacks have helped us better understand the relationship between latency, MEV-Boost, and the Consensus Mechanism. We hope this will promote the continuous strengthening of the protocol.