The current game between Ethereum consensus and MEV starts from the day PoW switches to PoS...

Written by Tia, Techub News

The process of solving the MEV problem is actually to re-formulate the allocation rules of block space. I believe 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 supplementary background information. Therefore, this article has sorted out a series of questions about the governance of MEV since Ethereum shifted to PoS. Proposals such as PBS, ePBS, and PEPC, I hope to provide you with some background information.

PBS (Proposer Builder Seperatioin)

Before the Ethereum merger, the way to solve MEV was by using MEV-Geth developed by Flashbots. MEV-Geth is a modified go-ethereum client. The core idea is to allow miners to focus on their job - mining, rather than participating in MEV competition, thereby avoiding potential restructuring issues that may arise. The mechanism of MEV-Geth is very simple. It is a market-oriented solution, that is, when miners package blocks, they can choose based on the profit of the bundle submitted by the searcher. Through this ingenious market-oriented mechanism, all parties can gain benefits while also forming certain constraints. Although the searcher needs to share part of the profits with the miners, what it gets in exchange is a safer guarantee against being stolen by the miners. When searchers, the main source of profits, are trapped, miners will also passively start using MEV-Geth, and will 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 searcher bundles. By imposing reputation constraints on miners and removing miners who steal searcher's results from the whitelist, miners can be prevented from robbing searcher's MEV profits.

But after the merger, since the block generation method changes to randomly selecting proposers from validators to propose blocks, the reputation constraint method to prevent proposers from snatching MEV is no longer feasible.

A possible solution is to make the block contents invisible to validators. A further improvement along this line of thinking is PBS (Proposer Builder Seperatioin, Proposer Builder Seperatioin). PBS further deconstructs the responsibilities of the proposer's verifier into block construction and block proposals, and outsources the complex construction rights that may involve competing for interests to the builder. In this way, the proposer's work becomes very simple, and only needs to Blocks are proposed based on the builder's profit from submitting the block.

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

Because there are other issues that need to be solved, such as how to ensure that the builder will definitely pay the proposer, and will definitely disclose the block content to the proposer at the end so that the proposer will not be penalized for submitting a blank block; such as how to ensure Ensure that the blocks submitted by the builder will be included in the beacon chain, etc. These issues of protecting the rights and interests of builders and proposers are mainly realized through relay.

Builder will send the blocks to the relay, and then the relay will sort the blocks according to the profit that can be obtained from each block, and then send the block header with the highest profit to the proposer to ensure that the proposer understands the block content Invisible. The relay will not disclose the complete block to the proposer until the proposer commits to the block proposal (signs the block header). The fee paid by the builder to the proposer also requires the help of a relay to ensure completion. The transaction paid to the proposer is included in the submitted block, but since the proposer cannot see the content of the block, it still needs to be confirmed by the relay in advance.

In protocol & out protocol

In order to participate in the market built by MEV-Boost, the verifier needs to run a third-party non-Ethereum client while running the Ethereum consensus client and execution client. MEV-Boost program. This is the magic of the currently running PBS, which allows third parties outside the protocol to participate in the design of rules for the consensus formation of Ethereum. From an ownership perspective, 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, as there may be situations where external protocols make changes to existing mechanisms. When the protocol itself begins to lag behind, such changes may begin to sprout from the outside. The sprouting of external mechanisms must meet the current market demand, but whether the external mechanism is credible and whether it is rigorously designed to prevent the emergence of potential problems. , and even external mechanisms that may undermine the agreement are not yet known.

Centralized Relay

MEV-Boost has been criticized the most for its centralized relay market. But this setup introduces trust issues. Builders need to trust the relay not to steal their MEV. Proposers must also trust that the block headers they receive and sign from the relay are valid. However, despite their vital role, there is no financial incentive for relays, and running them requires a significant expense. Last year, there were 11 relays supporting the Ethereum network, but today, only 9 relays are still providing services.

It is worth noting that relay does not require permission. Relays such as Eden only relay their own builders. There are also relays such as bloXroute that claim to filter out transactions related to front-running and sandwich attacks. To some extent, relay also has certain rule-making rights.

数据来自Rated Network

And, from the perspective of Liveness, due to the existence of relay, atomic level confirmation cannot be provided between builder and proposer. If the proposer signs a commitment to the block header and the builder also provides the payload content, but the relay fails to submit the content in time (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 parts outside the protocol into the protocol, encapsulating PBS into Ethereum’s ePBS seems to have become a must. Currently, 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 complete the outsourcing of block construction rights. The role of builder, which was originally outside the protocol, has been included in the protocol, that is, one more role of builder is split among the validators. The builder as a validator also needs to complete the pledge in Ethereum. Since the responsibilities of the original proposer of the consensus layer have been split, completing ePBS requires changes to the consensus layer. 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 beacon blocks. The specific process is as follows:

1. 在知道被选为 Proposer 后，制作并广播 Inclusion List（IL，即在该 slot 中必须包含的交易）。

2. builder 们将包含了 execution payload 的区块哈希以及愿意支付给 proposer 费用的承诺「SignedExecutionPayloadHeader」发送给 proposer（execution payload 需满足 IL）

3. proposer 从 builders 发来的「SignedExecutionPayloadHeader」中选择一个将其纳入（通常会选支付给 proposer 价格最高的那个）。并广播提议的信标区块「SignedBeaconBlock」。

4. 见证者履行见证职责

5. Aggregators 提交 attestation aggregates；同时，builder 广播 execution payload

6. PTC（Payload Timeliness Committee，每个 slot 中，都会有 512 个验证者会被选为 PTC 成员）检查 builder 是否及时揭示 execution payload，并对结果进行广播

ePBS 从提出到最终获取 EIP 编号中间也经历了多次讨论。最初 PBS 由 Vitalik在 21 年 6 月提出，4 个月后完善了Two-slot这一方案，又过了 3 个月，推出了Single-slot PBS，直到 23 年 7 月，PTC的想法才被正式提出。

PEPC（Protocol-Enforced Proposer Commitments）

当然，也有不赞同 ePBS，希望用其他方案来代替的。PEPC 就是如此。ePBS 是将一种确定的规则嵌入协议之中，但在 PEPC 这里，proposer 出售的是可编程的区块构建权。

PEPC 是 barnabe 在 2022 年 10 月提出的。barnabe 认为，如果要将 PBS 机制放到协议内来实现，应当考虑实现一种用于可信信号传递的通用机制，而不是实现某一特定可信信号的机制（比如如果让我构建区块的话我会返还给你 xx ETH）。

就像 PEPC（Protocol-Enforced Proposer Commitments）的名字一样，一些确保 builder 以及 proposer 权益的机制是通过 proposer 在协议内提交的 commitment 来完成的，这些 commitments 是能够在链上进行验证的，主要由操作码 「BEACONROOT」来实现。这是一个更通用的机制，commitment 可以是将区块构建权全部外包，也可以是只外包一部分区块，即 proposer 出售的是可编程的区块构建权。

小结

The above is the detailed content of The current game between Ethereum consensus and MEV starts from the day PoW switches to PoS.... For more information, please follow other related articles on the PHP Chinese website!