Time, Slots, and Event Ordering in Ethereum Attestation

On April 2, a malicious participant in the Ethereum network exploited a vulnerability in mev-boost-relay to steal 20 million USD from a certain MEV seeker. The developers subsequently released five patches to fix this vulnerability, but interactions with existing network delays and validator strategies led to a brief instability in the Ethereum network on April 6. Network reorganization can reduce block production rates and settlement guarantees, which is detrimental to network health.

This article aims to explore the interplay between mev-boost and consensus mechanisms, reveal the nuances in Ethereum's attestation, and discuss some possible directions for improvement. Our inspiration comes from two events: attacks on searchers and temporary network instability.

The role of mev-boost ###

mev-boost is a protocol designed to mitigate the negative impact of maximum extractable value (MEV) on the Ethereum network.

There are three roles in mev-boost:

• Relay - Connects proposers to trusted intermediaries of block builders.
• Builders - Complex entities that construct blocks to maximize their own and proposers' MEV.
• Proposer - Ethereum attestation validator.

The approximate sequence of events in each block is:

Builders receive transaction creation blocks from users, searchers, or other sources.

The builder submits the block to the relay.

Relay validation of block validity and calculate the fees paid to the proposer.

The relay sends the "blind" block header and payment amount to the proposer of the current time slot.

The proposer evaluates all received bids and signs the blinded block header corresponding to the highest payment.

The proposer will send the signed block header back to the relay.

The relay publishes blocks through the local beacon node and returns them to the proposer. The builder and proposer receive rewards through transactions within the blocks and block rewards.

Relays, as trusted third parties, facilitate the fair exchange of block space for proposers and the transaction ordering for builders regarding MEV extraction. Relays protect builders from MEV theft and also safeguard proposers in verifying block validity, processing large volumes of blocks, and ensuring accurate payments.

mev-boost is a key infrastructure because it allows all proposers to fairly obtain MEV without establishing trust relationships, which helps to decentralize Ethereum in the long run.

Ethereum's fork choice rules and mev-boost

Before delving into the attacks and responses, let's first understand the attestation mechanism of Ethereum and its fork choice rule. The fork choice rule allows the network to reach consensus on the chain head.

The fork choice rule is a function evaluated by the client that takes known blocks and other messages as input and outputs what the "canonical chain" is. The fork choice rule is necessary because there may be multiple valid chains to choose from.

The relationship between fork selection rules and time is less known, but it has a significant impact on block production.

(# Slot and Sub-Slot Cycle

In Ethereum PoS, time is divided into 12-second slots. The PoS algorithm randomly designates a validator to propose the block for that slot, and this validator is called the proposer. In the same slot, other validators are assigned to vote on the latest block at the chain head position in their local view by applying the fork choice rule. The 12-second interval is divided into three 4-second phases.

The events in the slot are as follows, t=0 indicates the start of the slot:

The most critical moment in the slot is the attestation deadline at t=4. If the attestation validator does not see the block before the deadline, it will vote on the previously confirmed head on-chain. The earlier the block proposal, the longer the propagation time, and the more accumulated witnesses there will be.

From the perspective of network health, the optimal block release time is t=0. However, since the value of blocks monotonically increases over time, proposers have the incentive to delay the release in order to accumulate more MEV.

Historically, even after the attestation period and close to the end of the slot, as long as the next validator observes the block before building the subsequent slot block, the proposer can still publish the block. In order to promote rational behavior ) delaying the publishing of blocks ### towards honest behavior ( timely publishing ) development, "honest reorganization" was introduced.

(# Proposer Enhancement and Honest Restructuring

Two new concepts have been introduced to the consensus client, which have a significant impact on the attestation deadline.

Proposal Enhancements - Attempts to minimize reorganization balance attacks by granting the proposer a "boost" equivalent to 40% of the full attestation weight for fork selection. This boost lasts for only one slot.

Honest Restructuring - Adopting proposer uplift, allowing honest proposers to use it to forcibly restructure blocks with attestation weights below 20%. This is implemented in certain clients. This change is optional, as it is a local decision of the proposer and does not affect validator behavior.

Avoid honest restructuring in certain special circumstances:

1. During the epoch boundary block period
2. If the chain is not completed
3. If the chain head is not obtained from the slot before the reorganized block

Condition 3 Ensure that honest reorganizations only remove a single block from the chain, acting as a circuit breaker to allow the chain to continue generating blocks during extreme network delays.

)# Repair of relays and beacon nodes against unbinding attacks

In the unbinding attack on April 2, the proposer exploited a relay vulnerability to send invalid signature headers for the attack. In the following days, the relay and core development teams released multiple software patches to mitigate the risk of repeated attacks. The five main changes are as follows:

1. Relay Change:

Check the database for known malicious proposers.

Check whether the complete block has been transmitted to the P2P network during this period.

Introduce a uniform random delay within the range of 0-500ms before publishing the block.

2. The beacon chain node change ### is only applicable to the relay beacon chain node ###:

Verify the validity of the beacon block before broadcasting.

Check if there is an equivalent on the network before publishing the block.

These changes combined lead to unstable consensus, and most validators adopting honest reorganization strategies further exacerbate this situation.

(# unintended consequences

Each of the 5 changes mentioned above will increase the delay on the hot path of relay block publication, thereby increasing the probability that the relay block may be broadcasted beyond the attestation deadline.

Before implementing these checks, the signature header typically arrives around t=3 without issues. The relay overhead is low, and blocks can be published before t=4.

However, as the delay introduced by the five patches increases, the relay may be partially responsible for the delayed broadcast. In some cases, the proposer sending the signed header late, combined with the additional delay introduced by the relay, can lead to missing the attestation deadline. When there is no honest reorganization, these blocks are likely to enter the chain. However, when there is an honest reorganization, missing the attestation deadline means that the block will be reorganized by the next proposer.

As a result, in the days following the attack, the number of forked blocks increased sharply. In the worst case, 13 blocks were reorganized within an hour, which is about 4.3%) more than normal, approximately 5 times more. As various changes were introduced by the relay, the surge in the number of forked blocks became apparent. Through community efforts, many changes were reversed, and the network returned to a healthy state.

The most useful change at present is the equivalence check before the beacon node block validation and broadcasting. Malicious proposers can no longer carry out attacks by sending invalid headers to the relay and ensuring that the relay beacon node does not see the equivalent block before publishing. Nevertheless, the relay is still vulnerable to more general equivalence attacks.

![Paradigm: Exploring the Relationship Between MEV-Boost and Ethereum Consensus Mechanism]###https://img-cdn.gateio.im/webp-social/moments-00fb5ee47056beb2efc3ca4ac271a69c.webp(

) future direction

The research community should assess the "acceptable" number of reorganizations, consider the general risks posed by equivalence attacks, and determine whether mitigation measures are necessary.

Several directions are being actively explored:

Implement "headlock" protection for mev-boost against equivalence attacks. This requires changes to the consensus client software and may necessitate extending the attestation deadline.

Increase the mev-boost software vulnerability bounty program.

Exploring the impact of extended simulation software on the timing of sub-slot on network stability.

Optimize the relay block publishing path to reduce unnecessary delays.

Incorporate mev-boost into the consensus client, namely enshrined-PBS(ePBS).

Add tests based on delay and attestation deadline issues.

Encourage diversity in relay clients.

Consider adjusting equivalent penalty measures.

Overall, we are excited about the renewed momentum of the MEV and mev-boost ecosystem. Through unbinding attacks and mitigation measures, we have understood the key relationship between latency, mev-boost, and consensus mechanisms; we hope that the protocol can continue to strengthen.

![Paradigm: Discussing the relationship between MEV-Boost and Ethereum consensus mechanism]###https://img-cdn.gateio.im/webp-social/moments-9db8f9a0944e1eff6bde4db0c8343fbe.webp(