Optimization Problem: Block Proposal in ePBS Block Auction

In ePBS block auctions, a block proposal must consider its local block before opting to use a builder block. This represents honest behavior that aligns with today's MEV-Boost block auctions. Considering a local block in ePBS requires an additional round of message passing and signing between validator client and beacon node which could prolong block proposal time, for which I currently don't have a solid solution. This document describes this optimization problem.

We begin with two requirements:

• A proposer can only start block proposals at the beginning of the slot, not earlier. This aligns with the honest validator specifications.
• A proposer must consider the local execution payload and use it if its value is higher after local value boost mutiplier (how it works today) or minimum bid calculations, or if a censorship oracle flag has been set.

API Interaction for Block Proposal Today

Block proposal today using mev-boost can be described under the following steps

• At the start of the slot, the validator requests a block from the beacon node.
  $T_{req}$
• The beacon node assembles the consensus parts of the block.
  $T_{consensus}$
• The beacon node requests the execution payload from the execution client.
  $T_{e=local}$
• The beacon node requests the execution header from relayers.
  $T_{e=relayers}$
• The beacon node selects the best header.
• The validator signs the block.
  $T_{sign}$
• The beacon node either gossips the block or returns the signed block to the relayer.
  $T_{gossip}$

Block constructions can be optimized by parallelizing tasks as much as possible. The total block construction time is listed as follows:

$$T_{req}+max(T_{consensus},T_{e=local},T_{e=relayers})+T_{sign}+T_{gossip}$$

Naive API Interaction for Block Proposal in ePBS Block Auctions

• At the start of the slot, the validator requests a header from the beacon node.
  $T_{req}$
• The beacon node requests the execution payload from the execution client.
  $T_{e=local}$
• The validator signs the execution header.
  $T_{sign}$
• The validator requests a block from the beacon node.
  $T_{req}$
• The beacon node assembles the consensus parts of the block.
  $T_{consensus}$
• The beacon node requests the execution header from builders.
  $T_{e=builders}$
• The beacon node gathers the execution header from the P2P network.
  $T_{e=p2p}$
• The beacon node selects the best header.
• The validator signs the block.
  $T_{sign}$
• The beacon node gossips the block.
  $T_{gossip}$

The new total block construction time is listed as follows:

$$T_{req}+T_{e=local}+T_{sign}+T_{req}+max(T_{consensus},T_{e=builders},T_{e=p2p})+T_{sign}+T_{gossip}$$

$$=2\ast T_{req}+2\ast T_{sign}+T_{e=local}+max(T_{consensus},T_{e=builders},T_{e=p2p})+T_{gossip}$$

As expected, the additional latencies are due to an extra round of requests and signing the local execution payload, which is necessary because the header requires the proposer's signature.

Optimized API Interaction for Block Proposal in ePBS Block Auctions

Idea 1

1.Proposer calls

$PrepareBlock$ at the start of the slot.

$PrepareBlock$ returns a boolean flag to indicate whether local header should be used.

$PrepareBlock$ prepares execution and consensus parts of the block in the background so any subsequent call that is

$GetHeader$ or

$GetBlock$ will be a no-op
2. If

$local$ is

$true$ then proposer calls

$GetHeader$ ->

$SubmitHeader$ ->

$GetBlock$ ->

$SubmitBlock$
3. If

$local$ is

$false$ then proposer calls

$GetBlock$ ->

$SubmitBlock$

Idea 2

1.Proposer calls

$GetBlock$ to sign.

$GetBlock$ returns

$Block|Header$.

• a. If it's
  $Block$ then proposer knows builder's header is selected and it just has to to sign the block. Proposer signs the block and calls
  $SubmitBlock$
• b. If it's
  $Header$ then proposer knows the local's header is selected, it signs the header and calls
  $SubmitHeader$

2. Continue from step (2b),
   $SubmitHeader$ returns
   $Block$. Proposer signs block and calls
   $SubmitBlock$
3. Finally if the proposer uses local header, it must get and sign the execution payload envelope. Proposer calls
   $GetExecutionPayloadEnvelope$, signs the payload envelope, and calls
   $SubmitExecutionPayloadEnvelope$

Slot auction

• Given that the proposer does not have to commit to the transactions, this issue seems less severe in a slot auction. The validator could just commit to its builder ID and sign it ahead of the slot, with the value defaulting to 0. The beacon node can then choose whether to use its own header at the time of the proposal.