-
Notifications
You must be signed in to change notification settings - Fork 94
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Breakdown the long ePBS page into separate pages and create separate …
…specs page (#202) * Fixed issue #173 - static images instead of mermaid script rendering. * remove empty line in the wordlist file * Added missing words to wordlist coming from week9 doc * Adding Potuz's correction on PTC and proposer boost and fixed some grammar. * ePBS design specs overview section is added * Fixed formatting issues and added links to EIPs * Fixed formatting issues * epbs specs new slot anatomy flow section is added. * Adding back the mermaid scripts to render PTC and PEPC workflows. * updated the epbs slot anatomy with the specs * Fixed some formatting issues. * Inclusion List Timeline section is added * Execution Payload Timeline section is added * Payload Attestation Timeline section is added * beacon block timeline section is added * fixed some typos * Honest validator behavior section is added * honest builder behavior section is added * forkchoice section is added * security analysis section is added * fixed typos * Modularize ePBS page into separate wiki pages for better accessibility and add cross links * typos fixed * pbs sidebar reorg * changed the epbs specs URL, simplified PEPC benefits, disadvantages, tradeoffs sections into one section * Fixed missing link to KZG page in the sidebar --------- Co-authored-by: Mário Havel <[email protected]>
- Loading branch information
1 parent
984cd2b
commit aabac6d
Showing
9 changed files
with
907 additions
and
349 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,167 @@ | ||
| # Protocol-Enforced Proposer Commitments (PEPC) | ||
|
|
||
| Protocol-Enforced Proposer Commitments (PEPC), a conceptual extension and generalization of [PBS](/docs/wiki/research/PBS/pbs.md), introduces a more flexible and secure way for proposers (validators) to commit to the construction of blocks. Unlike the existing [MEV-Boost](/docs/wiki/research/PBS/mev-boost.md) mechanism, which relies on out-of-protocol agreements between proposers and builders/relays, PEPC aims to enshrine these commitments within the Ethereum protocol itself, offering a trustless and permissionless infrastructure for these interactions[^1][^2]. | ||
|
|
||
| ## Benefits and Related Trade-offs of PEPC | ||
| - **Enhanced Security and Trustlessness:** | ||
| - **Benefit:** Enforces agreements within the protocol, reducing reliance on external parties and minimizing the potential for manipulation. | ||
| - **Trade-off (Security vs. Overhead):** While security is enhanced, this internalization increases computational demands, potentially impacting network efficiency and scalability. | ||
|
|
||
| - **Increased Flexibility in Block Construction:** | ||
| - **Benefit:** Enables programmable contracts between proposers and builders, supporting diverse block construction scenarios. | ||
| - **Trade-off (Flexibility vs. Complexity):** This flexibility introduces complexity, which could limit participation to technically advanced users and raise barriers to entry. | ||
|
|
||
| - **Decentralization of MEV Opportunities:** | ||
| - **Benefit:** Promotes a more equitable distribution of MEV among validators. | ||
| - **Trade-off (Decentralization of MEV vs. Risk of Centralization):** While aiming to decentralize MEV, the complexity required might still favor larger, more sophisticated operators. | ||
|
|
||
| - **Scalability and Efficiency Improvements:** | ||
| - **Benefit:** Streamlines block construction and validation processes, enhancing overall network scalability. | ||
| - **Trade-off (Long-term Scalability vs. Short-term Performance):** Initial impacts on network performance may occur as validators adjust to new complexities. | ||
|
|
||
| - **Economic Innovation:** | ||
| - **Benefit:** Fosters novel economic models by allowing new types of transactions and block constructions. | ||
| - **Trade-off (Economic Innovation vs. Stability):** Introduces economic models that could disrupt established revenue structures and impact stability. | ||
|
|
||
| ## How would PEPC work? | ||
|
|
||
|
|
||
| ```mermaid | ||
| sequenceDiagram | ||
| participant V as Validator (Proposer) | ||
| participant B as Builders | ||
| participant P as Protocol | ||
| participant N as Network Validators | ||
| V->>V: Define Proposer Commitments (PCs) | ||
| rect rgb(240, 237, 225) | ||
| V->>P: Generate Commit-Block with PCs & Payload Template | ||
| loop Builder Submissions | ||
| B->>V: Submit Blocks/Parts fulfilling PCs | ||
| end | ||
| end | ||
| rect rgb(177,176,159) | ||
| V->>P: Verify Submissions against PCs | ||
| alt Submission satisfies PCs | ||
| V->>V: Incorporate Submission into Block | ||
| V->>N: Publish Finalized Block | ||
| N->>N: Validate Block (Consensus & PCs) | ||
| N->>P: Include Block in Blockchain | ||
| else Submission does not satisfy PCs | ||
| V->>V: Reject Submission | ||
| end | ||
| end | ||
| ``` | ||
|
|
||
| _Figure – PEPC flow._ | ||
|
|
||
| The operation of PEPC involves several key components and steps, which together ensure its seamless integration into the Ethereum ecosystem. Here’s an overview of how PEPC would work in practice: | ||
|
|
||
| **Step 1: Commit Phase** | ||
|
|
||
| - **Proposal Creation:** A validator (proposer) prepares to create a block by defining a set of commitments. These commitments represent agreements or contracts that specify how the block will be constructed. This could include, for example, commitments to include certain transactions, not to include others, or to structure the block in a specific way. | ||
|
|
||
| - **Commit Block Generation:** The proposer generates a commit-block that includes these proposer commitments (PCs) alongside the usual consensus data like attestations. This commit-block does not yet contain the full execution payload but specifies a payload template or placeholders for the expected content based on the commitments. | ||
|
|
||
| **Step 2: Reveal Phase** | ||
|
|
||
| - **Builder Submissions:** Builders, in response to the commitments published by the proposer, submit their proposed blocks or block parts to fulfill the commitments. This might involve submitting specific transactions, execution payloads, or other block components as defined by the initial commitments. | ||
|
|
||
| - **Commitment Verification:** Upon receiving submissions from builders, the proposer or the protocol itself verifies that these submissions satisfy the proposer commitments. This verification process ensures that only those blocks or block parts that meet the predefined criteria are considered for inclusion. | ||
|
|
||
| - **Block Finalization:** Once a submission from a builder is verified to fulfill the proposer commitments, the proposer finalizes the block by incorporating the builder's submission into the payload template or placeholders defined in the commit phase. The finalized block is then published to the network. | ||
|
|
||
| **Step 3: Validation and Inclusion** | ||
|
|
||
| - **Network Validation:** Other validators on the network validate the finalized block, ensuring it adheres to the Ethereum protocol rules and the specific proposer commitments. This step may involve standard block validation procedures, along with additional checks for commitment fulfillment. | ||
|
|
||
| - **Block Inclusion:** Upon successful validation, the block is included in the blockchain. This inclusion is contingent on the block satisfying both the usual Ethereum consensus rules and the specific proposer commitments outlined in the commit phase. | ||
|
|
||
| **PEPC's Mechanisms for Flexibility and Security** | ||
|
|
||
| - **Programmable Contracts:** PEPC allows proposers to enter into various programmable contracts with builders, ranging from full blocks to partial blocks, and even future slot auctions. This versatility enables a tailored approach to block construction, maximizing efficiency and optimizing block space usage. | ||
|
|
||
| - **Atomicity and Trustlessness:** The commit-reveal scheme ensures that either all parts of a commitment are fulfilled, or the block is rejected, maintaining atomicity. This process is enforced by the protocol, reducing reliance on external trust and minimizing the risk of manipulation. | ||
|
|
||
| - **Dynamic Block Construction:** By enabling a dynamic approach to block construction, PEPC allows for the real-time adjustment of block contents based on network conditions, user demands, and emerging opportunities, such as MEV extraction. | ||
|
|
||
| ## PEPC Use Cases | ||
|
|
||
| PEPC offers several compelling use cases[^2]: | ||
|
|
||
| **Full-Block Auctions** | ||
|
|
||
| - Validators auction the right to construct entire blocks to builders. This mirrors the current MEV-Boost mechanism but with enhanced security and trustlessness by embedding the auction within the Ethereum protocol. | ||
| - Ensures a transparent and fair process for block construction, potentially leading to more competitive bidding and better rewards for validators. | ||
|
|
||
| **Partial Block Auctions** | ||
|
|
||
| - Validators can auction portions of a block's space to different builders, allowing multiple parties to contribute to a single block's construction. | ||
| - Increases block space utilization efficiency and encourages diversity in transaction inclusion, mitigating potential centralization in block construction. | ||
|
|
||
| **Parallel Block Auctions** | ||
|
|
||
| - Similar to partial block auctions but with the auction focused on separate, parallel components of block space, enabling a more granular approach to block construction. | ||
| - Offers validators more control over block contents and structure, potentially optimizing for various factors like gas usage, transaction priority, and MEV extraction. | ||
|
|
||
| **Slot vs. Block Auctions** | ||
|
|
||
| - Validators commit in advance to using blocks or block parts from specific builders, differentiating between commitments to "slots" (who will build) versus "blocks" (what will be built). | ||
| - Enhances predictability and planning for both validators and builders, potentially leading to more strategic block construction and MEV extraction opportunities. | ||
|
|
||
| **Future Slot Auctions** | ||
|
|
||
| - Validators auction the rights to construct blocks for future slots, essentially creating futures contracts for block space. | ||
| - Provides market participants with more tools for speculation and hedging, potentially stabilizing income for validators and offering builders advanced planning capabilities. | ||
|
|
||
| **Inclusion Lists** | ||
|
|
||
| - Validators commit to including specific transactions in their blocks, either through direct listing or by adhering to lists provided by third parties. | ||
| - Increases transparency and predictability for transaction inclusion, potentially reducing gas price volatility and improving user experience. | ||
|
|
||
| **Dynamic Block Configuration** | ||
|
|
||
| - Validators use PEPC to adjust block configurations dynamically, responding to real-time network conditions and demands. | ||
| - Enhances network responsiveness and efficiency, potentially improving throughput and reducing congestion during peak periods. | ||
|
|
||
| **Censorship Resistance** | ||
|
|
||
| - By making commitments to include certain transactions or follow specific inclusion patterns, validators can provide guarantees against censorship. | ||
| - Strengthens Ethereum's censorship-resistant properties, ensuring that the network remains open and accessible to all users. | ||
|
|
||
| **Protocol Upgrades and Feature Testing** | ||
|
|
||
| - PEPC can be used to test new protocol features or upgrades in a live environment without risking network stability, by making commitments to include transactions that utilize these features. | ||
| - Offers a safer pathway for innovation and evolution within the Ethereum protocol, allowing for more experimental approaches to development. | ||
|
|
||
| ## Relationship and Differences to EigenLayer | ||
|
|
||
| PEPC and Eigenlayer have a complementary relationship, each addressing different aspects of Ethereum's scalability, security, and decentralization, while also sharing a common goal of enhancing the network's efficiency and flexibility[^3]. | ||
|
|
||
| - **Security Layering:** Eigenlayer introduces a mechanism to extend Ethereum's security to additional layers and services. In contrast, PEPC focuses on embedding more sophisticated and flexible commitment mechanisms within the Ethereum protocol itself. While Eigenlayer seeks to augment Ethereum's security model externally, PEPC aims to enhance the internal workings of the Ethereum main chain, specifically around block proposal and transaction inclusion processes. | ||
|
|
||
| - **Validator Commitments:** Both PEPC and Eigenlayer involve validators making certain commitments, but the nature and scope of these commitments differ. In Eigenlayer, validators might commit to securing additional layers or services by restaking their ETH. In PEPC, validators make commitments regarding the construction of blocks, such as including certain transactions or adhering to specific block construction criteria. | ||
|
|
||
| - **MEV and Transaction Inclusion:** Both projects indirectly address issues related to MEV and transaction inclusion fairness. Eigenlayer can facilitate solutions that mitigate the negative aspects of MEV or improve transaction inclusion through additional consensus layers. PEPC, by allowing for more dynamic and programmable proposer-builder agreements, could lead to a more equitable distribution of MEV opportunities and more transparent transaction inclusion mechanisms. | ||
|
|
||
| **Economic Bound to Security in Eigenlayer** | ||
|
|
||
| In principle, if the value at stake in activities or assets secured by Eigenlayer exceeds the value of staked ETH in Ethereum, the economic incentives could potentially become misaligned, leading to concerns about the sufficiency of security provided [^2]. | ||
|
|
||
| In a broader Ethereum ecosystem context, PEPC and Eigenlayer could be seen as complementary, with Eigenlayer expanding Ethereum's security and utility beyond its core protocol and PEPC enhancing the efficiency and flexibility within the core protocol itself. Implementing both could lead to a scenario where Ethereum not only becomes more efficient and adaptable in handling transactions and block construction but also extends its security guarantees to a broader range of decentralized applications and services. | ||
|
|
||
| ## Resources | ||
| - [Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC)](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879/1) | ||
| - [PEPC FAQ](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4) | ||
| - [EigenLayer protocol](https://docs.eigenlayer.xyz/eigenlayer/overview/whitepaper) | ||
| - [Notes on Proposer-Builder Separation (PBS)](https://barnabe.substack.com/p/pbs) | ||
| - [Mike Neuder - Towards Enshrined Proposer-Builder Separation](https://www.youtube.com/watch?v=Ub8V7lILb_Q) | ||
| - [An Incomplete Guide to PBS - with Mike Neuder and Chris Hager](https://www.youtube.com/watch?v=mEbK9AX7X7o) | ||
| - [ePBS – the infinite buffet](https://notes.ethereum.org/@mikeneuder/infinite-buffet) | ||
|
|
||
| ## References | ||
| [^1]: https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879/1 | ||
| [^2]: https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4 | ||
| [^3]: https://docs.eigenlayer.xyz/eigenlayer/overview/whitepaper |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,105 @@ | ||
| # Payload-Timeliness Committee (PTC) for EPBS | ||
|
|
||
| The Payload-Timeliness Committee (PTC) proposal is a design for enshrining PBS (ePBS) within the Ethereum protocol. It represents an evolution of the mechanism to determine block validity and includes a subset of validators who vote on the timeliness of a block's payload[^1][^2][^3]. | ||
|
|
||
| ## PTC Overview | ||
|
|
||
|
|
||
| ```mermaid | ||
| sequenceDiagram | ||
| autonumber | ||
| rect rgb(240, 237, 225) | ||
| participant V as Validator (Proposer) | ||
| participant C as Attesting Committee | ||
| participant B as Builder | ||
| participant PTC as Payload-Timeliness Committee | ||
| participant N1 as Next Proposer (Slot N+1) | ||
| rect rgb(255, 190, 152) | ||
| Note over V: Slot N begins | ||
| V->>V: Proposes CL block <br>with builder bid at t=t0 | ||
| Note over V: Block contains no ExecutionPayload | ||
| end | ||
| rect rgb(219,188,157) | ||
| Note over C: Attestation deadline at t=t1 | ||
| C->>C: Use fork-choice to determine chain head | ||
| C->>V: Attestation | ||
| end | ||
| rect rgb(212,202,205) | ||
| Note over B: At t=t2 Broadcast of <br>Aggregate Attestations | ||
| C->>C: Begin broadcasting <br>aggregate attestations | ||
| B-->>V: Publishes execution payload <br>if no equivocation seen | ||
| end | ||
| rect rgb(177,176,159) | ||
| Note over PTC: At t=t3 Cast vote for <br>payload timeliness | ||
| PTC->>PTC: Votes on payload <br>release timeliness | ||
| end | ||
| rect rgb(203, 134, 143) | ||
| Note over N1: At t=t4 Propagation <br>of next block | ||
| N1->>N1: Publishes block based on <br>PT votes and attestations | ||
| end | ||
| end | ||
| ``` | ||
|
|
||
| _Figure – Payload-Timeliness Committee Flow._ | ||
|
|
||
|
|
||
| The proposal introduces a new slot anatomy with an additional phase for Payload-Timeliness (PT) votes to propagate. It aims to refine the roles of proposers and builders in the block creation process, ensuring that proposers remain lightweight and unsophisticated entities for the goal of decentralization, and specialized builders can create high-value blocks efficiently. | ||
|
|
||
| 1. **Block Propagation**: An elected Proof-of-Stake (PoS) validator, known as the proposer, broadcasts a CL block at the beginning of their slot (`t=t0`). This block contains a builder's bid but not the actual payload ( i.e. transactions). | ||
| 2. **Attestation Aggregation**: At the attestation deadline (`t=t1`), validators, known as attestors, vote on the perceived head of the chain using their local fork-choice rule. | ||
|
|
||
| 3. **Aggregation & Payload Propagation**: The builder sees the CL block and publishes the execution payload. The validator committee begins to broadcast aggregated attestations. | ||
|
|
||
| 4. **Payload-Timeliness Vote Propagation**: At (`t=t3`), the Payload-Timeliness Committee casts their votes on whether the payload was timely released. | ||
|
|
||
| 5. **Next Block Propagation**: At (`t=t4`), the next proposer publishes their block, deciding to build on either the full or empty block based on the PT votes they've observed. | ||
|
|
||
| #### Honest Attesting Behavior | ||
|
|
||
| Honest attestors will consider the payload-timeliness when casting their votes. Their behavior revolves around the PT votes, which influence the subsequent block choice. The votes indicate whether a payload is present, unavailable, or whether there's been an equivocation by the builder. The weight given to a full or empty block in the fork-choice is based on these PT votes. | ||
|
|
||
| ## Properties and Potential New Attack Vectors | ||
|
|
||
| **Properties**: | ||
|
|
||
| - **Honest-Builder Payment Safety**: If a builder's bid is processed, their payload becomes canonical. | ||
|
|
||
| - **Honest-Proposer Safety**: If a proposer commits to a single block on time, they will receive the payment. | ||
|
|
||
| - **Honest-Builder Same-Slot Payload Safety**: An honest builder can ensure their payload for a slot cannot be overridden by another payload in the same slot. | ||
|
|
||
| **Non-Properties**: | ||
|
|
||
| - **Honest-Builder Payload Safety**: Builders can't be sure their payload will become canonical; the design does not protect from next-slot splitting. | ||
|
|
||
| **Potential New Attack Vectors**: | ||
|
|
||
| - **Proposer-Initiated Splitting**: A proposer could release their block close to the deadline, causing a split in the attesting committee's views. | ||
|
|
||
| - **Builder-Initiated Splitting**: Builders could selectively reveal payloads to part of the committee to influence the next proposer’s block, potentially causing it to be orphaned if the committee’s votes differ significantly. | ||
|
|
||
| **Builder Payment Processing**: | ||
|
|
||
| - Payments are processed if the builder’s payload header is part of the canonical chain and there's no evidence of proposer equivocation. | ||
|
|
||
| ## Differences from Other Designs* | ||
|
|
||
| - The PT votes influence the fork-choice weight but do not create separate forks. | ||
| - The payload view informs subsequent committee votes, which usually align with the proposer. | ||
| - In the current ePBS design[^2][^3], builders receive a proposer boost. They don't explicitly create fork choice weight between different forks. Instead, they boost or "deboost" the current block by revealing or withholding it. | ||
|
|
||
| The [ePBS design specs](/docs/wiki/research/PBS/ePBS-Specs.md) has more details about the implementation specifications and flow. | ||
|
|
||
| ## Resources | ||
| - [Payload-timeliness committee (PTC) – an ePBS design ](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054) | ||
| - [Consider the ePBS](https://notes.ethereum.org/@mikeneuder/consider-the-epbs) | ||
| - [ePBS Breakout Room](https://www.youtube.com/watch?v=63juNVzd1P4) | ||
| - [Notes on Proposer-Builder Separation (PBS)](https://barnabe.substack.com/p/pbs) | ||
| - [Mike Neuder - Towards Enshrined Proposer-Builder Separation](https://www.youtube.com/watch?v=Ub8V7lILb_Q) | ||
| - [ePBS design specs](/docs/wiki/research/PBS/ePBS-Specs.md) | ||
|
|
||
| ## References | ||
| [^1]: https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054 | ||
| [^2]: https://hackmd.io/@potuz/rJ9GCnT1C | ||
| [^3]: https://github.com/potuz/consensus-specs/pull/2 |
Oops, something went wrong.