# ePBS – the infinite buffet <img src=https://storage.googleapis.com/ethereum-hackmd/upload_a9c5214479e17ec81c85503ec28f89f9.png width=61%> *by [mike](https://twitter.com/mikeneuder)* *sept 20, 2023* $\cdot$ ***tl;dr;** – The ePBS discussion has evolved significantly over the past months. With new in-protocol designs, proposed out-of-protocol solutions, and big-picture questions cropping up, we aim to distill and categorize the current themes. This document \*does not\* try to answer any specific question but rather seeks to organize the discourse and serve as a reference point and a living document to be updated as the meta shifts. We examine three categories: (1) in-protocol designs, (2) out-of-protocol proposals, and (3) open questions – each of which has a dedicated section below. The format of this document is an "annotated bibliography" of sorts, with short descriptions and links to further resources.* *In my opinion, the questions in Section 3 are the crux of the debate. Without answers to these questions, discussing the exact mechanics of different ePBS instantiations is a moot point.* $\cdot$ ***Thanks*** *Many thanks to [Barnabé](https://twitter.com/barnabemonnot), [stokes](https://twitter.com/ralexstokes), [Jacob](https://twitter.com/jacobykaufmann), [Justin](https://twitter.com/drakefjustin), [Terence](https://twitter.com/terencechain), [Jon](https://twitter.com/jon_charb), and [Max Wilde](https://twitter.com/AestusRelay) for comments. :-)* --- ### (1) In-protocol designs - [Two-slot ePBS](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980) – *The original ePBS design from Vitalik, in which the attesting committee is partitioned and the builder block is given fork-choice weight.* - [Why enshrine PBS?](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710) – *A high-level view of ePBS discussions and a presentation of HeadLock, a version of two-slot ePBS with stronger protection from equivocations.* - [Reorg probabilities](https://notes.ethereum.org/@mikeneuder/epbs-reorgs) – *A draft document outlining the main issue with granting fork-choice weight to builder blocks – the resulting increase in reorg probabilities.* - [Payload-Timeliness Committee](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054) – *A different version of ePBS in which the builder block receives no fork-choice weight and is instead voted on by a committee.* - [Proposer-initiated splitting](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054#proposer-initiated-splitting-18) – *The key weakness of this design. Could probably be tweaked with two-slot to give \~some amount\~ of fork-choice weight to builder blocks, without making the reorg properties too much worse.* - [Terence's WIP spec PR](https://github.com/terencechain/consensus-specs/pull/1) & [Potuz's WIP spec PR](https://github.com/potuz/consensus-specs/pull/1) - [PEPC](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879) – *A more flexible version of ePBS where proposers can make different commitments to the contents of their block that are enforced by the block-validity conditions.* - [PEPC faq](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4) ### (2) Out-of-protocol proposals - [optimistic relays](https://github.com/michaelneuder/optimistic-relay-documentation/blob/main/towards-epbs.md) – *Experimental relay changes to iterate on the `mev-boost` implementation.* - [Optimistic Relays and where to find them](https://frontier.tech/optimistic-relays-and-where-to-find-them) – *Fleshing out the goals of optimistic relaying.* - [pepc-boost](https://hackmd.io/@oLeaCeNDTl-O01HPNj9_sw/r1eZd51g3n) – *A relay enforced version of PEPC being researched & prototyped by Ethereum Protocol Fellows, Bharath Vedartham and Filip Siroky.* - [pepc-boost-relay repo](https://github.com/bharath-123/pepc-boost-relay) – *WIP relay changes for pepc-boost.* - [pepc-boost-builder repo](https://github.com/bharath-123/pepc-boost-builder) – *WIP builder changes for pepc-boost.* - [pepc-dvt](https://ethresear.ch/t/pepc-dvt-pepc-with-no-changes-to-the-consensus-protocol/16514) – *A proposed use of DVT to enforce commitments made by the proposer through the use of an enforcement committee that needs to agree on the block.* - [mev-boost+](https://research.eigenlayer.xyz/t/mev-boost-liveness-first-relay-design/15) – *A proposal from the EigenLayer team to use restaking to allow proposers to commit to a builder block while still preserving agency to construct a block suffix.* - [Preserving Block Proposer Agency with MEV-boost using EigenLayer](https://hackmd.io/@layr/SkBRqvdC5) – *Original post from Sreeram.* - [mev-boost++](https://research.eigenlayer.xyz/t/mev-boost-liveness-first-relay-design/15#mev-boost-high-level-design-20) – *An extension of `mev-boost+` to incorporate a high-speed DA layer to eliminate the need for the trusted relay.* - [Censorship resistance via restaking](https://www.youtube.com/watch?v=ywJNXIUSqOw) – *Sreeram's 2022 SBC talk about `mev-boost+` and `mev-boost++`.* ### (3) Open questions - *What does bypassability imply?* - *Bypassability is the fact that even if we enshrine PBS, there is no credible way (that I am aware of) to enforce that all of the proposers and builders make use of the protocol instead of continuing to rely on the relays or other out-of-protocol solutions. This is the subject of ["Relays in a post-ePBS world"](https://ethresear.ch/t/relays-in-a-post-epbs-world/16278). That piece argues that it is still worth enshrining PBS to allow the protocol to serve as the "neutral relay" while acknowledging that an out-of-protocol relay market may exist and evolve. What percentage of proposers do we think will bypass the enshrined solution? Is there any way to force participants to make use of the in-protocol solution (e.g., a non-bypassable design – IMO this is an impossibility result because there is no anti-sybil for validators)?* - *What does enshrining aim to achieve?* - *The natural extension of the previous question. Given bypassability, what are we accomplishing by enshrining? Are we building a "relay of last resort"? Are we trying to encourage validators to disconnect from `mev-boost` and make use of the protocol even though the `mev-boost` bids may have higher payments? Are we enshrining as a means to achieve further protocol roadmap items (e.g., mev-burn)? Are further roadmap items still desirable/effective if a majority of activity bypasses ePBS? What percentage of proposers do we need to justify enshrinement? Is there utility in enshrining something that ~95% of validators may choose to bypass? Does eliminating "neutral relays" accelerate vertically integrated builder relays?* - *What are the implications of not enshrining?* - *If we don't enshrine, we explicitly acknowledge that `mev-boost` and/or other out-of-protocol implementations are here to stay. Is that a concession we are comfortable with? If so, neutral relay funding should become a top priority, as these relays are the last line of defense against full centralization of the builder-proposer market. Without ePBS, censorship resistance becomes increasingly important. Should we prioritize this instead of working towards an in-protocol solution for the MEV market? Are we OK with the core protocol depending so heavily on an external market? What does non-enshrinement imply for `mev-boost` as it relates to the EL and CL clients?* - *How much can we rely on altruism and the social layer?* - *If we define "protocol-aligned" behavior as making use of the in-protocol mechanism, how likely are large `ETH` holders to sacrifice a small amount of MEV to not bypass ePBS? If the long-term value proposition of `ETH`, the asset, is a decentralized protocol, could there exist an incentive for large holders to make use of the protocol to ensure the long-term viability of their investment? Is the social layer something we want to lean on in this context?* - *How important is L1 ePBS in a future with L2s and OFAs?* - *If much of the L1 activity migrates to L2s and/or OFAs and other app-layer MEV mitigation tools gain popularity, there may be less MEV exposed at the L1. In that world, ePBS may be less necessary to ensure the decentralization of the validator set. Do we think this is likely to occur? If that occurs, is there a compelling reason to do ePBS regardless?* - *What priority should ePBS have in light of other protocol upgrades?* - *Other important roadmap items might take precedence given the above considerations. With the complexity and lack of clarity around the usage of ePBS, should we instead focus on preserving the censorship resistance properties of the protocol (e.g., enshrine inclusion lists) and aim for other PoS upgrades (e.g., single-slot finality)? It is clear that the MEV market is not in equilibrium, is it OK to experiment with out-of-protocol solutions and not prioritize ePBS as a must-have in the medium term? If the market shifts dramatically, are we confident that we have a design at the ready we can fast-track in an attempt to respond to the situation?* <br><br>