This blog series explores the evolution of Proposer-Builder Separation (PBS) within Ethereum and how Radius brings a new perspective to PBS in the Layer 2 (L2) ecosystem through its Blockspace Network. PBS has become a key concept for improving block production efficiency and decentralization in Ethereum. The article first looks at PBS’s development in Layer 1 (L1) Ethereum, then shifts focus to how Radius aims to optimize L2 revenue through the Blockspace Network, contributing to the broader ecosystem.

The concept of Proposer-Builder Separation (PBS) was proposed to address the issue of centralization in the Ethereum network, where the proposer could monopolize power to maximize MEV (Maximal Extractable Value) profits. A solution was introduced to separate the roles of the proposer, who previously generated and included blocks in the chain, into the builder, who creates the blocks, and the proposer, who includes them in the chain. This separation aims to enhance the efficiency of block production and the fee market, while mitigating network centralization. Let's explore the evolution and development of PBS over time.

• https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725

  In June 2021, Vitalik Buterin, the founder of Ethereum, proposed the concept of Proposer-Builder Separation (PBS), introducing an innovative approach to address block production and the network's MEV (Maximal Extractable Value) issues. At that time, Vitalik suggested separating the roles of proposing blocks (Proposer) and building blocks (Builder) to mitigate centralization caused by MEV extraction in the network.

  The core of PBS is that the Proposer acts as a simple block proposer who receives bids, while the Builder constructs the blocks and submits them to the network. This allows the Builder to optimize the transactions included in the block to maximize profit, and the Proposer evaluates the validity and bid value of each block to select the one that will ultimately be included in the network. This structure helps to alleviate network centralization due to MEV extraction and enables efficient fee market management.

  Vitalik presented various design requirements and implementation ideas to make this PBS structure feasible. This initial proposal laid the foundation for the development of PBS and paved the way for more concrete implementation stages in the future.

• https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177

  The first attempt to realize the concept of PBS was the "MEV-Boost" architecture proposed by Flashbots. This architecture aims to support efficient block production by minimizing the direct connection between the Proposer and the Builder, introducing a trusted intermediary between them. This intermediary is known as a Relay, and it serves as a mediator that receives bids from Builders and passes them on to the Proposer. Through the Relay, the interaction between the Builder and the Proposer becomes more secure and efficient; however, this introduces the issue of trust in the Relay itself. Specifically, it is crucial to ensure that the Relay manages the bids from Builders fairly and accurately relays them to the Proposer. Trust in the Relay's proper handling and fair management of Builder bids is therefore essential.

• https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710#optimistic-relaying-an-iterative-approach-to-pbs-8

  ePBS (Enshrined Proposer-Builder Separation) is a significant upgrade to Ethereum, aiming to enhance security and decentralization by making the interactions between Proposer and Builder more efficient. With the introduction of ePBS, the role of the Relay is greatly reduced, diminishing its function as an intermediary, although some of its roles may still be retained. Instead of managing the bid transmission and verification between the Builder and Proposer, the Relay will adopt a more restricted yet efficient function.

  Even after the implementation of ePBS, the Relay can still assist in bid management and verification between the Builder and Proposer or act as an intermediary to facilitate block creation and submission in specific situations. This means the Relay can continue to play a role in enhancing the network's stability by transparently conveying bid information and monitoring the Proposer's signing of valid bids.

  ePBS not only reduces the operational burden and costs associated with the Relay but is also designed to be compatible with future features such as MEV-burn and censorship resistance. This enhances the stability and efficiency of the Ethereum protocol while offering flexibility for selectively leveraging the Relay's intermediary functions when necessary.

• https://ethresear.ch/t/two-slot-proposer-builder-separation/10980

  To further refine the PBS structure, Vitalik proposed a "Two-slot PBS" structure for Ethereum 2.0 in July 2021. This structure separates the roles of the Proposer, who determines which blocks are included in the blockchain, and the Builder, who actually creates the blocks, while managing this entire process within the protocol itself. By doing so, the aim was to address trust issues and complexities that may arise from external interactions.

  A key change in the Two-slot PBS structure is dividing the single block production process into two slots. In the first slot, the Proposer receives bids from Builders, decides on the block header, and includes it in the Beacon block. In the second slot, the Builder generates the block and includes it in an intermediary block. Through this process, block production is systematically handled within the protocol, with an Attestation Committee validating the block's validity. In this structure, the Beacon block, which records the network state, and the intermediary block, which connects it to the execution block, operate independently to enhance both the efficiency and security of the block.

  However, this structure also presents some challenges. First, the increased time required for block production can reduce network efficiency. Second, the fork-choice rule between the Beacon block and the intermediary block becomes more complex, potentially leading to a higher likelihood of block re-organizations (re-orgs).

• https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054

  To overcome the limitations of the Two-slot PBS structure and further enhance the efficiency and security of block production, the introduction of the Payload Timeliness Committee (PTC) has been proposed. PTC is one of the enhancements to the ePBS structure, providing a mechanism to ensure that the Proposer must include a block from an honest Builder.

  Within this structure, a PTC is formed separately from the Attestation Committee to monitor the timeliness and submission of blocks by the Builder. Once a Builder is selected, the PTC monitors whether the block is submitted on time. If the Builder meets the submission deadline, the PTC votes on the Payload Time to confirm the timely submission of the block. This voting process is crucial in verifying both the submission time and the validity of the block, ensuring a transparent and reliable collaboration between the Proposer and Builder.

While Proposer-Builder Separation (PBS) promotes competitive block creation by separating block production rights, it also poses a limitation by giving Builders full control over which transactions are included in the blocks. To address this, the concept of Inclusion Lists has been proposed. These lists are created by the Proposer and specify a set of transactions that must be included in the next block. This mechanism acts as a safeguard against transaction censorship or monopolistic control by the Builder. By mandating certain transactions for inclusion, it encourages Proposer participation and maintains fairness in block creation, while still preserving the competitive environment fostered by the PBS structure.

• https://eips.ethereum.org/EIPS/eip-7547

  EIP-7547 is a proposal that defines the workings of the Inclusion List mechanism. According to this proposal, the Proposer creates a list of transactions that they want to be included in the block, and the Builder is required to construct the block according to this list. The Inclusion List serves as a fundamental tool for countering censorship, promoting the fair inclusion of transactions, and maintaining balance between the Proposer and Builder.

• https://ethresear.ch/t/no-free-lunch-a-new-inclusion-list-design/16389

  With the adoption of PBS, validators generally outsource block creation to Builders, resulting in a structure where Builders control which transactions are included in the blocks. If the Proposer refuses to accept a block created by the Builder, they risk losing MEV (Maximal Extractable Value) profits. To address this, the concept of the Forward Inclusion List has been proposed. A Forward Inclusion List applies to the next Proposer, requiring them to include certain transactions in their block. This design aims to limit the Builder's power over transaction censorship and return some of the block composition authority to the Proposer, enhancing fairness in transaction inclusion.

  The Forward Inclusion List helps prevent Builders from censoring transactions without restriction and allows the Proposer to set a guaranteed list of transactions for inclusion. This improves the network's resistance to censorship and promotes a more equitable transaction inclusion process.

Currently, Ethereum’s structure operates in a way where validators assigned to each slot within an epoch sequentially propose blocks and receive rewards. However, Execution Tickets propose a new mechanism in which the right to propose a block is sold in the form of tickets. The holder of such a ticket gains the right to propose a block for a given slot. This allows block production rights to be obtained simply through the purchase of a ticket, without the need for staking or validator participation. The goal of this mechanism is to pursue both decentralization and efficiency in block production rights.

• https://ethresear.ch/t/execution-tickets/17944

  Execution Tickets introduce a separation of two core roles within Ethereum:

  • Beacon Chain Validator:

    • Participates in the consensus process of the Beacon Chain, verifying the state of the chain and deciding on block headers.

    • Manages the Inclusion List, which consists of transactions that must be included in the block, thereby ensuring resistance to censorship.

    • Receives rewards based on staked ETH. With reduced computational requirements, it becomes easier for individual stakers to participate, enhancing decentralization.

  • Execution Block Proposer:

    • Anyone can obtain the right to create execution-layer blocks by purchasing an Execution Ticket.

    • A ticket holder is randomly selected for each slot to propose a block, functioning in a lottery-like manner.

    • The Proposer is rewarded through transaction fees and MEV (Maximal Extractable Value) derived from the block.

    • Due to the high uptime, low latency, and significant MEV extraction capabilities required, specialized entities are likely to take on this role.

  This separation allows Validators to focus on decentralized consensus while introducing specialized Execution Block Proposers who can efficiently generate and monetize blocks, thereby enhancing the efficiency and security of the network.

  In the auction for Execution Tickets, if a user secures consecutive slots, they can potentially generate multi-slot MEV (MMEV), extracting more value by controlling several slots in a row rather than individual ones. However, the randomness in the Execution Ticket lottery helps mitigate the risks of MMEV. Since tickets are randomly assigned, it becomes difficult for a user to predictably control consecutive slots, preventing malicious attempts to exploit the network.