Crisis of Confidence experiment ePBS's protocol built-in

TL;DR

• The core design of ePBS is built around the concept of Builder security, which grants the Builder full control over Block transactions.
• ePBS is a proposal to directly incorporate PBS into the Ethereum consensus layer, known as In-Protocol PBS, aiming to address potential Relay failures and eliminate single points of failure within the system.
• ePBS still follows the foundation of the original PBS, increasing the network's censorship resistance and Decentralization by dropping the ability of a single entity to control Block content.
• The Payload Timeliness Committee (PTC) serves as a supervisory role to ensure the timeliness and validity of transaction content in the new blocks.

Preface

In February, Prysm developer Potuz believed that there was a trust issue with the Ethereum mainnet and advocated for delaying the Electra fork until 2025 to improve the ePBS design using the Interop event. However, the Ethereum community holds different views on ePBS, with some developers and researchers concerned about the potential risks it may bring. Opinions on ePBS vary, so today we will understand what ePBS is and how it differs from PBS.

Previously, we mentioned that the mechanism of PBS is to ensure the security of the Proposer's commitment and the security of the Builder's interpretation, so this right is entrusted to the trusted Relay. The Relay is responsible for keeping the Block content, ensuring that the Proposer will receive the Block content but cannot easily steal the Builder's Block content. However, if the Relay is malicious, both the Proposer and the Builder will be harmed, and they can only turn to cooperate with other Relays and hope that other Relays are not malicious. There is a problem here that we must find a trusted third party for trust delegation. Because PBS is a solution outside the protocol. PBS relies on community consensus and voluntary compliance, requiring additional coordination and trust.

In PBS, there must be a middleman role as a third-party credit-granting party to handle the issue:

• If the Proposer wants to sell the rights to Block content, they must trust the middleman.
• Builders must trust the middleman to purchase the right to build Blocks.

The revolutionary design of ePBS

Built-in Proposer-Builder Separation

Enshrined Proposer-Builder Separation (ePBS) is another variant derived from PBS. ePBS is a proposal to directly incorporate PBS into the Consensus layer of the ETH network, hence it is also known as In-Protocol PBS. Its birth is to address potential Relay failures and eliminate the need for single point of failure within the system. As an emerging Consensus Mechanism, we will delve into ePBS next, aiming to clarify its core principles, advantages, and differences from the traditional Proposer-Builder Separation (PBS).

ePBS, which stands for Embedded Proposer-Builder Separation, is a mechanism built into the blockchain protocol. It replaces the trusted Relay role in the Ethereum protocol. If either the Proposer or Builder behaves maliciously, they can be penalized (slashing) by the Ethereum protocol itself, without relying on trust in a specific role. This is the biggest difference between the entire protocol and the previously mentioned PBS protocol.

Of course, the role separation in the application of ePBS still follows the original PBS, increasing the censorship resistance and decentralization of the Block chain network by dropping the control of a single entity over Block content.

• Proposer: Responsible for proposing a Block, including the Block header information
• Builder: Construct the specific content of the Block

Two Major Benefits

Directly penalize misconduct and do not require third-party credit

From the name, we can see that Enshrined in ePBS means that the protocol will be built in, which will directly punish malicious behavior and cause a quiet transformation in the trust center under this setting.

1. The protocol has the ability to identify and process, and directly punish

In PBS, the identification and punishment of malicious behavior rely on the intervention of third parties (validators, relays, etc.). In ePBS, however, due to its design within the protocol, malicious behavior can be directly identified and handled by the protocol itself.

1. No need to credit third parties, improve the degree of Decentralization

To some extent, PBS relies on external governance or third parties, which involves trust centralization. In contrast, ePBS reduces the reliance on external third parties by embedding the rules into the protocol, thereby enhancing the degree of decentralization of the system.

*Comparison Chart of Traditional PBS and ePBS

ePBS Design

The Dance of Execution and Verification

In the ETH POS, the time of the slot is divided into intervals of 12 seconds. In each slot, a validators is randomly selected to propose a Block. At the same time, a committee is designated to verify the validity of the Block. If a Block is not proposed in a given slot, the validators responsible for the proof will verify the previous Block after 4 seconds.

source: ethresearch, an ePBS slot will be processed by CL (consensus layer) and EL (execution layer). Block information is broadcasted at the consensus layer, and then the block is submitted to the execution layer for validation.

1. BlockBidding phase: Bulider will start Bidding and send it to Proposer.
2. proposer broadcast: The Proposer selects Bidding and chooses whether to use the Inclusion List to build their own Block content. Then broadcast the Block.
3. validators vote: After seeing the Block, they will vote based on its validation result.
4. Aggregate attestation: Aggregate attestation is created by aggregators, who aggregate the attestations of multiple validators for the same block. Validators validate through aggregate attestation.
5. Payload broadcast: The Builder needs to publicly disclose the complete and valid execution payload within the specified time.
6. PTC Voting: Special Committee to Supervise and Verify the Timeliness and Effectiveness of Builder's Payload.
7. The Proposer of the next slot publishes their Block, based on the voting results of PTC and the aggregated proof to construct a Full Block or an Empty Block. When the percentage of timely published PT votes in a Block is higher, it will be considered as a Full Block.

PTC, Supervise the timeliness and effectiveness of transaction content in the new blockchain

The Payload Timeliness Committee (PTC) is responsible for ensuring that the transaction content in a new Block is added in a timely and accurate manner. The committee is composed of validators (borrowed from the Beacon Chain Committee as part of the committee, with 521 members) whose job is to check whether the Builder has completed the transaction filling work of the Block before the end of each Block creation cycle, and whether these transactions are executed correctly according to the rules.

Simply put, PTC is like a supervisory team, overseeing whether the Builder has submitted their work on time and whether it includes the correct transactions Block. If the Builder does a good job and submits the required Block on time, PTC will confirm this through a vote. This way, the network can determine which Blocks are complete and valid, and which ones may have issues or be incomplete.

Through the voting mechanism, PTC influences the status of whether a Block is considered a 'complete block' or an 'Empty Block'. If PTC verifies the timeliness and correctness of the payload, the Block can be recognized as a 'complete block'; if there is no payload or the payload submission has latency, the Block may be marked as an 'Empty Block'. Then, based on the voting results of PTC, the network directly rewards or punishes the Proposer and Builder to incentivize timely and accurate Block construction.

• Full block: Block contains a set of valid payload, which can also contain multiple transactions, and the transaction execution status will be updated in a timely manner.
• Empty Block (empty block): A block that contains almost no transactions, or only a very small number of transactions. It can be a CL block, but it will not update the EL state.
• Missing block: an empty slot. A block that is expected to exist in the blockchain but has not been created or successfully added to the on-chain block. Missing blocks can be classified as either full blocks or empty blocks through the (block, slot) fork choice voting.

The implementation of ePBS's censorship resistance, combined with the design of the Inclusion List

Although the design core of ePBS is built around the concept of Builder security, it grants the Builder full control over Block transactions. Therefore, applying the Inclusion List on this basis will be a perfect combination that can achieve resistance to censorship and Decentralization.

In our previous articles, we mentioned CL and briefly described the process (for details, click the link: undefined).** Provide this list to the Builder and prioritize these transactions. It should cover all current active transactions, whether they are in the transaction pool or not. As long as there is remaining space in the Block, the transactions in the list should be included in the Builder's Block. If the Block is full, the Builder should explicitly indicate and confirm that they have noticed this list.

When the Builder tries to review certain transactions, the implementation of EIP-1559 will cause the Block continuously filled with transactions to rapidly rise the base fee. If the Builder insists on reviewing by adding fake transactions in the Block at this time, the increasing cost will make this behavior too costly to be practical.

Summary

ePBS separates the roles of proposers and builders through the built-in protocol. PTC, as a subset of the proof committee, is responsible for voting on the validity and timeliness of the Execution Payload published by the Builder. Its core advantage is that it transforms the traditional role of trusted third parties into supervision and punishment by the Ethereum protocol itself, thereby reducing the need to trust a single entity. It not only enhances the system's censorship resistance, but also strengthens transaction protection through mechanisms such as the Inclusion List, making the cost of reviewing transactions high and impractical.

Additionally, ePBS only provides an option to separate the Block Proposer and Builder at the protocol layer, rather than being mandatory. Their main differences lie in the payment mechanism and trust model. When considering the trust issue of the entire protocol, the cost that needs to be paid is the commitment to pay the fee in advance. Compared with ePBS, MEV-Boost can decide the amount paid to the Beacon Proposer based on the profits realized in the sorted Execution Payload, which has more profit and space. Perhaps one day, when the mechanism of ePBS is implemented without the need to consider the commitment fee, we hold a little fantasy and expectation!