Introduction
This piece is the second in our series on the Ethereum supply chain. In Part 1, we covered the evolution of the supply chain to date and the justifications for proposer-builder separation (PBS). We also explored some issues that the current reliance on out-of-protocol relays has led to, and how various design decisions have led to centralizing tendencies up and down the stack.
In this part, we explore Enshrined Proposer-Builder Separation (ePBS), a high-level proposal to protocolize PBS and avoid the negative effects of out-of-protocol relays. First, we recap the reasons to enshrine PBS. Then, we define the design goals for ePBS, analyze the proposals themselves, and examine dependencies that may affect potential implementations of ePBS.
Image by Mike Neuder
Why ePBS?
As described in Part 1, Ethereum’s current out-of-protocol implementation of PBS pushes up against some core Ethereum values and design goals.
Centralization
Today, there are only eight active relays, and the five largest relays have a market share of over 90%. So much reliance on so few entities is undesirable as it represents a centralized chokehold over Ethereum block production.
From mevboost.pics
Relay Censorship
Because MEV-Boost relays today simulate blocks, they can censor blocks that contain undesirable transactions. Censorship is observed today where some relays choose to not relay blocks that include transactions interacting with OFAC-sanctioned addresses. Such censorship violates Ethereum’s aim to be credibly neutral.
From censorship.pics
Dependence on Out-of-Protocol Software
As out-of-protocol software, MEV-Boost is not subject to Ethereum’s rigorous testing for in-protocol changes. MEV-Boost is used to relay 92.23% of Ethereum blocks today; such critical infrastructure needs to be robust and stable. Issues related to MEV-Boost have already produced negative effects on the network, including the low-carb-crusader attack (which exploited a bug in a MEV-Boost implementation) and the Prysm MEV-Boost Shapella bug.
Sustainability
Independent relays operate today as public goods with unclear funding models. Their sustainability depends on altruism or more verticalized business models.
Trustlessness
Today, Validators and builders must trust relay operators to fulfill their duties.
By enshrining PBS, Ethereum can get the benefits of PBS without compromising on its core values.
ePBS Design Goals
ePBS is intended to reduce Ethereum’s reliance on MEV-Boost and public good relays. Here are some important design goals for an ePBS implementation. Of course, these goals may trade off against each other.
- Builder safety: an honest builder winning the block auction must be able to create a block, and their payload content should eventually become canonical. In Equivocation attacks in mev-boost and ePBS, the authors analyze the scenario where a malicious proposer unbundles a block to steal the MEV. In this context, safety means the block and its constituent MEV bundles should be safe from these attacks.
- No builder griefing: If the builder payment is processed, the builder must be able to publish a block that becomes canonical.
- Proposer safety: when a proposer commits to a block on time, they must receive the promised payment.
- The system should be permissionless and censorship-resistant.
- The system should be compatible with the future roadmap of Ethereum: single slot finality, MEV burn, distributed block building, etc.
- Validators should incur minimal additional overhead to keep node requirements minimal.
- The system should be maximally competitive with out-of-protocol solutions: validators running mev-boost should not have significant advantages over “altruistic” validators relying on ePBS.
- Block times should be minimized so MEV is minimized.
The Anatomy of a Slot
Before proceeding with the discussion of ePBS, we need to understand the timeline of slots. This is central to understanding how the ePBS proposals are designed.
In Ethereum PoS, time is partitioned into 12-second increments called slots. Block production is done by validators who validate blocks and take turns proposing blocks. For each slot, the consensus algorithm designates one of the validators unilateral permission to propose a block; this validator is called the proposer.
When it’s a validator’s turn to propose:
- The proposer assembles a valid signed block and broadcasts it to the network. This broadcast is the proposer committing to a block at their assigned time.
- Attesters validate and vote for the block they believe to be the next head of the chain, according to their local view of the world, by applying the fork choice rule.
- If enough validators attest to the proposer’s block, the block is included in the canonical chain. The proposer receives the block reward and attesters receive attestation rewards.
So "committing to a block on time" means the assigned proposer proposing a seemingly valid block in the time slot they are scheduled and not missing their assigned slot. A validator can be penalized or slashed for failing to propose a block when they are supposed to. The rule ensures proposers get fairly rewarded for doing their job on time.
From Time, slots, and the ordering of events in Ethereum Proof-of-Stake
ePBS Designs
We are finally ready to discuss some designs for ePBS. The high level goal for ePBS is to have an in-protocol block auction that builders bid on. If the winning builder reveals their payload on time, it is guaranteed to become canonical.
Two-slot PBS
Two-slot proposer/builder separation proposes splitting the single slot into a “slot pair”. Vitalik suggested each "slot pair" consists of two slots: one for publishing an "exec header" and another for publishing the next "exec header." The first slot contains a "beacon block" proposed by a randomly selected validator, including a commitment to the winning builder's bid.
The second slot contains an "intermediate block" published by the winning builder with the full execution payload and as many attestations from the beacon block as possible. The remaining N-1 attestation committees vote on the intermediate block. The builder has 8 seconds to publish an intermediate block, which is then attested to by remaining validator committees, giving it a "proposer boost" in the fork choice. If the beacon block is missing, the builder is not penalized for not publishing the intermediate block.
This design aims to protect builders from censorship and ensure their inclusion in the blockchain, with payments guaranteed through the beacon chain's fork choice rule. While analyzing the fork choice rule and consensus is beyond the scope of this article, in short the fork choice rule is a part of the consensus mechanism, ensuring that all validators are working on the same chain.
From Two-slot proposer/builder separation
In a modification proposed by Mike Neuder and Francesco, two-slot PBS is called Two-Block HeadLock because it uses a single slot to produce two blocks. The first is a proper block, which contains a commitment (header) to the execution payload, and the second block contains the actual content of the payload.
This proposal does not address transaction-level censorship, and introduces additional complexity from the two-slot structure. And one primary requirement for making this possible is increasing the effective slot time from 12 seconds to 16 seconds, which is already on the roadmap as a part of single-slot finality.
The main drawback of this proposal is that it weakens the chain’s resistance to reorgs. In Ethereum today, one mechanism for resisting reorgs is the proposer boost. Proposer boost gives the validator who is elected to propose the next block additional weight ("boost") in the fork choice rule that selects the canonical chain. By boosting the weight of the next proposer's block, reorgs become much harder to execute. An attacker has to outweigh the boosted block with many more votes on their fork. Proposer boost is a key way Ethereum maintains chain consistency and transaction ordering today.
Under two-slot PBS, the builder's block is given full weight in the fork choice rule that selects the canonical chain in two-slot PBS, diluting the power of the proposer boost. With two slots and builder blocks weighted equally, the proposer boost is only applied to the proposer's block. For example, if validator committees are split 50/50 between slots, the proposer boost is only 20% instead of the full 40% of the stake.
This significantly increases the probability that an attacker can intentionally reorg the chain by withholding their attestations. Analytical modeling shows that a 10% attacker can pull off a 6-block reorg with a 4.6% probability under two-slot PBS. But this attack would only have a 0.04% success probability under today's protocol. By reducing the resistance to reorgs, two-slot PBS gives attackers more opportunities to reorder or censor transactions on the chain.
Alternative proposer-builder separation designs are aiming to restore reorg resistance. For example, the payload timeliness committee approach does not give builders direct weight in fork choice. Further analysis is still needed to quantify reorg probabilities under different PBS approaches. Ultimately, there might be an inherent tradeoff between enabling proposer-builder separation and maintaining reorg resistance.
Payload-timeliness Committee (PTC)
The Payload-timeliness Committee (PTC) is the latest ePBS design, proposed by Mike Neuder and Francesco. The PTC design retains Ethereum's existing single-slot structure but introduces a new committee that votes on payload timeliness in each slot.
Under this proposal, blocks are produced in two phases. First, the proposer proposes the consensus layer block, containing only a builder bid and header but no execution payload. Again, this represents the proposer’s commitment to the winning builder bid. As usual, the full attestation committee then votes on this consensus block before the deadline. After observing this block, the chosen builder releases their execution payload, including the full transaction list.
This payload is then observed by the PTC, which is a subset of the current slot's attestation committee. The PTC casts votes on whether the payload was released in a timely manner or not based on their view. These votes determine if the block should be considered full or empty—a full block means the execution payload successfully updated the Ethereum state, while an empty block did not.
In the following slot, the new attestation committee uses the proportion of PTC votes for full versus empty to decide how much weight to assign to the full and empty versions of the previous block. Unlike two-slot PBS, builders do not directly get fork choice weight themselves. By retaining single slots and using committees, the PTC approach aims to improve security and simplicity compared to two-slot PBS while still formalizing the proposer-builder relationship to enable open participation.
Payments to proposers are handled after the epoch is finalized to allow time for detecting duplicate proposals (equivocation). Bids are paid when the bid is part of the canonical chain, regardless of whether the payload itself made it. This design provides proposer safety (proposer gets paid for the bid they choose) and same-slot builder payload safety (protecting builders against same-slot unbundling), but does not prevent next-slot unbundling.
This PTC design introduces new potential for chain splitting by malicious actors.
One vector is proposer-initiated splitting. Here, the proposer intentionally releases their block commitment close to the attestation deadline, splitting the honest attesters' views. Some see the block on time, and some don't. This forces the builder into a tough position. Publishing the payload risks it not making it into the canonical chain if the next proposer doesn’t build off their block, while withholding it risks paying the winning bid without landing the payload. The builder's outcome depends entirely on the subsequent proposer's uncertain actions.
Another risk is builder-initiated splitting, where the builder selectively reveals the payload to grief the next slot's proposer. If the builder only reveals their payload to only a subset of the PTC, the next proposer may build on a block that gets orphaned because it disagrees with the main PTC votes. This attack is difficult to execute as it requires precise coordination between the builder and most of the PTC. The risk can be mitigated by having a decentralized, randomized, and sufficiently large PTC committee.
In summary, PTC introduces some new but seemingly manageable splitting vectors. Further analysis of the feasibility and probability of such attacks would be beneficial. Ongoing research is exploring PTC parameters and tradeoffs to mitigate these risks.
Proposals to Support
Like any Ethereum upgrade, ePBS does not live in a vacuum. These are some future Ethereum proposals with which an ePBS implementation should be compatible.
Inclusion Lists
Inclusion lists were proposed as a way to combat censorship by block builders. At a high level, an inclusion list is a list of transactions published by the proposer, that the block builder must include in their block.
Inclusion lists do not impose a material constraint on most builders because their constituent transactions should make blocks no less valuable to the builder.
The first issue with this proposal is that because censoring builders see the inclusion list ahead of time, they may simply refuse to build the block. This can place a burden on the proposer, who now needs to build their own block. There are many variants on inclusion lists to solve this problem.
Proposer Suffixes: Under this implementation, proposers create a suffix for the proposed block. The block builder sees no information from the proposer, and the final block is the block builder’s partial block, plus all transactions in the suffix that were not included by the block builder. This adds a burden to the proposer and also allows them some MEV opportunities, which can be mitigated by having the proposer pre-commit to their suffix.
Forward Inclusion List: Under forward inclusion lists, a proposer broadcasts a list of transactions that builders must include unless they can fully fill the block with other transactions. Put another way, a block builder must either fully utilize the available blockspace or use the unused space for the proposer-selected transactions.
The core idea is to force builders to fully utilize the available block space rather than allowing proposers to force the inclusion of their chosen transactions (which may prevent builders from building the most valuable block). The current proposer publishes a list of transactions to be included in the next block, and the attesters of the next block ensure its transactions are in that block if the block is not full and the inclusion list was published on time.
No Free Lunch: This proposal by Mike Neuder and Vitalik addresses the free data availability problem. The free data availability problem is that the proposer (or the builder) should be unable to include data on-chain that no one pays for, in the form of the inclusion list itself.
The forward inclusion list proposal above solves this problem with subjective enforcement of the inclusion list: attesters determine a block's validity based on their local view of the inclusion list. This proposal aims to design objective enforcement; that is, producing a valid block that doesn’t conform to the constraints set out in the IL should be impossible.
The core idea is to split the inclusion list into a summary and a list of transactions. The summary only includes address and gas limit pairs that can be satisfied by a transaction in the current or next block. Transactions in the list must be valid pre-state, but their contents are not signed, so validators can deny seeing specific ones. This solves the free data availability issue since validators only need access to transactions that end up on-chain.
MEV Burn
MEV burn explores burning MEV as part of ePBS. Under the out-of-protocol implementation of PBS and most proposals for ePBS, MEV is directed to the proposer, which results in minor economies of scale for validators. ePBS without MEV burn requires builder balances to exceed bids, so only the builders with the largest balances can capture the largest MEV opportunities. MEV burn additionally smooths proposer MEV rewards and directs some MEV away from proposers to ETH holders.
In MEV burn, builders bid to construct block payloads by specifying a "payload base fee" which is burned instead of paid to the proposer. Honest attesters enforce a “payload base fee floor” based on the largest payload base fee they observe by some cutoff before the slot boundary. Once the proposer picks the winning the builder bid, the builder reveals their block; the payload base fee is burned (distributed to ETH holders), and only the payload tip is captured by the proposer.
This redirects some MEV to ETH holders via burning, partially smooths the distribution of MEV rewards to proposers, and only requires builder balances to exceed payload base fees rather than the total value of the block.
Analysis from “In a post-MEV-Burn world - Some simulations and stats” finds that MEV burn could burn around 90% of the current MEV rewards to validators (assuming bidding behavior does not change under the new system). This suggests that MEV burn can significantly reduce the role of MEV in motivating participation in Ethereum consensus.
Additionally, the proposed median MEV profits per block could decrease by 96% from around 0.05 ETH to 0.002 ETH. This reduction in absolute MEV rewards may also decrease inequality in validator revenue.
However, MEV burn is not likely to eliminate sporadic high-value MEV jackpot blocks. With careful parameterization of the "delta time,” large jackpots would become rarer but could still occur regularly at over 1 ETH.
Challenges remain around potential gaming of the system, e.g. by builders colluding with proposers to withhold bids (intermediated by out-of-protocol relays) until after the attester payload base fee observation cutoff. Longer block times may be required to implement this proposal to allow for the extra attestation round.
While MEV burn should reduce the influence of MEV on staking rewards, it will not do so perfectly. Some types of MEV, e.g. sandwich attacks, are likely to be captured by the burn, while other types, e.g. CEX/DEX stat arb, are unlikely to be captured fully as they depend more on last-second bids. The shape of the MEV, specifically how much depends on time-sensitive off-chain information, dictates how much is likely to be burned.
In summary, MEV burn shows potential to distribute some MEV to ETH holders rather than proposers and additionally smooth validator rewards, but is potentially gameable in a world with collusion devices.
Unbundling PBS
PBS is a mechanism for the proposer to commit to entirely selling off their right to propose a block. Inclusion lists, as discussed above, solve some issues that arise from the sale of the whole block. But the future of Ethereum may require proposer commitments beyond the sale of the entire block. Protocol-enforced proposer commitments (PEPC) was originally presented in Unbundling PBS as a way to protocolize general proposer commitments.
PEPC
Recall that PBS is a mechanism for sophisticated block builders to buy blockspace from unsophisticated proposers. Builders bid for the blockspace, the proposer signs a block header, and is compensated by the block builder after the signed block header is delivered. ePBS attempts to enable this behavior entirely in the protocol.
The more general problem is to create a general in-protocol commitment mechanism for block proposers and other market participants rather than the specific mechanism of auctioning off an entire block. ePBS is highly opinionated on the market structure for blockspace, specifically anchoring on a market where entire blocks are auctioned to single winning builders. That may be too rigid for future blockspace markets, once again pushing these markets out of protocol. For example, a proposer, Alice, could commit to including a certain transaction from Bob as the first transaction in her next proposed block. Currently, if Alice violates this commitment, her block can still be made canonical by the network even though she broke the agreement.
The goal of PEPC is effectively to protocolize Eigenlayer. Validators allow external addresses to slash them under some conditions. More specifically, proposers specify commitments in the EVM, and attesters verify whether or not the proposed blocks satisfy the commitments.
If commitments are violated, the entire block is considered invalid—so blocks that break commitments are ignored and not gossiped by honest nodes. The idea is to write and enforce commitments through the EVM via standardized smart contracts. Participants like Alice and Bob would write their commitments to the EVM, where they become "common knowledge". The EVM code defining the commitments would then be executed to validate blocks, reverting if commitments are violated.
PEPC is in its early stages of research and development. Many fascinating open problems remain around optimizing latency, gas usage, data availability for commitments, effects on block builders, detrimental commitments, incentives for distributed enforcement by nodes, and more. A PEPC design will need to manage complexity, griefing risks, safety guarantees, and coordination incentives. Continued research is needed to address these issues and unlock the potential of flexible, in-protocol proposer commitments.
The Cost of Enshrinement
We have explored the benefits to enshrining PBS and some paths forward. But this is an opinionated change which naturally leads to the question of the costs of enshrinement.
Ethereum originally sought to build a simple shared state machine, delegating most functionality to protocols built on top of it. This approach aimed to keep Ethereum lean, versatile, and neutral.
Recent enthusiasm for enshrining more into the core protocol risks undermining Ethereum’s values of decentralization and credible neutrality. Any enshrinement expresses a point of view on the network and increases complexity. And as long as the protocol has not ossified, protocol upgrades rely on political consensus at the social layer, perhaps the layer of Ethereum that is the least credibly neutral. Vitalik explores minimal viable enshrinement: “rather than enshrining an entire functionality, the protocol could enshrine a specific piece that solves the key challenges with making that functionality easy to implement”.
Discourse around centralization is often imprecise, failing to take into account which forms of centralization are non-starters for the protocol and which are less acceptable. It can also be unrealistic, fighting uphill against economic realities while sacrificing efficiency.
A spectrum of centralization will emerge at different layers of Ethereum due to market incentives and efficiencies. Rather than attempt to fully eliminate centralization, a degree of centralization may be tolerable if equilibrium behaviors adhere to Ethereum’s core principles of censorship resistance and credible neutrality. Because Ethereum is meant to be useful in the real world, such equilibriums must be analyzed taking economic, political, and regulatory realities into account.
Conclusion
In this piece, we explored the path to enshrining PBS, multiple designs for ePBS, and some of the tradeoff space inherent to enshrinement. In Part 3, we will examine the space of out-of-protocol solutions for replacing or augmenting relays to achieve similar goals to ePBS, including mev-boost+/++ and optimistic relays. We will also motivate why these solutions may be desirable due to the cost of enshrinement.
To collaborate with us, please reach out to collaborators@umbraresearch.xyz.