# 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\_Time^{CL}$: The time taken by a node to verify the consensus portion of a block.
$Validation\_Time^{EL}$: The time taken by a node to verify the execution portion of a block.
$Release\_Time^{mevboost}$: The time when a block is released from a node or relayer, assuming the MEV-boost setting.
$Release\_Time^{epbs,cl}$: The time when a consensus block is released from a node or relayer, assuming the ePBS setting.
$Release\_Time^{epbs,el}$: The time when an execution block is released from a node or relayer, assuming the ePBS setting.
$Propagation\_Time^{mevboost}$: The time taken for a block to propagate across the network, assuming the mev-boost setting.
$Propagation\_Time^{epbs,cl}$: The time taken for a consensus block to propagate across the network, assuming ePBS setting.
$Propagation\_Time^{epbs,el}$: The time taken for an execution block to propagate across the network, assuming ePBS setting.
$Attestation\_Release\_Time^{beacon}$: The time when a beacon attestation is released from a node.
$Attestation\_Release\_Time^{ptc}$: 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\_Time^{EL}$

$Proposer\_To\_Relayer\_Time = Proposer\_Build\_Block\_Time + Proposer\_Get\_Header\_Time + Proposer\_Get\_Payload\_Time + Proposer\_Submit\_Blind\_Block\_Time$

$Release\_Time^{mevboost} = 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\_Time^{mevboost} = 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\_Time^{mevboost} = Builder\_To\_Relayer\_Time + Proposer\_To\_Relayer\_Time$

> [!NOTE]
> Using optimistic relayer is faster than non-optimistic relayer by: $Validation\_Time^{EL}$

## Validating a mev-boost block

In MEV-Boost, the block must be processed before $Attestation\_Release\_Time^{beacon}$ 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\_Time^{mevboost} + Propagation\_Time^{mevboost} + Validation\_Time^{CL} + Validation\_Time^{EL} < Attestation\_Release\_Time^{beacon}$

## 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\_Time^{epbs,cl} = Proposer\_Get\_Header\_Time + Proposer\_Build\_Block\_Time$

> [!NOTE]
> Using ePBS is faster than mev-boost by: $Builder\_Submit\_Payload\_Time+Validation\_Time^{EL}+Proposer\_Get\_Payload\_Time + Proposer\_Submit\_Blind\_Block\_Time$

### Proposing the execution block

$Release\_Time^{epbs,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\_Time^{epbs,cl} < Propagation\_Time^{mevboost}$
$Attestation\_Release\_Time^{beacon,epbs} < Attestation\_Release\_Time^{beacon,mevboost}$

For a consensus block to be canonical, it should satisfy:
$Release\_Time^{epbs,cl} + Propagation\_Time^{epbs,cl} + Validation\_Time^{CL} < Attestation\_Release\_Time^{beacon}$

> [!NOTE]
> Using ePBS is faster than mev-boost by: $Propagation\_Time^{mevboost}-Propagation\_Time^{epbs,cl}+Validation\_Time^{EL}$

### Validating the execution block

#### As a PTC voting for execution block's presence
$Release\_Time^{epbs,el} + Propagation\_Time^{epbs,el} < Attestation\_Release\_Time^{ptc}$
#### As a proposer proposing the next slot's consensus block
$Release\_Time^{epbs,el} + Propagation\_Time^{epbs,el} + Validation\_Time^{EL} < Next\_Slot\_Start\_Time$
#### Everyone else
$Release\_Time^{epbs,el} + Propagation\_Time^{epbs,el} + Validation\_Time^{EL} < Next\_Slot\_Attestation\_Release\_Time^{beacon}$

## Proposing an ePBS block using mev-boost

$Builder\_To\_Relayer\_Time = Builder\_Submit\_Payload\_Time + Validation\_Time^{EL}$
$Proposer\_To\_Relayer\_Time = Proposer\_Build\_Block\_Time + Proposer\_Get\_Header\_Time$
$Release\_Time^{epbs,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\_Time^{EL}$
> 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\_Time^{epbs,cl} + Propagation\_Time^{epbs,cl} + Validation\_Time^{CL} < Attestation\_Release\_Time^{beacon}$

> [!NOTE]
> Given $Attestation\_Release\_Time^{beacon}$ is shorter than ePBS, an extra $Builder\_Submit\_Payload\_Time + Validation\_Time^{EL}$ could lead to additional reorgs.