Authored by: Tia, Techub News

The process of solving the MEV problem is actually a redefinition of the allocation rules for block space. MEV is no longer unfamiliar to everyone, but if you want to know what some Ethereum MEV governance proposals are talking about, you may still need some additional background information. Therefore, this article sorts out a series of governance proposals related to MEV after Ethereum's transition to PoS, such as PBS, ePBS, and PEPC, hoping to provide some background information.

PBS (Proposer Builder Separation)

Before the Ethereum merge, the way to solve MEV was through the use of MEV-Geth developed by Flashbots. MEV-Geth is a modified go-ethereum client. Its core idea is to allow miners to focus on their primary job - mining, rather than participating in MEV competition, thus avoiding potential reorganization issues. The mechanism of MEV-Geth is simple, it is a market-based solution, where miners can choose which bundle to include in the block based on the profit submitted by the searcher. Through this clever market mechanism, all parties not only obtain benefits but also form certain constraints. Although the searcher needs to share some of the profits with the miner, what they get in return is a more secure guarantee against miner theft. When the main source of profit for the searcher is locked in, miners will passively start using MEV-Geth and be further constrained by the mechanism of MEV-Geth. MEV-Geth maintains a whitelist of miners, and only miners on the whitelist can receive the bundle from the searcher. By constraining the reputation of miners and removing miners who steal the searcher's results from the whitelist, it is possible to prevent miners from seizing the MEV profit of the searcher.

However, after the merge, the method of preventing proposers from seizing MEV through reputation constraints is no longer feasible because the block proposal method has changed to randomly selecting a proposer from the validators.

A possible solution is to make the block content invisible to the validators. Following this idea, PBS (Proposer Builder Separation) was further improved. PBS further deconstructs the responsibility of the validator as a proposer into block construction and block proposal, outsourcing the complex construction rights that may be involved in profit competition to the builder. In this way, the work of the proposer becomes very simple, just choosing the block to propose based on the profit submitted by the builder.

Initially, Ethereum wanted to embed PBS into the protocol during the merge, but due to potential complexity, this process was shelved, giving MEV-Boost the opportunity to intervene in PBS. Currently, PBS is implemented through MEV-Boost developed by Flashbots. In addition to the builder and proposer, there is another important role - relay. The builder does not send the block directly to the proposer, but through a third role, the relay.

Because there are still some other issues to be resolved, such as how to ensure that the builder will definitely pay the fee to the proposer and will definitely disclose the block content to the proposer at the end to avoid the proposer being penalized for submitting empty blocks; how to ensure that the block submitted by the builder will definitely be included in the beacon chain, etc. These issues that safeguard the interests of the builder and proposer are mainly implemented through the relay.

The builder will send the block to the relay, and then the relay will sort the blocks based on the profit that each block can obtain, and then send the block header with the highest profit to the proposer to ensure that the proposer cannot see the block content. After the proposer makes a commitment to propose the block (signs the block header), the relay will disclose the complete block to the proposer. The fee paid by the builder to the proposer also needs to be ensured with the help of the relay. The transaction paid to the proposer is included in the submitted block, but because the proposer cannot see the block content, it still needs to be confirmed in advance by the relay.

In protocol & out protocol

In order to participate in the market constructed by MEV-Boost, validators need to run a third-party non-Ethereum MEV-Boost program while running the Ethereum consensus client and execution client. This is the magic of PBS currently running, it allows third parties outside the protocol to participate in the design of Ethereum's consensus rules. From the perspective of ownership, this is incredible.

This also raises considerations about the "credibility" of the protocol mechanism, how credibility is strengthened, and how it is eroded by other mechanisms. MEV-Boost is a good example because external protocols may change the existing mechanisms. When the protocol itself begins to lag, such changes may start from the outside, and the emergence of external mechanisms must meet current market demand, but whether the external mechanisms are trustworthy, whether they are carefully designed to prevent potential problems, and even whether the external mechanisms may disrupt the protocol, all of this is still unknown.

Centralized Relay

MEV-Boost is most criticized for its centralized relay market. However, this setup introduces trust issues. The builder needs to trust that the relay will not steal their MEV. The proposer also has to trust that the block header received and signed from the relay is valid. However, despite playing a crucial role, the relay has no economic incentive, and running a relay also requires a considerable expense. Last year, there were 11 relays supporting the Ethereum network, but now, only 9 relays are still in service.

It is worth noting that relays are not without admission requirements, such as Eden, which only relays its own builder. Some relays, such as bloXroute, claim to filter out transactions related to frontrunning and sandwich attacks. To some extent, relays also have a certain rule-making power.

The data is from Rated Network.

Furthermore, from the perspective of Liveness, due to the existence of the relay, it is impossible for the builder and proposer to provide atomic-level confirmation. If the proposer signs a commitment to the block header and the builder provides the payload content, but due to a mistake by the relay (whether malicious or not), the timely submission of the content cannot be made, causing losses for the builder and proposer.

ePBS: Embedding PBS into Ethereum

Whether it is to solve the centralization problem of the relay or to move the part outside the protocol to the inside, embedding PBS into Ethereum seems to be a necessary option. Currently, ePBS is no longer just a proposal under discussion; it has been assigned an Ethereum Improvement Proposal (EIP) number - EIP-7732.

ePBS provides a trustless infrastructure for proposers and builders to outsource the right to construct blocks. The role of the builder, which was originally outside the protocol, is now included in the protocol, meaning that a role of the builder is split from the validators and the builder as a validator also needs to stake on Ethereum. Since the responsibility of the proposer at the consensus layer has been split, making ePBS requires changes to the consensus layer. In this process, the builder is responsible for constructing the execution payload (the final list of transactions to be executed in the block), and the proposer's responsibility is to propose the beacon block. The specific process is as follows:

1. After being selected as the proposer, create and broadcast the Inclusion List (IL), which must include certain transactions in that slot.
2. The builders send the block hash containing the execution payload and the commitment to pay the proposer to the proposer (the execution payload must meet the IL).
3. The proposer selects one from the "SignedExecutionPayloadHeader" sent by the builders (usually the one with the highest payment to the proposer) and broadcasts the proposed beacon block "SignedBeaconBlock".
4. Validators fulfill their witnessing duties.
5. Aggregators submit attestation aggregates; at the same time, builders broadcast the execution payload.
6. The Payload Timeliness Committee (PTC) checks whether the builder timely reveals the execution payload and broadcasts the results for each slot.

ePBS went through several discussions from its proposal to obtaining an EIP number. Initially, PBS was proposed by Vitalik in June 2021, and four months later, the "Two-slot" proposal was improved, followed by the introduction of "Single-slot PBS" three months later. It was not until July 2023 that the idea of PTC was formally proposed.

PEPC (Protocol-Enforced Proposer Commitments)

Of course, there are also dissenting voices against ePBS, hoping to replace it with other solutions. This is where PEPC comes in. While ePBS embeds a specific rule into the protocol, in PEPC, the proposer sells programmable block construction rights.

PEPC was proposed by barnabe in October 2022. Barnabe believes that if the PBS mechanism is to be put into the protocol, a general mechanism for trusted signal transmission should be considered, rather than a specific trusted signal mechanism (such as "if you let me build the block, I will return xx ETH to you").

Just like the name suggests, some mechanisms to ensure the rights of the builder and proposer are completed through commitments submitted by the proposer within the protocol. These commitments can be verified on-chain and are mainly implemented using the "BEACONROOT" opcode. This is a more general mechanism; the commitment can be to outsource all block construction rights or only a part of the block, meaning that the proposer sells programmable block construction rights.

Conclusion

The above is a brief introduction to PBS, ePBS, and PEPC. From the perspective of protocol design, it is not only necessary to design a market mechanism for reallocating MEV but also to consider how to make the validators more decentralized and how to increase resistance to censorship. Additionally, there are many trade-offs in protocol design. Taking ePBS, which has obtained an EIP number, as an example, although the design of ePBS solves the problem of centralized relay, is the role of the third-party relay outside the protocol really only negative? From the perspective of the builder's payment mechanism, using the relay is actually more advantageous than the ePBS mechanism because ePBS is a prepaid mechanism, and if the builder packages a block with a very high profit, it will be unable to provide a high return to the proposer under the prepaid mechanism.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。