The current game between Ethereum consensus and MEV starts from the day when PoW switched to PoS

Written by: Tia, Techub News

The process of solving the MEV problem is actually to reformulate the allocation rules of block space. I believe that everyone is no longer unfamiliar with MEV, but if you want to know what some Ethereum MEV governance proposals are talking about, you may still need some background information. Therefore, this article sorts out a series of proposals for governing MEV since Ethereum turned to PoS, such as PBS, ePBS, and PEPC, hoping to provide some background information for everyone.

PBS (Proposer Builder Seperatioin)

Before the Ethereum merger, the way to solve MEV was to use MEV-Geth developed by Flashbots, which is a modified go-ethereum client. Its core concept is to let miners focus on their job - mining, rather than participating in the MEV competition, so as to avoid potential reorganization problems. The mechanism of MEV-Geth is very simple, and it is a market-oriented solution, that is, miners can choose when packaging blocks according to the size of the bundle profit submitted by the searcher. Through this clever market mechanism, all parties have formed certain constraints while gaining benefits. Although the searcher needs to share part of the profit with the miner, it gets a safer guarantee against theft by the miner. When the searcher, the main source of profit, is encircled, the miner will also passively start to use MEV-Geth and be further constrained by the MEV-Geth mechanism. MEV-Geth will maintain a whitelist of miners, and only miners on the whitelist can receive the searcher's bundle. By constraining the miners' reputation, that is, removing the miners who steal the searcher's results from the whitelist, it can prevent miners from robbing the searcher's MEV profit.

However, after the merger, since the block generation method has changed to randomly selecting proposers from the validators to propose blocks, the reputation constraint method to prevent proposers from robbing MEV is not feasible.  

A possible solution is to make the block content invisible to the validator. A further improvement along this line of thought is PBS (Proposer Builder Seperatioin). PBS further deconstructs the responsibilities of the proposer as a validator into block construction and block proposal, and outsources the complex construction rights that may participate in the competition of interests to the builder. In this way, the proposer's work becomes very simple, and only needs to propose blocks according to the profit size of the block submitted by the builder. Initially, Ethereum wanted to embed PBS into the protocol during the merge, but due to the 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 very important role - relay. The builder does not send the block directly to the proposer, but through a third role, relay.  

Because some other problems need to be solved, such as how to ensure that the builder will pay the proposer and disclose the block content to the proposer in the end to avoid the proposer being fined for submitting a blank block; for example, how to ensure that the block submitted by the builder will be included in the beacon chain. These issues that protect the rights and interests of the builder and proposer are mainly achieved through the relay.  

The builder will send the block to the relay, and then the relay will sort the blocks according to 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 the block proposal (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 completed with the help of the relay. The transaction paid to the proposer is included in the submitted block, but since the proposer cannot see the block content, the relay still needs to help confirm it in advance. In protocol & out protocol In order to participate in the market built by MEV-Boost, the validator needs to run a third-party non-Ethereum MEV-Boost program while running the Ethereum consensus client and execution client. This is the magic of the currently running PBS, which allows third parties outside the protocol to participate in the design of the rules for the formation of Ethereum consensus. From the perspective of ownership, this is incredible. This also triggers thinking about the "credibility" of the protocol mechanism, how credibility is strengthened and how it is eroded through other mechanisms. MEV-Boost is a good example, because there may be situations where external protocols will make changes to existing mechanisms. When the protocol itself begins to lag, such changes may begin to emerge from the outside. The emergence of external mechanisms must be in line with current market needs, but whether the external mechanisms are trustworthy, whether they are carefully designed to prevent potential problems, or even whether the external mechanisms may undermine the protocol, is still unknown.

Centralized Relays

MEV-Boost is criticized most for its centralized relay market. But this setup introduces trust issues. Builders need to trust that relays will not steal their MEV. Proposers must also trust that the block headers they receive and sign from relays are valid. However, despite playing a vital role, relays have no economic incentives and running relays also requires a considerable amount of money. Last year, there were 11 relays supporting the Ethereum network, but today, only 9 relays are still providing services.  

It is worth noting that relays are not permissionless. Relays like Eden only relay their own builders. Some relays like bloXroute claim to filter out transactions related to front-running and sandwich attacks. To some extent, relays also have certain rule-making powers.

Data from Rated Network

And, from the perspective of Liveness, due to the existence of relays, atomic-level confirmation cannot be provided between the builder and the proposer. If the proposer signs a commitment to the block header and the builder also provides the payload content, but fails to submit the content in time due to a relay error (whether malicious or non-malicious), the builder and proposer will suffer losses. ePBS: Encapsulating PBS into Ethereum Whether it is to solve the problem of relay centralization or to move the part outside the protocol into the protocol, encapsulating PBS into ePBS of Ethereum seems to be a must. At present, ePBS is no longer a proposal under discussion, and the Ethereum EIP editor has assigned it a number - EIP-7732. ePBS provides a trustless infrastructure for proposers and builders to outsource block construction rights. The role of the builder, which was originally outside the protocol, has been incorporated into the protocol, that is, a builder role is split out from the validator, and the builder as a validator also needs to complete the pledge in Ethereum. Since the original proposer responsibilities of the consensus layer have been split, the consensus layer needs to be modified to complete ePBS. Among them, the builder is responsible for building the execution payload (the final list of transactions to be executed in the block). The proposer's responsibility is to propose the beacon block. The specific process is as follows:

1. After knowing that it has been selected as a proposer, make and broadcast the Inclusion List (IL, which is the transactions that must be included in the slot).

2. Builders send the block hash containing the execution payload and the commitment to pay the proposer "SignedExecutionPayloadHeader" to the proposer (the execution payload must meet IL)

3. The proposer selects one from the "SignedExecutionPayloadHeader" sent by the builders to include it (usually the one with the highest price paid to the proposer is selected). And broadcast the proposed beacon block "SignedBeaconBlock".

4. Witnesses perform witness duties

5. Aggregators submit attestation aggregates; at the same time, the builder broadcasts the execution 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 time and broadcasts the results

ePBS has also gone through many discussions from its proposal to the final acquisition of the EIP number. PBS was originally proposed by Vitalik in June 21, and the Two-slot solution was improved 4 months later. After another 3 months, the Single-slot PBS was launched. It was not until July 23 that the idea of ​​PTC was formally proposed.

PEPC (Protocol-Enforced Proposer Commitments)

Of course, there are also those who disagree with ePBS and hope to replace it with other solutions. This is the case with PEPC. ePBS embeds a certain rule into the protocol, but 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 implemented in the protocol, a general mechanism for trusted signal transmission should be considered, rather than a mechanism for implementing a specific trusted signal (for example, if you let me build a block, I will return you xx ETH).  

Like the name of PEPC (Protocol-Enforced Proposer Commitments), some mechanisms to ensure the rights of builders and proposers are completed through the commitments submitted by proposers in the protocol. These commitments can be verified on the chain, mainly implemented by the operation code "BEACONROOT". This is a more general mechanism. The commitment can be to outsource all block construction rights or only outsource part of the blocks, that is, the proposer sells programmable block construction rights.

Summary 

The above is a brief introduction to PBS, ePBS, and PEPC. From the perspective of protocol design, it is necessary not only to design a market mechanism for redistributing MEVs, but also to consider how to make validators more decentralized and how to improve censorship resistance. In addition, there are many trade-offs in the design of the protocol. Take ePBS, which has obtained an EIP number, as an example. Although the design of ePBS solves the problem of centralized relay, does the key role of relay, as a third party outside the protocol, really only have negative effects? From the perspective of the builder's payment mechanism, using relay is better than the ePBS mechanism, because ePBS is a prepaid mechanism. If the builder packs a block with super high profits, then it will not be able to provide high returns to the proposer under the prepaid mechanism.