TL;DR

• ePBS is designed with a focus on Builder security, granting Builders full control over block transactions.
• It integrates Proposer-Builder Separation (PBS) directly into Ethereum’s consensus layer, referred to as In-Protocol PBS, to address potential relay failures and eliminate system single points of failure.
• ePBS continues PBS’s foundation by reducing a single entity’s control over block content, enhancing network censorship resistance and decentralization.
• The Payload Timeliness Committee (PTC) ensures the timeliness and validity of transactions in new blocks.

Introduction

In February, Prysm developer Potuz raised concerns about trust issues in Ethereum’s mainnet, suggesting a delay of the Electra fork until 2025, using the Interoperability Event to refine the ePBS design. However, there were mixed opinions within the Ethereum community, with some developers and researchers worried about the potential risks. Opinions on ePBS are divided, so today we will explore what ePBS is and how it differs from PBS.

Previously, we mentioned that the PBS mechanism ensures the security of the Proposer’s commitment and the Builder’s explanation by assigning this responsibility to trusted relays. Relays store block content and ensure that the Proposer receives the block content but cannot easily steal the Builder’s content. However, if the relay is malicious, both the Proposer and Builder can be harmed, and they can only switch to another relay and hope it is not malicious. This presents a problem: we must find a trusted third party for delegation. PBS is an off-chain solution that depends on community consensus and voluntary compliance, requiring additional coordination and trust.

In PBS, there must be an intermediary role to act as a third-party trust handler:

• Proposers must trust the intermediary if they want to sell block content rights.
• Builders must trust the intermediary if they want to purchase block-building rights.

Revolutionary Design of ePBS

Built-In Proposer-Builder Separation

Enshrined Proposer-Builder Separation (ePBS) is a variant of PBS integrated directly into Ethereum’s consensus layer, also known as In-Protocol PBS. It was designed to address potential relay failures and eliminate system single points of failure. As an emerging consensus mechanism, we will now delve into ePBS, explaining its core principles, advantages, and how it differs from traditional Proposer-Builder Separation (PBS).

PBS replaces the need for a trusted relay role by using the Ethereum protocol itself. If either the Proposer or Builder acts maliciously, Ethereum’s protocol can impose penalties (such as confiscation), removing the dependency on trusting a third-party role. This is the major difference from PBS, where trust is external.

Despite this, the separation of roles in ePBS still follows the original PBS structure, reducing a single entity’s control over block content, thus enhancing the censorship resistance and decentralization of the blockchain network.

• Proposer: Responsible for proposing the block, including block header information.
• Builder: Responsible for constructing the block’s content.

Two Major Benefits

Direct Punishment for Malicious Actions & No Need for Third-Party Trust

From its name, it’s clear that the term “Enshrined” in ePBS reflects its protocol-integrated design, enabling direct punishment for malicious behavior. This integration subtly transforms the trust model within the system.

1. Built-in Capability for Detection and Enforcement

   In PBS, identifying and penalizing malicious actions relies on third-party intervention, such as validators or relays. In contrast, ePBS, being protocol-native, allows the protocol itself to directly detect and handle misconduct without requiring external involvement.

2. Reduced Reliance on Third Parties, Enhancing Decentralization

   PBS inherently depends on external governance or third parties, which introduces an element of trust centralization. ePBS, however, embeds rules within the protocol, fundamentally reducing reliance on external trust. This shift enhances the decentralization of the system, making it more robust and resistant to manipulation.

*Comparison between Traditional PBS and ePBS👇

ePBS Design

The Dance of Execution and Verification

In Ethereum’s Proof of Stake (PoS) system, the time for each slot is divided into 12-second intervals. In each slot, a validator is randomly chosen to propose a block, and a committee is assigned to verify the block’s validity. If a block is not proposed during the given slot, the responsible validator will verify the previous block after 4 seconds.

Source: ethresearch, one ePBS slot will be processed by the Consensus Layer (CL) and Execution Layer (EL). Block information is broadcasted in the consensus layer, and then the block is submitted to the execution layer for verification.

1. Block Bidding Phase: The Builder starts bidding and sends the bid to the Proposer.
2. Proposer Broadcasting: The Proposer selects the winning bid and decides whether to use the Inclusion List to construct the block content, then broadcasts the block.
3. Validator Voting: Upon seeing the block, validators vote based on their verification results.
4. Aggregate Attestation: Aggregated attestations are created by Aggregators, who combine multiple validators’ proofs for the same block. Validators then use the aggregated attestation to verify the block.
5. Payload Broadcasting: The Builder must publish the complete execution payload within the designated time.
6. PTC Voting: The Payload Timeliness Committee (PTC) supervises and verifies whether the Builder’s payload is timely and valid.
7. The next slot’s Proposer publishes their block, building it on either a full or empty block based on the PTC’s voting results and the aggregated attestations. A block with a higher percentage of timely PT votes is considered a full block.

PTC - Ensuring Timeliness and Validity of Transactions in New Blocks \ The Payload Timeliness Committee (PTC) ensures that transactions in new blocks are timely and accurately added. This committee consists of validators (521 members borrowed from the beacon chain committee), who check if the Builder has completed the block’s transaction fillings and if these transactions are executed correctly according to the rules before the end of each block creation cycle.

In simple terms, the PTC acts like a supervisory team, ensuring that the Builder submits their work on time and includes the correct transactions in the block. If the Builder does well and submits the required block on time, the PTC confirms it through voting. This way, the network can identify which blocks are complete and valid, and which ones might have issues or be incomplete.

Through the voting mechanism, the PTC influences whether a block is considered a “full block” or an “empty block.” If the PTC verifies the timeliness and correctness of the payload, the block is recognized as a “full block.” If there is no payload or the payload is delayed, the block may be marked as an “empty block.” Based on the PTC’s vote, the network directly rewards or punishes the Proposer and Builder to incentivize timely and accurate block construction.

• Full Block: The block contains a complete set of valid payload, potentially including multiple transactions, and the transaction execution state is updated in a timely manner.
• Empty Block: The block contains very few or no transactions at all. It may be a CL block, but it does not update the EL state.
• Missing Block: A slot is empty. This refers to a block that was expected but not created or successfully added to the chain. Missing blocks can be classified as full or empty based on the (block, slot) fork choice vote.

ePBS’s Censorship Resistance, Combined with the Inclusion List Design

While the core design of ePBS revolves around Builder security and grants Builders full control over block transactions, implementing the Inclusion List makes it a perfect combination for achieving censorship resistance and decentralization.

In our previous articles, we discussed the CL process (for more details, please visit: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg). In brief, the Proposer provides the Builder with a list of transactions that should be prioritized. This list should include all currently active transactions, regardless of whether they are in the transaction pool. As long as there is space left in the block, transactions from the list should be included in the Builder’s block. If the block is full, the Builder must clearly indicate and confirm that they have acknowledged the list.

When a Builder tries to censor certain transactions, the base fee will rise quickly due to the implementation of EIP-1559, as blocks are filled continuously with transactions. If the Builder insists on adding fake transactions to the block to perform censorship, the rising fees will make such actions cost-prohibitive and impractical.

Summary

ePBS separates the roles of Proposer and Builder through its protocol integration. With the PTC acting as a subset of the verification committee, it is responsible for voting on the validity and timeliness of the Execution Payload released by the Builder. The core advantage of ePBS lies in its shift from relying on trusted third parties to being overseen and penalized directly by the Ethereum protocol itself, reducing the need to trust a single entity. This not only enhances the system’s censorship resistance but also strengthens transaction protection through mechanisms like the Inclusion List, making the cost of censoring transactions prohibitively high and impractical.

It’s important to note that ePBS provides an option for block Proposer-Builder separation at the protocol level, rather than being mandatory. The key distinction between ePBS and other models is in their payment mechanisms and trust models. When considering the trust issues of the entire protocol, the cost to be paid is the need to commit to paying fees in advance. In contrast, MEV-Boost allows for payments to the Beacon Proposer based on the profits derived from the Execution Payload sequenced, offering more room for profitability. Perhaps one day, ePBS could evolve to a point where upfront fee commitments are no longer necessary—this is a small hope for the future!

Reference

@ttsao/epbs-faq0"">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

Disclaimer：

1. This article is reprinted from [Uncommons], All copyrights belong to the original author [Jocelyn]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.