What is PEPC?

PEPC (pronounced “pepsi”) stands for Protocol-Enforced Proposer Commitments. PEPC was originally proposed in the post “Unbundling PBS”, published in Oct. 2022 before Devcon 6. It is intended as an enshrined protocol gadget allowing validators (”proposers”) to enter into binding commitments over the blocks they produce.

Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC)

The simplest mental model for PEPC is as a generalisation of PBS. Today, validators overwhelmingly delegate the construction of their block to specialised parties known as “builders”. This delegation is operated out-of-protocol by the MEV-Boost marketplace, where trusted relays guarantee the fair exchange of builder items (full blocks) against proposer signatures, without which the builder items remain invalid.

ePBS intends to enshrine some model of proposer/builder separation (PBS) in the Ethereum protocol, by enshrining the fair exchange in the rules of the protocol. Ethereum validators will be responsible for ensuring atomicity of builder block delivery against the proposer signature. This atomicity is critical to protect proposers and builders alike.

ePBS envisions enforcing a single type of exchange between builders and proposers, for instance, a full block containing a payment to the proposer, in exchange for a signature from the proposer to make the block valid. Many types of exchanges are possible, but ePBS would ultimately enshrine only one of them as a global setting for all proposers. Meanwhile, PEPC asks: what if proposers were able to enter into any programmable contract with builders? This includes a host of block-building primitives such as partial blocks, commitments to orderings and many other ways to segment block building, detailed below in the PEPC use cases.

Why is this useful?

Enshrining mechanisms in-protocol is desirable to boost the mechanism’s credibility beyond that of third-party actors such as relays. By enshrining, the Ethereum community implicitly commits to defending the mechanism, via the control it exercises over validators who execute the protocol. Enshrining also provides additional introspection of the protocol, who becomes aware of certain actions executed in its environment.

Seeing like a protocol

The trade-off: enshrining anything locks in certain outcomes, which may reveal to be suboptimal from various perspectives (political, economic, technical…) To explore this trade-off, we propose a different perspective on PBS, splitting PBS in two layers:

• The market structure: Validators enter into agreements with outside parties (”builders”), and there is a legal system (consensus rules) which guarantees the fair exchange between them.
• The allocation mechanism: The specific shape of the agreements entered into by validators and builders.

<aside> 💡 Devcon 6 presentation on the two layers of PBS

https://www.youtube.com/watch?v=sQQ2UYB3qOI

</aside>

Today, neither layer is enshrined in the protocol. The Builder API, a module in all consensus-layer clients, allows proposers to offer their signature to builders, but this module is not part of the Ethereum consensus rules, nor is the abstraction of a builder ever instantiated there. On the opposite side, ePBS enshrines both the market structure, instantiating the “Proposer” and “Builder” abstractions in the consensus rules of Ethereum, as well as a specific allocation mechanism, for instance, a full block in exchange for a signature.

PEPC sits in the middle, recognising that the fundamental asymmetry in complexity between block construction and block validation means that the market structure is justified, but stopping short of enshrining a specific allocation mechanism regulating the contracts between proposers and builders.

What is the status of PEPC?

PEPC is very much still in the research phase. Since the publication of the “Unbundling PBS” post, PEPC has remained a subject of discussion with collaborators. In my opinion, it has prompted useful discussions around some risks of ePBS and the larger design space, but it has also failed to materialise a concrete design. Current work aims at bridging this gap, but doubts remain over the feasibility and our willingness to use PEPC in its full generality.

• On the feasibility, it had become clear that PEPC would require the same research as ePBS to create a safe mechanism from a consensus perspective, i.e., a reorg- and griefing-resilient mechanism, hence resources were spent to think about PBS designs. This is all the more critical since PEPC would likely need to support multiple deliveries, e.g., two partial builders delivering two partial blocks (see below).
• On the willingness, while tail risks from unlimited commitment power may exist, it is also highly possible to deploy PEPC incrementally, starting from “a PEPCified implementation of ePBS” and adding more capabilities as needed over time.

  • Practically, this would look like including a generic “hook” for proposers to include additional block validity conditions, but initially restricting the hook to allow only for commitments to builders making the whole block. This differs from the ePBS approach of enshrining the commitment to full-block building directly into the consensus logic.

    <aside> 🪝 Functional diagram of a proposer hook

    

    </aside>