ePBS - HackMD

--- layout: default title: ePBS --- # Enshrined Proposer-Builder Separation ## What is ePBS? **[skip](#Latest-Updates-and-Developments)** For every slot in Ethereum, a previously psuedo-randomly chosen validator has [a monopoly on creating the next block](https://www.blocknative.com/blog/anatomy-of-a-slot). To advance the chain, transactions have to be collected, executed to ensure validity, and then propagated to a committee of attesters(also psuedo-randomly selected from the pool of proposers) who validate the block. This monopoly on block-building opens up the opportunity to order, include, exclude and indeed introduce transactions so as to make a profit for the validator proposing the block (and 'builders' who do this for them) over and above fees and issuance. This is the source of 'MEV', and this context is well understood. This is a highly sophisticated activity, as complex algorithms are required to find potentially mulitple MEV opportunities, select the most profitable ones, and ensure their execution validity, all in time to propagate the new block. To satisfy this, a complex [MEV supply-chain](https://www.paradigm.xyz/2021/02/mev-and-me) dominated by a few off-chain actors has emerged, where [builders](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus) bundle and 'sell' high-value blocks to block [proposers](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus) (validators) via [relays](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus) for a share of the profits - [and is in fact responsible for the majority of transactions included in Ethereum today](https://www.theblock.co/data/on-chain-metrics/ethereum/percentage-of-blocks-proposed-by-mev-boost-relay). The interactions between these parties are currently out-of-protocol, and rely on multiple trust assumptions. Builders submit a bid and Hash Tree Roots (HTR) to relays for an execution payload that they promise to deliver upon being selected by a proposer. The proposer polls the relay, selects the best bid [as it gets close to the end of the block](https://www.blocknative.com/blog/anatomy-of-a-slot#7) and submits a [SignedBlindedBeaconBlock](https://github.com/ethereum/builder-specs/blob/main/apis/builder/blinded_blocks.yaml#L19) to the relay, trusting that the HTR will be replaced with a full execution payload from the builder in time to broadcast the complete block for inclusion. This is the current state of Proposer-Builder Separation (PBS). This system is problematic because it requires the proposer to trust the relay to: - Relay the blinded block to the builder. - Ensure the builder provides a valid payload matching the HTR. - Not manipulate the block or steal MEV. - Ensure the builder pays the promised bid. The builder is trusting that the relay: - Transmits their bid accurately - Will not unbundle the block and manipulate its contents There are also some inefficiencies related to propagating the blocks and the risk of reorgs which will be discussed below. The primary proposal on the Ethereum Roadmap to mitigate this requirement for a trusted third party is [Enshrined Proposer Builder Separation - EIP 7732](https://eips.ethereum.org/EIPS/eip-7732). In this paradigm, the currently 'informal', offchain 'builder' role is formally recognized within the protocol, and provides a pathway for the interaction between the proposer and the builder to be trustlessly disintermediated (no relay) and specified fully. Under the current conception of ePBS: - **Builder stakes**: Builders have to stake on the Beacon chain in order to pay block proposers - **Builder Prepares Bid**: Builders assemble execution payloads (ExecutionPayloadEnvelope) and prepare SignedExecutionPayloadHeader objects, containing bid values and commitments to their payloads. - **Bid Requisition**: Proposers can directly pull bids from builders over a P2P network. This direct interaction reduces reliance on relays. - **Proposer Selects Bid**: Proposers collect bids and make a selection based on value and other factors. - **Proposer Includes Header in Beacon Block**: The proposer incorporates the chosen builder's SignedExecutionPayloadHeader into their beacon block. This acts as an on-chain commitment to include that specific payload. - **Block Proposal and Payment**: The proposer broadcasts the beacon block, initiating the payment process. The builder's staked ETH is automatically reduced by the bid amount on the beacon chain, ensuring payment to the proposer. - **Builder Reveals Payload**: Upon seeing their header included in a valid beacon block, and if it is convinced that the beacon block will become canonical, the builder reveals their full ExecutionPayloadEnvelope, containing the transactions and data for the block. - **Payload Timeliness Committee (PTC)**: A dedicated committee (PTC) attests to the timely presence of the builder's payload, in time for propagation and addition to the canonical chain. - **Payload Validation**: Validators independently validate the received payload against the committed header in the beacon block. If it is valid and timely, as attested by the PTC, the block is included in the canonical chain. (Click the arrows to see the flow. Select the current form of PBS or proposed ePBS flow from the legend to compare) <iframe src="https://ramshreyas.github.io/Possible-Futures/viewer.html?data=graphs/ePBS.json" width="100%" height="700px" style="border:none;"></iframe> This design removes the requirement for a Relay to manage the interactions between Builders and Proposers in a trustless manner. This however does introduce new concerns and considerations with respect to fork choice, reorgs and withdrawal dynamics, some of which is discussed below. ## Open Questions ### Block auctions vs slot auctions In the current design of ePBS, builders and proposers participate in a block auction where the builders commit to an execution payload and then wait for proposers to select them. So the builder commits to the block at the time of bidding. However, we know from work on [timing games](https://arxiv.org/abs/2305.09032) that a rational proposer will wait as long as possible to select a block as the block value (and corresponding bid) increases with time (within a given slot). Further, there is the threat of [free DA from invalid blocks](https://www.notion.so/efdn/Free-DA-from-invalid-blocks-e4d3790bc21941f2804ba01b3876e9b4). This is an attack where a malicious builder commits to a block with invalid execution and some arbitrary data they want included in the chain. They reveal the block on time, so the PTC will attest to its timeliness. The builder will pay the proposer. But the payload will then be deemed invalid on execution, and pay no gas. The outcome is that the data was available to all nodes, and the blockhash is committed on chain for the data, even though the clock was invalid. One alternative under discussion was [slot auctions](https://mirror.xyz/julianma.eth/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ) which has been explored at length by [Julian Ma](https://mirror.xyz/julianma.eth) from the Robust Incentives Group. In a slot auction, the builder only submits a bid and is free to construct their block within the timeframe as attested by the Payload Timeliness Comittee. Proposers will evaluate blocks based on their bid size alone, and not based on the contents - builders are able to delay the production of the block so as to capture the most MEV. <iframe src="https://ramshreyas.github.io/Possible-Futures/viewer.html?data=graphs/block_vs_slot.json" width="100%" height="700px" style="border:none;"></iframe> However, this approach has lost favor because there is a [trusted advantage in Slot Auction ePBS if the beacon proposer has sufficient risk appetite](https://ethresear.ch/t/trusted-advantage-in-slot-auction-epbs/20456). - **Trusted Advantage in Slot Auction ePBS** *Julian Ma* [Read more](https://ethresear.ch/t/trusted-advantage-in-slot-auction-epbs/20456) - **Arguments in Favor and Against Slot Auctions in ePBS** *Robust Incentives Group* [Read more](https://efdn.notion.site/Arguments-in-Favor-and-Against-Slot-Auctions-in-ePBS-c7acde3ff21b4a22a3d41ac4cf4c75d6) - **Block vs. Slot Auction PBS** *Julian Ma* [Read more](https://mirror.xyz/julianma.eth/CPYI91s98cp9zKFkanKs_qotYzw09kWvouaAa9GXBrQ) - **Why Slot Auction ePBS is not held back by LocalBlockValueBoost** *Julian Ma* [Read more](https://mirror.xyz/julianma.eth/_hSa9NOov25RMafJL2AfvrIfVKVo9reKP9UfjGv5T7E) - **Trusted Advantage in Slot Auction ePBS** *Julian Ma* [Read more](https://ethresear.ch/t/trusted-advantage-in-slot-auction-epbs/20456) - **Trusted Advantage in Slot Auction ePBS (slides)** *Julian Ma* [View](https://docs.google.com/presentation/d/1-MnAqDzR7JapIPpUEbScALEtY5axyRcPgJDpgaJ_qVI/edit#slide=id.g2ffd67b81f7_0_80) ### Forkchoice considerations The core motivation for ePBS is [proposer and builder safety](https://ethresear.ch/t/epbs-design-constraints/18728#h-31-builder-safety-9): - An honest proposer who proposes the beacon block should receive payment from the builder even if they fail to reveal the execution payload in time - An honest builder who reveals his payload in a timely manner should have his block included on chain - If the beacon block is late to propagate, then the builder [can decide not to reveal his payload](https://ethresear.ch/t/epbs-design-constraints/18728#h-33-builder-safety-revisited-12) Once again, this is a complex design space with multiple considerations. These are outlined extensively in these articles: - **epbs/DAS/FOCIL all-in-1 fork-choice** *Various authors* [Read more](https://hackmd.io/UX7Vhsv8RTy8I49Uxez3Ng) - **EIP 7732: (Block, Slot, Payload) - Fork choice** *Various authors* [Read more](https://eips.ethereum.org/EIPS/eip-7732#block-slot-payload---fork-choice) - **ePBS specification notes: Forkchoice considerations** *Potuz* [Read more](https://hackmd.io/@potuz/rJ9GCnT1C#Forkchoice-considerations) - **ePBS Forkchoice annotated spec** *Potuz* [Read more](https://hackmd.io/@potuz/SJdXM43x0) ### No trusted advantage As a general principle, ePBS - the 'enshrining' of PBS within the protocol - needs to be rationally advantageous to the proposer compared to any trust-based system such as [MEV-Boost](https://github.com/flashbots/mev-boost) and other existing MEV infrastructure. ## Community - **Eth R&D (Discord):** [Join the Discussion](https://discord.com/channels/595666850260713488/874767108809031740) - **Ethereum Magicians:** [View Thread](https://ethereum-magicians.org/t/eip-7732-enshrined-proposer-builder-separation-epbs/19634/1) ## Useful links - [EIP 7732](https://eips.ethereum.org/EIPS/eip-7732#block-slot-payload---fork-choice) - [ePBS Design Constraints](https://ethresear.ch/t/epbs-design-constraints/18728) - [ePBS Specification](https://github.com/potuz/consensus-specs/pull/2) - [ePBS specification notes](https://hackmd.io/@potuz/rJ9GCnT1C) ---