Written by: Tia, Techub News
The process of solving the MEV problem is actually to redefine 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 on MEV governance since Ethereum switched 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 solution to 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 is a market-based solution, that is, miners can choose when packaging blocks based on the size of the profit of the bundle submitted by the searcher. Through this ingenious market-based mechanism, all parties have formed certain constraints while gaining benefits. Although the searcher needs to share part of the profit with the miners, it is in exchange for a safer guarantee against theft by the miners. When the searcher, the main source of profit, is encircled, miners will also passively start to use MEV-Geth and be further constrained by the mechanism of MEV-Geth. MEV-Geth will maintain a whitelist of miners, and only miners on the whitelist can receive the bundle of the searcher. By imposing credibility constraints on miners, that is, removing miners who steal searcher results from the whitelist, miners can be prevented from robbing searcher's MEV profits.
However, after the merger, since the block generation method has changed to randomly selecting a proposer from the validators to propose blocks, the reputation constraint method to prevent the proposer from snatching MEV is no longer 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 Separation). PBS further deconstructs the responsibilities of the validator as a proposer into block construction and block proposal, and outsources the complex construction rights that may participate in the competition for interests to the builder. In this way, the proposer's work becomes very simple, and he only needs to propose blocks based on 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 put on hold, 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 issues need to be resolved, 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, etc. These issues to protect the rights and interests of the builder and proposer are mainly achieved through 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 block 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, 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 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 leads to 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 change existing mechanisms. When the protocol itself begins to lag behind, such changes may begin to germinate from the outside. The emergence of external mechanisms must be in line with current market demand, but whether the external mechanism is credible, whether it has been carefully designed to prevent potential problems, or even whether the external mechanism may destroy the protocol, is still unknown.
Centralized Relay
The most criticized aspect of MEV-Boost is its centralized relay market. But this setup introduces a trust problem. 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 such as Eden only relay their own builders. 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 powers.
Data from Rated Network
Moreover, from the perspective of liveness, due to the existence of relay, the builder and proposer cannot provide atomic-level confirmation. If the proposer signs the commitment on the block header and the builder also provides the payload content, but fails to submit the content in time due to the relay's error (whether malicious or non-malicious), both the builder and the 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 Ethereum's ePBS 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, an additional builder role is split out from the validator, and the builder as a validator also needs to complete the pledge on Ethereum. Since the original responsibilities of the proposer in 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:
After knowing that it has been selected as the Proposer, it creates and broadcasts the Inclusion List (IL, i.e. the transactions that must be included in this slot).
The builders send the block hash containing the execution payload and the promise to pay the proposer the fee "SignedExecutionPayloadHeader" to the proposer (the execution payload must meet IL)
The proposer selects one of the "SignedExecutionPayloadHeader" sent by the builders to include (usually the one with the highest price paid to the proposer), and broadcasts the proposed beacon block "SignedBeaconBlock".
Witnesses perform their duty to bear witness
Aggregators submit attestation aggregates; at the same time, builders broadcast execution payloads
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 also went through many discussions from its proposal to its final acquisition of the EIP number. PBS was first proposed by Vitalik in June 2021, and the Two-slot solution was perfected four months later. Three months later, Single-slot PBS was launched. It was not until July 2023 that the idea of PTC was officially proposed.
PEPC (Protocol-Enforced Proposer Commitments)
Of course, there are also those who disagree with ePBS and hope to use other solutions instead. PEPC is such a case. ePBS embeds a certain rule into the protocol, but in PEPC, the proposer sells the 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).
Just like the name of PEPC (Protocol-Enforced Proposer Commitments), some mechanisms to ensure the rights of builders and proposers are completed through 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. Commitments can be outsourcing all block construction rights or only outsourcing 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 MEV, but also to consider how to make validators more decentralized and how to improve censorship resistance. In addition, there are many trade-offs in protocol design. Take ePBS, which has already obtained an EIP number, as an example. Although the design of ePBS solves the problem of centralized relay, does the key role of relay, 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.
