Try   HackMD

Block Proposing and Validating Timelines for MEV-Boost, ePBS, and ePBS with MEV-Boost

This writeup summarizes the timeline differences between ePBS and MEV-Boost using inequalities. We analyze three models: 1) MEV-Boost, 2) ePBS, and 3) MEV-Boost with relayers on ePBS. We show that MEV-Boost with relayers on ePBS is slower than ePBS alone, which could lead to reorgs.

Definitions

Validation_TimeCL: The time taken by a node to verify the consensus portion of a block.
Validation_TimeEL
: The time taken by a node to verify the execution portion of a block.
Release_Timemevboost
: The time when a block is released from a node or relayer, assuming the MEV-boost setting.
Release_Timeepbs,cl
: The time when a consensus block is released from a node or relayer, assuming the ePBS setting.
Release_Timeepbs,el
: The time when an execution block is released from a node or relayer, assuming the ePBS setting.
Propagation_Timemevboost
: The time taken for a block to propagate across the network, assuming the mev-boost setting.
Propagation_Timeepbs,cl
: The time taken for a consensus block to propagate across the network, assuming ePBS setting.
Propagation_Timeepbs,el
: The time taken for an execution block to propagate across the network, assuming ePBS setting.
Attestation_Release_Timebeacon
: The time when a beacon attestation is released from a node.
Attestation_Release_Timeptc
: The time when a payload attestation is released from a node, assuming the ePBS setting.
Proposer_Build_Block_Time
: The time taken for a proposer to build consensus portion of a block.
Proposer_Get_Header_Time
: The time taken for a proposer to obtain a header from a relayer (MEV-boost) or builder (ePBS).
Proposer_Get_Payload_Time
: The time taken for a proposer to obtain a payload from a relayer (MEV-boost).
Builder_Submit_Payload_Time
: The time taken for a relayer to receive a payload from the builder (MEV-boost).
Proposer_Submit_Blind_Block_Time
: The time taken for a proposer to submit blind block to the relayer (MEV-boost).

Proposing a mev-boost block

In Mev-Boost, proposing a block involves two parts. First, the builder sends the block to the relayer. Second, the proposer requests the header and returns the signed block to the relayer. We break down the time it takes in the following subsections, starting with the non-optimistic relayer and then the optimistic relayer. We also assume that everything starts at the 0-second mark of the slot, including the builder sending the execution block to the relayer.

Non optimistic relayer

Builder_To_Relayer_Time=Builder_Submit_Payload_Time+Validation_TimeEL

Proposer_To_Relayer_Time=Proposer_Build_Block_Time+Proposer_Get_Header_Time+Proposer_Get_Payload_Time+Proposer_Submit_Blind_Block_Time

Release_Timemevboost=Builder_To_Relayer_Time+Proposer_To_Relayer_Time

This assumes everything happens after the slot start because bids become more valuable. Another model is to assume

Builder_To_Relayer_Time happens before the slot. Then
Release_Timemevboost=Builder_To_Relayer_Time
.

Optimistic relayer

Relayer receives builder block time

Builder_To_Relayer_Time=Builder_Submit_Payload_Time

Proposer_To_Relayer_Time is the same as before

Release_Timemevboost=Builder_To_Relayer_Time+Proposer_To_Relayer_Time

Note

Using optimistic relayer is faster than non-optimistic relayer by:

Validation_TimeEL

Validating a mev-boost block

In MEV-Boost, the block must be processed before

Attestation_Release_Timebeacon to be considered canonical. The following equation shows the conditions that need to be met for the block to be considered canonical from the perspective of all nodes.

For a beacon block to be canonical, it should satisfy:

Release_Timemevboost+Propagation_Timemevboost+Validation_TimeCL+Validation_TimeEL<Attestation_Release_Timebeacon

Proposing an ePBS block

In ePBS, proposing the consensus block and the execution block are pipelined, where the consensus block commits to the execution block's header. Block release time becomes two parts 1.) CL block release time and 2.) EL block release time.

Proposing the consensus block

We assume the proposer uses the builder's RPC to get the header. The proposer could also self-build or use P2P to obtain the header, which is arguably faster. Therefore, there is no need for proposer get header time anymore.

Release_Timeepbs,cl=Proposer_Get_Header_Time+Proposer_Build_Block_Time

Note

Using ePBS is faster than mev-boost by:

Builder_Submit_Payload_Time+Validation_TimeEL+Proposer_Get_Payload_Time+Proposer_Submit_Blind_Block_Time

Proposing the execution block

Release_Timeepbs,el is when fork choice accumulates sufficient weight (~40%) or 6 seconds into the slot. The builder could propose a "withhold" block to try to reorg consensus layer block so builder does not have to pay the proposer.

Validating an ePBS block

In ePBS, validating the consensus block and the execution block are pipelined in different stages. The beacon attestation cutoff time has been moved from 4 seconds into the slot to 3 seconds into the slot. However, we can assume that the CL block propagation time is shorter than the block propagation time. EL block validation can be delayed until the subsequent slot, as shown in the equations.

Validating the consensus block

Propagation_Timeepbs,cl<Propagation_Timemevboost
Attestation_Release_Timebeacon,epbs<Attestation_Release_Timebeacon,mevboost

For a consensus block to be canonical, it should satisfy:

Release_Timeepbs,cl+Propagation_Timeepbs,cl+Validation_TimeCL<Attestation_Release_Timebeacon

Note

Using ePBS is faster than mev-boost by:

Propagation_TimemevboostPropagation_Timeepbs,cl+Validation_TimeEL

Validating the execution block

As a PTC voting for execution block's presence

Release_Timeepbs,el+Propagation_Timeepbs,el<Attestation_Release_Timeptc

As a proposer proposing the next slot's consensus block

Release_Timeepbs,el+Propagation_Timeepbs,el+Validation_TimeEL<Next_Slot_Start_Time

Everyone else

Release_Timeepbs,el+Propagation_Timeepbs,el+Validation_TimeEL<Next_Slot_Attestation_Release_Timebeacon

Proposing an ePBS block using mev-boost

Builder_To_Relayer_Time=Builder_Submit_Payload_Time+Validation_TimeEL
Proposer_To_Relayer_Time=Proposer_Build_Block_Time+Proposer_Get_Header_Time

Release_Timeepbs,cl=Builder_To_Relayer_Time+Proposer_To_Relayer_Time

Note

Using MEV-Boost for ePBS is slower than ePBS by:

Builder_Submit_Payload_Time+Validation_TimeEL
The additional latency occurs because the trusted party must receive and verify the execution block before releasing it to the proposer.

Validating the consensus block

Release_Timeepbs,cl+Propagation_Timeepbs,cl+Validation_TimeCL<Attestation_Release_Timebeacon

Note

Given

Attestation_Release_Timebeacon is shorter than ePBS, an extra
Builder_Submit_Payload_Time+Validation_TimeEL
could lead to additional reorgs.