ePBS, proposer-builder separation without an intermediary

Strawmap Glamsterdam (Early 2027) · ePBS

This change separates the execution part from the beacon block and lets the proposer pick a builder's bid inside the protocol to hand over block construction. The proposer and builder deal directly, with no external intermediary.

Why it is needed

Today, most block proposers hand off construction of the execution part, which decides which transactions go into the block, to an external builder. The builder must go through an intermediary that actually delivers the promised block, and both the proposer and the builder must trust that the counterparty and the intermediary are honest. Validators also have to finish consensus verification, execution verification, and blob data checks and then vote, all within a short window of one third of a slot after receiving the block. Propagation is also slow because the entire execution payload is carried in the beacon block. ePBS makes the builder an entity that deposits stake inside the protocol and removes the intermediary. An honest proposer gets paid no matter how the builder behaves, and an honest builder's block is included in the chain no matter how the proposer behaves. Execution verification is pushed to the later part of the slot, which reduces the burden before voting, and because the builder can broadcast blob data early, the risk of chain reorgs (reorg) caused by blob transactions also goes down. It is currently in the testing stage on devnet 7, where the slot deadlines and the safeguards of the builder deposit contract are being set. The Strawmap draws it as part of Glamsterdam, but this is an estimate, not a commitment.

How it works

  1. The builder deposits and registers The builder puts at least 1 ETH into a new deposit contract on the execution layer and gets onto the builder list in the beacon state. Because it is not a validator, it does not take part in attestations or committees.
  2. The proposer picks a bid The builder signs and sends a bid that contains only minimal information such as the block hash and the payment amount. The proposer picks one of them, puts it in the beacon block, and broadcasts it. The proposer can also build the block directly.
  3. The builder reveals the payload After the beacon block has propagated, the builder signs and broadcasts the promised execution payload and blob data. On devnet 7, the deadlines are tentatively set at 3 seconds for attestations and 6 seconds for the payload.
  4. The committee checks that it arrived on time A Payload Timeliness Committee (PTC) of 512 members chosen each slot votes on whether the payload and blob data were revealed within the deadline. If more than half vote yes, the payload is treated as included in the chain. Verification of the execution content happens in the later part of the slot.

Related EIPs

← Roadmap