Pipelining-only ePBS

# Pipelining-Only ePBS By Lin Oshitani (Nethermind Research). Thanks to Conor for the detailed discussion on the topic and for pointing out the direction of removing in-protocol auctions. Views are those of the author and not necessarily representative of other teams within Nethermind, including the Nethermind execution client team. ## TL;DR We propose a ePBS variant that removes trustless payment and commit-reveal-based in-protocol auction, and just focuses on execution/attestation pipelining and execution-payload beacon block separation. ## Summary ePBS ([EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)) remains the most promising path for slot restructuring: it enables execution pipelining that scales throughput, opens doors towards shortened slot times by pulling attestation aggregation off the critical path, and cleanly decouples the beacon block from the execution payload—an essential primitive for future upgrades like [attestor–proposer unbundling](https://ethresear.ch/t/decoupling-throughput-from-local-building/22004/1). However there are two open concerns around the current design: the gap between payload commitment and payload/blob reveal creates a [free-option problem](https://collective.flashbots.net/t/the-free-option-problem-in-epbs-part-ii/5145), and the trustless-payment mechanism [demands large upfront builder stake](https://x.com/mikeneuder/status/1948911398723223630). Moreover, under trustless-payments, builders must pay for the block even if it fails to be accepted by the network. Since builder revenue typically represents only a small fraction of the bid value, this creates an outsized downside risk, which must be priced into bids. As a result, in-protocol bids may consistently come in lower than off-protocol MEV-boost bids, and potentially leaving the trustless-payment path unused in practice (h/t to Lorenzo for introducing me to this). In this post we introduce pipelining-only ePBS, a minimalist variant of EIP-7732 that focuses purely on [execution-payload block separation](https://x.com/weboftrees/status/1922687909259272586). Beacon blocks now reference only the parent block’s execution-payload header, while the current slot’s execution payload is delivered later through a standard MEV-Boost auction before the PTC deadline. Eliminating the in-protocol commit-reveal auction and trustless-payment machinery closes the free-option window, removes builder staking requirements, and simplifies the protocol—yet it still preserves execution and attestation pipelining as well as the execution-payload/beacon-block split. The trade-off is a narrower blob-propagation window and continued reliance on off-chain relays, since there is no in-protocol alternative. This proposal should be viewed as one endpoint of a broader spectrum; intermediate designs, such as retaining trustless payments but tightening the commit–reveal schedule, remain open for discussion. ## Spec Change PoC A draft PoC consensus-specs implementation can be found here: https://github.com/linoscope/consensus-specs/pull/2 For reference, the patch trims 673 lines from the spec Markdown (from 2,914 to 2,241 = 23% reduction). ![image](https://hackmd.io/_uploads/Sk-i7vbOge.png) That said, the real simplification is the reduction in security-analysis complexity and ecosystem impact, not in the raw line count. ## Key Differences The tables below compare today’s Ethereum (pre-ePBS), current ePBS (EIP-7732), and the proposed pipelining-only variant. ### 1) Beacon-block structure | Era | Beacon block carries | |-----|----------------------| | **Current-day Ethereum (pre-ePBS)** | Full execution payload | | **Current ePBS (EIP-7732)** | Execution-payload **header** signed by the winning builder | | **Pipelining-Only ePBS (this proposal)** | **Parent** execution-payload header *(no commitment to the current slot’s payload)* | [DIAGRAM] ### 2) Slot Timeline | Design | Slot start | By attestation deadline | By PTC deadline | |--------|------------|-------------------------|-----------------| | **Pre-ePBS (today)** | Proposer runs an MEV-Boost auction and broadcasts the beacon block **with the full execution payload**. | Attestors download the beacon block **and its full execution payload**, then attest. | N/A | | **Current ePBS (EIP-7732)** | Proposer obtains a **builder-signed execution-payload header**, embeds it in the beacon block, and broadcasts. | Attestors download the beacon block (which commits to the current slot’s payload header) and attest. | Builder releases the execution payload; PTC attests to its availability. With the [dual-PTC deadline](https://notes.ethereum.org/@anderselowsson/Dual-deadlinePTCvote) variant, blob release will have another deadline later in the slot. | | **Pipelining-Only ePBS (proposal)** | Proposer broadcasts the beacon block referencing the **parent execution-payload header**—no commitment to the current slot’s payload, so no auction is run. | Attestors download the beacon block (which does not commit to the current slot’s payload header) and attest. | Proposer runs an MEV-Boost auction, broadcasts the proposer-signed execution payload, and PTC attests to its availability. | ## Comparisons We compare the proposed solution with the current ePBS design, delayed execution, and slot-auction ePBS. ### Comparison with Current ePBS Design ([EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)) **Shared properties** - Execution pipelining (good for scaling). - Attestation aggregation outside the critical path (good for shorter slot times). - CL/EL block separation (required for APS) **Advantages of pipelining-only ePBS** - Addresses the free-option problem by aligning the payload-commit deadline with the payload/blob-release deadline. - Eliminates trustless payments and builder staking (lower complexity). **Trade-offs** - Less blob-propagation head-room than current ePBS, especially relative to the [dual-deadline](https://notes.ethereum.org/@anderselowsson/Dual-deadlinePTCvote) variant Note that the reduced blob propagation time is inevitable if we want to mitigate the [free-option problem](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115), as both the free-option problem and better blob propagation stem from the same “commit early, propagate later” timing structure. Furthermore, if we can conclude that the free option problem is not a critical issue, we may add a dual-deadline PTC on top of the pipelining-only ePBS to maximize blob throughput. ### Comparison with Delayed Execution ([EIP-7886](https://eips.ethereum.org/EIPS/eip-7886)) **Shared properties** - Both defer consensus on a slot’s execution result until the *next slot’s* attestation deadline, achieving the same execution-pipelining effect. In this sense, ePBS can be seen as a CL-only form of delayed execution. **Advantages of ePBS** - Enables pipelining between attestation aggregation and payload propagation. With delayed execution, we need to wait until the full execution payload is propagated to start attestation aggregation, which is [especially problematic for shorter slot times](https://ethresear.ch/t/the-glamsterdam-equation/22760#:~:text=The%20speed%20that%20can%20be%20achieved%20for%20attestation%20aggregation%20is%20very%20important%20when%20considering%20the%20viability%20of%20DE%2C%20as%20shown%20in%20the%20plot.%20Can%20we%20push%20attestation%20aggregation%20down%20to%203s%3F%20If%20the%20answer%20is%20no%2C%20then%20short%20slot%20times%20seem%20rather%20daunting). - Keeps all changes on the CL side; no EL-payload reversion machinery needed. **Trade-offs** - Adds the PTC phase and fork-choice adjustments on the CL Note that it is [technically possible](https://ethresear.ch/t/slot-restructuring-design-considerations-and-trade-offs/22687#:~:text=If%20further%20pipelining%20is%20needed%2C%20we%20can%20still%20introduce%20the%20PTC) to add PTC on top of delayed execution and get the attestation aggregation pipelining. However, that does reduce the benefit of delayed execution being (mostly) a pure EL side change. Further insight on the comparison between delayed execution and ePBS can be found [here](https://ethresear.ch/t/slot-restructuring-design-considerations-and-trade-offs/22687) and [here](https://ethresear.ch/t/the-glamsterdam-equation/22760). ### Comparison with Slot Auction ePBS Switching to slot auctions is another way to address the free-option problem, as pointed out [here](https://x.com/mikeneuder/status/1948109514978582934), since it largely removes the gap between payload-commit time and payload broadcast. However, slot auctions have [well-documented drawbacks](https://www.notion.so/c7acde3ff21b4a22a3d41ac4cf4c75d6?pvs=21). They also create a [strong incentive for rational proposers to bypass the in-protocol auction](https://efdn.notion.site/Arguments-in-Favor-and-Against-Slot-Auctions-in-ePBS-c7acde3ff21b4a22a3d41ac4cf4c75d6), hence will likely collapse into off-protocol MEV-Boost auctions anyway. ## WIP: On Pipelining Borrowing from the diagram style in [Lion's post](https://blog.sigmaprime.io/glamsterdam-eip7732.html) Current day Ethereum: ![image](https://hackmd.io/_uploads/ry8Zg9Wdgg.png) Current ePBS design: [DIAGRAM] Pipelining-Only ePBS: [DIAGRAM]