The current game between Consensus and MEV in the Ethereum network starts from the day when it transitions from PoW to PoS...

Written by: Tia, Techub News

The process of solving the MEV problem is actually to redefine the allocation rules of Block space. For MEV, I believe everyone is no longer unfamiliar, but if you want to know what some ETH Block MEV governance proposals are talking about, you may still need some background information, so this article sorts out a series of proposals on governance MEV after ETH turns to PoS, such as PBS, ePBS, and PEPC, hoping to provide some background information for everyone.

PBS（Proposer Builder Seperatioin）

Prior to the ETH merge, the way to address MEV was through the use of MEV-Geth developed by Flashbots, which is a modified go-ethereum client. Its core concept is to allow Miners to focus on their primary job - Mining, rather than participating in MEV competition, thus avoiding potential reorganization problems. The mechanism of MEV-Geth is simple and a market-oriented solution, where Miners can choose to package Blocks based on the size of the bundle profit submitted by the searcher. Through this clever market mechanism, all parties benefit while also forming certain constraints. Although the searcher needs to share some profits with the Miner, it in turn brings a guarantee of being protected from Miner theft. When the main source of profit from the searcher is enclosed, Miners will also be forced to start using MEV-Geth and further constrained by its mechanism. MEV-Geth will maintain an Allowlist of Miners, and only Miners on the Allowlist can receive the bundle submitted by the searcher. By constraining the reputation of Miners, i.e. removing Miners who steal searcher results from the Allowlist, it can prevent Miners from grabbing MEV profits from searchers.

However, after the merger, the method of generating blocks changed to randomly selecting a proposer from validators to propose the Block. The way of reputation constraint to prevent proposers from grabbing MEV is no longer feasible.

One possible solution is to make the Block content invisible to validators. Along this line of thinking, a further improvement is PBS (Proposer Builder Separation). PBS further deconstructs the responsibility of validators as proposers into Block construction and Block proposal, outsourcing the complex construction rights that may be involved in the interest dispute to builders. In this way, the work of proposers becomes simple, only needing to select and propose Blocks based on the profitability submitted by builders.

Initially, ETH wanted to embed PBS into the protocol during the merge, but due to potential complexity, the process was put on hold, thus 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 also an important role - relay. The builder does not directly send the Block to the proposer, but through a third role called 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 in the end to avoid the proposer from being slashed for submitting an empty Block; for example, 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 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 content of the Block. After the proposer makes a commitment to propose the Block (sign the Block header), the relay will disclose the complete Block to the proposer. The fee paid to the proposer by the builder also needs to be ensured by the relay to be completed. The transaction paid to the proposer is included in the submitted Block, but because the proposer cannot see the content of the Block, 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 the ETH Ethereum Consensus client and execute the client, while running a third-party non-ETH MEV-Boost program. This is the magic of the currently running PBS, which allows third parties outside the protocol to participate in the rule design formed by the Consensus of the Ethereum. From the perspective of ownership, this is incredible.

This has also triggered thinking about the “credibility” of the protocol mechanism, how credibility is strengthened, and how it can be eroded by other mechanisms. MEV-Boost is a good example because there may be external protocols that will modify existing mechanisms. When the protocol itself begins to lag, such changes may emerge externally. The emergence of external mechanisms must meet the current market demand, but whether external mechanisms are trustworthy, whether they are designed rigorously to prevent potential problems, or even whether they may disrupt the protocol, is still unknown.

Decentralized Relay

MEV-Boost is most criticized for its centralized relay market. But this setup introduces trust issues. Builders need to trust that relays will not steal their MEV. Proposers also have to trust that the Block Headers they receive and sign from the relay are valid. However, despite playing a crucial role, Relays have no economic incentives 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 relay is not without admission. Relays like Eden only relay their own builder. Some relays, such as bloXroute, claim to filter out transactions related to front-running and sandwich attacks. To some extent, relays also have certain rule-making power.

Data from Rated Network

Moreover, from the perspective of Liveness, due to the existence of the relay, atomic level confirmation cannot be provided between the builder and the proposer. If the proposer signs the commitment of the block header and the builder also provides the payload content, but due to the relay’s mistake (whether malicious or non-malicious), the timely submission of the content cannot be made, both the builder and the proposer will suffer losses.

ePBS: Wrapping PBS into Ethereum

Whether it is to solve the centralization problem in relay or to move the parts outside the protocol into the protocol, encapsulating PBS into ePBS of Ethereum seems to be a must. Currently, ePBS is no longer a proposal under discussion, and Ethereum’s EIP editor has assigned it a number - EIP-7732.

ePBS provides a trustless infrastructure for proposers and builders to outsource the construction of Blocks. The role of the builder, who was originally outside the protocol, is now incorporated into the protocol as a separate builder role within the validators. As a builder of validators, they also need to stake on the Ethereum blockchain. As the responsibilities of the original proposer are split in the Consensus layer, modifications to the Consensus layer are required to complete ePBS. The builder is responsible for constructing the execution payload (the final list of transactions to be executed in the Block). The proposer’s role is to propose the beacon Block. The specific process is as follows:

1. After knowing that it has been selected as a Proposer, create and broadcast the Inclusion List (IL), which must include the transactions in this slot.
2. The builders include the Blockhash containing the ution payload and the commitment to pay the proposer fees ‘SignedutionPayloadHeader’ to the proposer (the ution payload must meet IL)
3. The proposer selects one of the ‘SignedutionPayloadHeader’ sent from the builders and includes it (usually the one with the highest price paid to the proposer) and broadcasts the proposed beacon block ‘SignedBeaconBlock’.
4. Witnesses fulfill their witnessing duties
5. aggregators submit attestation aggreGates; at the same time, builder broadcasts ution payload
6. PTC (Payload Timeliness Committee, in each slot, 512 validators will be selected as PTC members) checks whether the builder reveals the execution payload in a timely manner and broadcasts the result.

ePBS went through multiple discussions from proposal to finally obtaining the EIP number. Originally proposed by Vitalik in June 21, it was perfected with the Two-slot proposal four months later, and then the Single-slot PBS was introduced three months after that. It was not until July 23 of 23 that the PTC’s idea was officially proposed.

PEPC（Protocol-Enforced Proposer Commitments）

Of course, there are also dissenting opinions on ePBS, hoping to replace it with other solutions. PEPC is one such example. ePBS embeds a specific set of rules into the protocol, but in the case of PEPC, the proposer sells the Programmability’s Block construction right.

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

Just like the name of PEPC (Protocol-Enforced Proposer Commitments), some mechanisms that ensure the rights and interests of builders and proposers are achieved through commitments submitted by proposers within the protocol. These commitments can be verified on-chain and are mainly implemented by Operation Code ‘BEACONROOT’. This is a more general mechanism, where the commitment can be to outsource all Block construction rights, or only a part of it, that is, the proposer sells the Programmability of 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 the redistribution of MEV, but also to consider how to make validators more decentralized, and how to increase censorship resistance. In addition, there are many trade-offs in protocol design. Taking ePBS, which has already obtained the EIP number, as an example, although the design of ePBS solves the difficult problem of centralized relay, is it really only negative for third-party relay, a key role outside the protocol? From the perspective of the builder’s payment mechanism, the use of relay is actually more advantageous than the ePBS mechanism, because ePBS is a prepayment mechanism. If the builder packages a Block with super high profit, it will be unable to provide a high return to the proposer under the prepayment mechanism.