*Acknowledgement: This post is inspired by all the insightful work and thoughts from Vitalik Buterin, Barnabé Monnot, Julian Ma, Mike Neuder, Justin Drake, Davide Crapis and Dankrad Feist. *

Introduction

The Ethereum blockchain, since its inception, has been a hotbed for innovation, fostering the development of decentralized applications and smart contracts. In September 2022, Ethereum underwent a significant transition from a Proof-of-Work (PoW) consensus mechanism to a Proof-of-Stake (PoS) model. This transition was not only a shift in the way Ethereum secures its network but also introduced a new paradigm known as the Proposer-Builder Separation (PBS) scheme.

Understanding Proposer-Builder Separation (PBS)

The Proposer-Builder Separation (PBS) scheme was introduced to decouple the roles of selecting and ordering transactions in a block (the builder) from those validating its contents and proposing the block to the network (the proposer). In this system, proposers validate and secure the network, relying on specialized block builders to create blocks with the most value. Relays also play a crucial role, acting as mediators between builders and proposers, transmitting the most lucrative blocks from the builders to the proposers.

The PBS ecosystem is made up of several key players, including searchers, block builders, relays, and validators. Searchers are Ethereum users who prioritize privacy and prefer to use a private transaction pool instead of the public mempool. Block builders receive bundles from searchers in the PBS system and attempt to create the most profitable block possible. Relays are responsible for holding blocks from builders in escrow for validators, while validators are still responsible for proposing blocks to the Ethereum network.

The primary benefits of PBS lie in its potential to decentralize block validation and maximize block profitability. By separating the roles of block building and block proposing, PBS provides all validators, regardless of size, access to competitive blocks. This prevents hobbyist validators from being outcompeted by institutional players who can optimize block profitability better.

Enshrined Proposer-Builder Separation (ePBS) or in-protocol PBS

Enshrined Proposer-Builder Separation (ePBS) or in-protocol PBS is a proposition to incorporate PBS directly into Ethereum's consensus layer. This concept emerged in response to potential relay failures and the need to eliminate single points of failure in the system. This approach, introduced by Vitalik Buterin, allows the Ethereum protocol itself to provide assurances to both builders and proposers. At the time of the Ethereum merge, there was no in-protocol solution available for PBS. As a result, Flashbots developed an out-of-protocol solution known as mev-boost. This solution has been widely adopted, accounting for approximately 90% of the blocks produced on the Ethereum network.

For builders, the protocol ensures that a commitment made by the proposer can only be reverted due to a consensus failure or a safety fault with single-slot finality. For proposers, the protocol guarantees that the builder's promise of payment will be honored, regardless of the builder's subsequent actions.

The concept of PBS can be viewed in a modular fashion, considering it as a market structure/legal system and an allocation mechanism/business logic. As a market structure, the protocol defines the conditions under which proposers may engage with third parties during block construction. As an allocation mechanism, the protocol defines the space of contracts that proposers and third parties may enter into.

Under the mev-boost model, the protocol does not intervene in the principal-agent problem. It does not recognize the role of builders as an entity interfacing with proposers. This lack of intervention implies that there are no trust-minimized, in-protocol ways for proposers to be compensated when the other side of the market fails to honor their agreements.

The debate on whether this should be the responsibility of the protocol is ongoing. On one hand, proposers seeking maximum profit may engage in risky behavior, which the protocol may not want to backstop. On the other hand, the asymmetry between block construction and block verification opens up design possibilities that cannot be realized without appealing to external entities.

If the protocol intends to fully lean into the PBS design philosophy, it may require powerful builders to produce complex blocks, imposing this requirement on proposers. This could be a rough bargain for some proposers, particularly those in resource-constrained environments. However, the risk to the protocol is mitigated by the fact that builders are profit-making entities and care for their blocks to make it into the protocol.

Reasons to Enshrine PBS(ePBS)

1. Upholding Ethereum's Core Values: The current reliance on relays, which are centralized entities, contradicts Ethereum's foundational principles of decentralization. A small group of relay operators currently handle 99% of mev-boost blocks, which gives them a disproportionate influence in the ecosystem. Moreover, the centralized nature of relays makes them susceptible to regulatory pressures and potential censorship of transactions. Validators and builders also have to trust relays to provide valid block headers and not to misappropriate MEV. This trust-based system is fundamentally at odds with Ethereum's trustless philosophy.

2. Addressing Vulnerabilities in Out-of-Protocol Software: The existing out-of-protocol solution, mev-boost, has proven susceptible to attacks, such as the "Low-Carb Crusader" unbundling that exploited a relay vulnerability, leading to a loss of over 20 million USD. This incident underscores the fact that relays are attractive targets outside of the protocol. Additionally, the relay response to the unbundling attack destabilized consensus, resulting in a fivefold increase in reorged blocks.

3. Eliminating Inefficiencies of Side-Car Software: Maintaining compatibility between beacon clients and relays incurs significant coordination costs. Each hard-fork necessitates substantial work from the relay and core developers to ensure mev-boost continues functioning. This involves designing the builder spec, maintaining/improving the relay spec, and making software changes on the beacon clients, mev-boost, and the mev-boost relays. Because mev-boost is out-of-protocol, this coordination is in addition to the standard ACD pipeline and usually occurs later in the development cycle.

Reasons Not to Enshrine PBS

1. Current Stability of mev-boost: mev-boost has been effective to date and has seen widespread adoption, accounting for approximately 90% of Ethereum blocks produced. As the implementation continues to mature, confidence in its security properties can be built and the specification can be further developed. If a neutral way to fund a set of relays can be found, then it might be feasible to continue relying on them.

2. Potential for Other Tools to Mitigate MEV: There is ongoing work to protect users from MEV at the application/transaction level. Solutions like SUAVE, CoW swap, and MEVBlocker are gaining traction. If a significant portion of MEV can be safeguarded, enshrining PBS might be an unnecessary step on an already ambitious roadmap.

3. Resource Allocation: The Ethereum roadmap has numerous goals beyond ePBS. If we decide to proceed with ePBS, it raises the question of where this can fit on the roadmap and what upgrades will be postponed as a result. For instance, ePBS depends on Single-Slot Finality (SSF) for security and complexity reasons, and a validator set consolidation is a prerequisite for any SSF progress.

Protocol-Enforced Proposer Commitments(PEPC)

PEPC, or Protocol-Enforced Proposer Commitments, is a concept that aims to enhance the market structure of the Proposer-Builder Separation (PBS) in Ethereum proposed by Barnabé Monnot. It provides a flexible framework for proposers to make their own commitments, which are then secured by the protocol to prevent any reneging after the builder has delivered the block. Here's a summary:

1. PEPC's Purpose: PEPC aims to generalize the market structure to include more commitments than just the execution payload. It anticipates future needs where builders might be required to produce blocks for Danksharding, or where state providers might need to support block construction and witness computation for stateless proposers. PEPC could also accommodate the need for validity proofs based on a canonical zkEVM to be attached to an execution payload.

2. Flexibility: PEPC could potentially allow the proposer to control precisely how their block is being made. This could include summoning parallel execution-builders, auctioning off block building rights ahead of time, and more.

3. How PEPC Works: PEPC allows a proposer to include additional validity conditions to their block. These conditions could specify requirements such as the execution payload must be signed by a particular builder, or the block witness must be signed by a specific state provider. The hope is to use the EVM to provide a language to express such commitments.

4. Unanswered Questions: There are several open questions about how PEPC would work in practice. These include how builder promises of payment should be represented, how complex the commitments can be, and how PEPC would mesh with protocol-captured value.

In essence, PEPC is a proposal for a more flexible and adaptable market structure within the PBS framework, allowing for a wide range of commitments and conditions to be specified by proposers and secured by the protocol.

Optimistic Relaying

Optimistic Relaying is an iterative approach to Proposer-Builder Separation (PBS) in Ethereum proposed by Mike Neuder and Justin Drake. It offers a "bottom-up" approach to PBS, contrasting the traditional "top-down" approach where a design is fleshed out, a specification is written, and then implemented by client teams. Here's a summary:

1. Concept: Optimistic Relaying leverages the existence of mev-boost and mev-boost relays to gradually shift towards a full ePBS implementation. By modifying the relay, it's possible to progress towards ePBS without needing to alter the specification or make changes to the consensus node software. This approach allows for testing and mitigating risks associated with full ePBS features while maintaining agility.

2. Relay Responsibilities: The main theme of the optimistic roadmap is to reduce relay responsibilities, which improves the operational efficiency of running a relay. This is crucial as relay operation is expensive and currently performed as a public good. By lowering the entry barrier for relay operators, a more sustainable future for mev-boost is enabled as ePBS details are fleshed out.

3. Block Submission in mev-boost: In the mev-boost relay, processing builder bids is the main function of the relay, incurring the highest latency and compute costs. The relay must handle all builder submissions, simulate the blocks on the Execution Layer (EL) clients, and serve as a data availability layer for the execution payloads. The validator also relies on the relay to publish the block in a timely manner once they sign the header.

4. Optimistic Relaying v1: The first version of optimistic relaying removes the block validation step from the block submission pipeline. This means that once the builder block is received by the relay, it is immediately eligible to win the auction and be signed by the proposer. The risk here is that an invalid block may unknowingly be signed by the validator, resulting in a missed slot. To mitigate this risk, the relay holds builder collateral and uses it to refund the proposer if a bad builder block results in a missed slot.

5. Optimistic Relaying Endgame: The final iteration of optimistic relaying behaves more like the Two-Block HeadLock (TBHL) design of ePBS. Instead of the attesting committee enforcing the rules, the relay serves as a centralized "oracle" for the timeliness of events in the bidpool. Builders now directly submit bids to the peer-to-peer (p2p) layer, and proposers observe these bids and sign the corresponding header of the winning bid. The relay observes the bidpool and checks for timeliness of the proposer's signed header and the builder's block publication. The relay still holds builder collateral to refund a proposer if they sign a header on-time, but the builder doesn’t produce a valid block.

In summary, Optimistic Relaying is an innovative approach to gradually implementing ePBS in Ethereum. It reduces relay responsibilities, improves operational efficiency, and allows for a more sustainable future for mev-boost.

Conclusion

The Proposer-Builder Separation (PBS) scheme and its enshrined or in-protocol version (ePBS) represent significant advancements in Ethereum's evolution. These concepts aim to decentralize block validation, maximize block profitability, and eliminate single points of failure in the system. The introduction of Protocol-Enforced Proposer Commitments (PEPC) and Optimistic Relaying further enhance the flexibility and adaptability of the PBS framework.

However, these advancements are not without challenges. The debate on whether the protocol should intervene in the principal-agent problem continues, and the resource allocation for implementing ePBS needs careful consideration. Moreover, the reliance on relays in the current PBS system raises concerns about centralization and potential vulnerabilities.

Despite these challenges, the ongoing innovations in Ethereum's PBS, such as PEPC and Optimistic Relaying, show promise in addressing these issues. They offer potential solutions for creating a more flexible, efficient, and secure system for block construction and validation.