Merge pull request #201 from thogiti/pbs

Modularize ePBS page into separate wiki pages for better accessibility and add cross links

docs/_sidebar.md

@@ -60,6 +60,10 @@
     - [PBS](/wiki/research/PBS/pbs.md)
     - [MEV-boost](/wiki/research/PBS/mev-boost.md)
     - [ePBS](/wiki/research/PBS/ePBS.md)
+    - [PTC](/wiki/research/PBS/PTC.md)
+    - [ePBS Design Specs](/wiki/research/PBS/PTC-Specs.md)
+    - [PEPC](/wiki/research/PBS/PEPC.md)
+    - [TBHL](/wiki/research/PBS/TBHL.md)
   - Proof of Stake
     - [Upgrades](/docs/wiki/research/Beacon%20Chain%20Upgrades.md)
     - SSF

docs/wiki/research/PBS/PTC.md

@@ -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/PTC-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/PTC-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

docs/wiki/research/PBS/TBHL.md

@@ -0,0 +1,67 @@
+# The Two-Block HeadLock (TBHL) proposal for ePBS
+
+The Two-Block HeadLock (TBHL) design represents an innovative approach to [proposer-builder separation (PBS)](/docs/wiki/research/PBS/pbs.md) within the Ethereum protocol, aiming to address both the operational and [strategic issues posed by MEV](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/). This design is a nuanced iteration of previous proposals, integrating elements of Vitalik Buterin's two-slot design and enhancing it with a headlock mechanism to safeguard builders from proposer equivocations. Here, we delve into the key components of TBHL and its operational mechanics, drawing on the detailed explanation provided[^1].
+
+## TBHL Design Overview
+
+TBHL modifies the conventional slot structure in Ethereum, introducing a dual-block system within a single slot timeframe, effectively producing a proposer block and a builder block. This system retains the essence of a single execution payload per slot, though with an additional round of attestations, potentially extending the slot duration. TBHL aligns closely with Ethereum's existing LMD-GHOST mechanism and adheres to six specified design properties, ensuring compatibility and integrity within the Ethereum ecosystem.
+
+## Slot Anatomy and Operational Phases
+
+![Slot Anatomy of TBHL](/docs/wiki/research/img/scaling/Slot-Anatomy-of-TBHL-Mike.png)
+
+
+_Figure – The slot anatomy of TBHL. Credit by mike neuder and justin drake._
+
+The operational framework of TBHL is structured around four critical timestamps within a slot, delineated for specific actions by proposers, builders, and attesters:
+
+1. **t=t0 - Proposal of the Winning Bid:** The proposer begins by evaluating bids within the bidpool, a peer-to-peer (P2P) topic where builders submit their bids. Upon selecting a bid, the proposer publishes a proposer block before moving to the next phase.
+
+2. **t=t1 - Attestation Deadline for Proposer Block:** Here, the attesting committee assesses the timeliness of the proposer block. They vote for the first observed block, or in its absence, vote for an empty slot.
+
+3. **t=t1.5 - Equivocation Check:** The attesting committee for the builder block evaluates the proposer blocks for equivocations. A unique proposer block prompts a proposer boost for the associated builder, enhancing the fairness and integrity of the process.
+
+4. **t=t2 - Builder's Verification and Block Publication:** Builders verify their selection as the unique winner. In the event of an equivocation, they can produce a block containing proof to revert their payment. Otherwise, they proceed to publish their builder block, containing the transaction contents.
+
+5. **t=t3 - Second Attestation Deadline:** This phase involves another round of attestations, this time for the builder block, solidifying its position within the blockchain.
+
+## Satisfying ePBS Design Properties
+
+TBHL effectively addresses several critical ePBS design properties:
+
+- **Honest Builder Publication and Payment Safety:** Protection mechanisms ensure that builders can confidently publish blocks, with safeguards against proposer equivocations.
+
+- **Honest Proposer Safety:** Commitments made by honest proposers are respected, with their blocks receiving necessary attestations and unconditional payments proceeding unless equivocation proof is presented.
+
+- **Permissionlessness and Censorship Resistance:** The design promotes an open and competitive environment for builders while maintaining measures to combat censorship.
+
+- **Roadmap Compatibility:** TBHL is poised to integrate seamlessly with Ethereum's roadmap, including single-slot finality (SSF) and MEV-burn mechanisms, illustrating its adaptability and foresight in addressing future network needs.
+
+## Engineering Challenges of implementing TBHL
+
+Implementing TBHL proposal introduces several nuanced challenges and engineering issues, reflective of the complex interplay between Ethereum's consensus mechanism, the dynamic MEV landscape, and the protocol's overarching design philosophy. Drawing from the detailed exploration within the ePBS discussion, here are the primary implementation issues and engineering drawbacks associated with TBHL:
+
+- **Increased Protocol Complexity** TBHL significantly alters the traditional slot structure by introducing a dual-block mechanism within a single slot, complicating the consensus process. This complexity arises from managing two distinct types of blocks (proposer and builder blocks) and necessitates additional rounds of attestations to validate each. The complexity is further amplified by the need to detect and manage proposer block equivocations, requiring robust mechanisms to ensure builder safety and payment security.
+
+- **Slot Timing and Network Latency** Implementing TBHL requires careful consideration of slot timing, as the additional attestation rounds could potentially extend the slot duration. This adjustment impacts network latency, potentially affecting the timeliness of block propagation and attestation aggregation. Ensuring the network's ability to efficiently handle these processes without introducing significant delays or vulnerabilities is a substantial engineering challenge. Besides increasing slot duration change is a very big engineering project in Ethereum post merge as it requires changes to CL, EL and other smart contracts layers.
+
+- **Equivocation and Builder Safety Mechanisms** One of the critical components of TBHL is its approach to managing proposer equivocations to safeguard builders. Designing and implementing robust mechanisms to detect equivocations, allow builders to provide proof of such occurrences, and revert payments accordingly, introduces significant complexity. These mechanisms must be foolproof to prevent exploitation and ensure the system's integrity, demanding rigorous testing and potential iterations in response to discovered vulnerabilities.
+
+- **Permissionlessness and Censorship Resistance** While TBHL aims to maintain a permissionless environment and combat censorship, achieving these goals within the new framework poses challenges. Ensuring that any builder can submit bids and that proposer blocks fairly represent the competitive landscape requires transparent and secure handling of the bidpool. Moreover, integrating forward inclusion lists or other censorship resistance mechanisms within the TBHL structure necessitates additional protocol considerations to prevent manipulation or exclusionary practices.
+
+- **Compatibility with Existing and Future Ethereum Features** TBHL must seamlessly integrate with Ethereum's current protocol features and be adaptable to future innovations, such as single-slot finality (SSF) and MEV-burn mechanisms. Ensuring compatibility with these evolving aspects of the Ethereum ecosystem demands a forward-looking approach to design and implementation, capable of accommodating adjustments and enhancements without undermining the TBHL framework's integrity or efficacy.
+
+- **Resource and Computational Overheads** The introduction of TBHL introduces new computational and resource overheads, particularly related to handling the increased data volume from the dual-block mechanism and the additional attestation rounds. Optimizing the protocol to manage these demands efficiently, without significantly increasing the computational burden on validators or compromising the network's performance, is an essential engineering concern.
+
+The TBHL proposal stands as a testament to the ongoing efforts to refine Ethereum's PBS mechanisms, striving for a balance between operational efficiency, security, and the overarching ethos of decentralization. By addressing the nuances of proposer-builder dynamics and introducing robust safeguards, TBHL marks a significant step forward in the evolution of Ethereum's protocol design, offering a promising avenue for mitigating the challenges posed by MEV while enhancing the network's resilience and integrity.
+
+You can learn more about different ePBs solutions at [PTC](/docs/wiki/research/PBS/PTC.md) and [PEPC](/docs/wiki/research/PBS/PEPC.md).
+
+## Resources 
+- [Why enshrine Proposer-Builder Separation? A viable path to ePBS](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710/1)
+- [PBS](/docs/wiki/research/PBS/pbs.md)
+- [ePBS](/docs/wiki/research/PBS/epbs.md)
+- [Mike Neuder - Towards Enshrined Proposer-Builder Separation](https://www.youtube.com/watch?v=Ub8V7lILb_Q)
+
+## References
+[^1]: https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710/1