Further Reading: Gate Ventures Research Institute: In-depth Analysis of MEV, Illuminating the Dark Forest (Part 1)

Direction for Mitigating MEV

Within the Ethereum ecosystem, the solution to PBS in the past was outsourced to Flashbots. Flashbots is dedicated to researching the MEV problem in Ethereum, and its latest valuation has reached 1 billion USD. However, due to the lack of economic benefits for Relayers and the high technical and economic thresholds required to implement Relay, Blocknative has abandoned the development of this project. In order to address the issues of trustlessness and zero economic incentives, Ethereum is also considering using e-PBS protocol-level improvements to avoid the existence of Relayers based on the third-party protocol mevboost.

Currently, MEV seems to be a problem that cannot be easily solved, as it is essentially a product of the increased complexity of the ecosystem and the asymmetry of information within user time periods. For Ethereum in the dark forest, especially under the influence of the hacker mindset of permissionless and censorship-resistant, Ethereum cannot conduct a one-time review and improvement at the protocol level to cut off MEV. This is not possible and will not happen. In the Ethereum ecosystem, the focus is more on finding ways to mitigate the negative externalities of MEV and enhance its positive externalities. Many projects, community members, developers, and VCs are exploring some worth-trying methods, which have also led to many potential opportunities. Next, we will briefly introduce some attempts to mitigate negative externalities. In general, all attempts fall into three directions: protocol level, application level, and auction mechanism.

SUVAE

SUAVE (Single Unifying Auction for Value Expression) is proposed by Flashbots to improve the negative externalities of MEV. Similarly, it does not aim to solve MEV, but to guide MEV to become decentralized and transparent.

Architecture of the SUAVE chain, image source: Flashbots

It achieves this by building a new blockchain SUAVE, which incorporates a MEVM virtual machine capable of running EVM smart contracts. The accompanying developer tools can support the development of MEV smart contracts based on the EVM virtual machine. This allows any centralized MEV infrastructure today to be transformed into smart contracts on a decentralized blockchain. This significantly reduces the threshold for creating new MEV applications, maximizes competition between different mechanisms, and brings decentralization and transparency. Finally, it helps to decentralize the centralization problem of the MEV industry chain by allowing centralized infrastructure (builders, relayers, centralized RFQ routing, etc.) to be programmed as smart contracts on a decentralized blockchain.

Supply chain of Rollup transactions, image source: dba:

SUAVE can act as a decentralized sorter and intent recognition machine submitted to the Proposer on the chain, and finally use Ethereum as the settlement layer. Execution nodes will be off-chain, using trusted execution environments or zero-knowledge proof technology. Users can use intent transactions, submit transactions to SUAVE for parsing, and maximize transparent MEV for smart contract bidding, effectively mitigating negative externalities through a transparent market mechanism. At the same time, according to Paradigm's application tax article, it is also suitable to implement application taxes for MEV bot behavior on SUAVE. Paradigm happens to be an advisor and investor in this project.

OFA

Let's take OFA (Order Flow Auction) as an example to see its improvements to the auction mechanism.

OFA auction mechanism, image source: Frontier Research

1. The order initiator (wallet/application) sends the order to OFA, which selectively discloses some information, including the order value, etc. This is the design space.

2. Bidders bid, receive corresponding information, and propose a price they can pay for this order flow, after which Bidders will conduct MEV on this order flow.

3. This private order flow can only be seen by Bidders, and after introducing market competition, it can make MEV more transparent and minimize user losses.

Currently, there are many projects based on the OFA auction mechanism under development, and the overall operation mechanism and process are very similar. The differences lie in the details and implementation methods between the four core components.

Private Transaction Pool Encryption

OFA is similar to building a private transaction pool, but these user orders can only be extracted for MEV by Bidders who win under a certain auction mechanism, and the auction fees are returned to the order owner. In fact, there is still a kind of MEV extraction under this architecture of auction mechanism. The memory privacy pool aims to solve the confidentiality issue for Searchers, as Searchers are the main participants in MEV. Therefore, by using a privacy transaction pool, orders can only be seen by relayers and block builders. Among them, encryption means that users' transactions may require higher Gas fees, which should be optional. Currently, there are several encryption methods worth exploring.

1. Multi-party computation MPC: Multiple participants use MPC, which hides transaction details from multiple participants. MPC can also be applied at the shared sorter to decentralize the centralization rights of a single sorting node.

2. Verifiable Delay Function VDF: This function requires a certain time T to perform the calculation, and once the calculation is completed, its correctness can be quickly verified. Using VDF can make transaction sequencing serial, but it can make the experience very bad for a large number of users, and the delay time T is a trade-off value.

3. Threshold Signature Scheme TSS: Allows multiple participants to jointly participate in the encryption and decryption process without any single participant having complete keys. Threshold encryption can prevent attackers from seeing transaction details before the transaction is confirmed, effectively preventing frontrunning attacks. Compared to MPC, TSS is simpler and more suitable for single signing and private key generation. Shutter Network uses TSS, which allows verifiers to sort and package transactions without knowing the transaction content, thereby preventing MEV attacks.

4. Zero-knowledge proof ZKP, which can verify the correctness of information without disclosing specific information. Currently, its development is mainly constrained by hardware development, and commercialization requires time due to high costs. Automata Network has proposed a privacy relay network called "Conveyor," which uses multi-party computation (MPC) and zero-knowledge proofs to protect transaction privacy while allowing verifiers to perform necessary computations.

Comparison of encryption schemes for private transaction pools, image source: Flashbots

There are various optional encryption algorithms for encrypting private transaction pools, including MPC, TSS, VDF, ZKP, etc., but each encryption algorithm has its drawbacks that developers need to weigh. Projects with exploratory potential include Shutter Network, which uses the TSS algorithm, and Automate Network, which uses MPC and ZKP to address MEV.

Execution Tickets

Execution Tickets is a solution proposed by Justin at the Columbia Cryptoeconomics Workshop to address MEV. This is an improvement at the consensus level and involves three steps:

1. It introduces a Tickets market, where the person who obtains a Ticket is eligible to propose the execution of a block at a future time slot. Through a dynamic pricing mechanism, the circulation of Tickets and the existing supply can be adjusted in real-time. The specific slot for each Ticket is also randomly selected.

2. Blocks are divided into execution and proposal blocks, with block proposers being randomly selected, and execution blocks requiring Tickets for eligibility.

3. Holders of Tickets for execution blocks have the right to propose the execution of a block within the allocated time slot and receive related execution layer rewards (EL Rewards = TX Fees + MEV). Block proposers for execution blocks need to provide collateral to ensure that they generate the execution block in the allocated slot. If they engage in double spending or go offline, the collateral will be confiscated.

Slots are divided into execution rounds and beacon rounds (consensus rounds). When a Ticket is destroyed, it is equivalent to the destruction of the corresponding ETH, increasing the deflationary pressure on ETH. Since execution blocks and consensus blocks are randomly selected, this greatly increases the possibility of collusion between the two, which presents the following issues:

1. However, this mechanism may lead to the problem of multi-block MEV, where purchasing execution Tickets for multiple consecutive blocks may expand the profit from MEV to offset the cost of purchasing Tickets. Therefore, this mechanism requires a well-designed function for changing Ticket prices.

2. This mechanism still does not solve the issue of user MEV sandwich attacks, but rather compensates for user losses through network-wide deflation.

e-PBS

In fact, after the Merge, Ethereum did not implement PBS, meaning that builders and block proposers need to be selected from validators. However, to maximize the economic benefits of the network, MEV-Boost is used as a third-party PBS protocol solution, currently holding 90% of the Relayer market share.

e-PBS (enshrined PBS) is Ethereum's solution to address MEV-boost Relay as a third-party trust-based middleware, incorporating PBS into the consensus level, no longer relying on third-party solutions like Flashbosts. The proposal is codenamed EIP-7732. The goal of this protocol is to enable Ethereum's protocol layer to achieve a trust-minimized PBS solution, capturing the vast majority of MEV through mechanisms within the Ethereum protocol and distributing the captured MEV to participants in a way that maximizes Ethereum protocol interests. This e-PBS is similar to the workflow mentioned in the PBS section, but its feature lies in the elimination of the Relayer role, and the bidding of Builders to Proposers is written as code at the consensus layer.

ePBS execution process diagram, image source: mikeneuder

The above diagram illustrates the Slot N process under the ePBS mechanism:

1. Block broadcast: At t=0, the selected POS validator proposes a consensus layer (CL) block for slot N, which includes the Builder's auction block bid but does not include execution liabilities.

2. Proof deadline: At t=t1, the committee selects the correct block according to forking rules and provides proof.

3. Aggregation of proof and payload propagation: At t=t2, the aggregation proof for Slot N is broadcast for verification. At the same time, builders publish their ExecutionPayload to construct the complete version of the block.

4. PTC voting broadcast: At t=t3, the PTC is responsible for supervising whether the Builder's Payload is constructed according to the rules and determining its timeliness.

5. At t=t4, it is crucial for the proposer of the next block to determine whether the slot N block is considered an empty block or a correctly constructed full block based on the PTC's vote and proof.

It is important to note that to ensure that Builders can submit block payloads in a timely manner within a slot (similar to ensuring that validator committees vote and propose blocks within a certain time frame in Ethereum 2.0), in the protocol-level PBS, Builders still tend to publish Payload content late, providing more opportunities to find MEV. Therefore, the PTC (Payload-Timeliness Committee) is introduced in the protocol to supervise the timeliness of Payload construction. From an economic perspective, the PTC can encourage builders to publish payloads in a timely manner, ensuring the security of Ethereum. If a Builder's Payload is defined as untimely, the Builder will not receive the corresponding execution payload reward.

Block parsing diagram, image source: mikeneuder

Therefore, in ePBS, a complete block requires two parts to be assembled together: an empty CL Block, constructed by the proposer at the beginning of the slot, containing the Execution Payload Header and Builder Bid, but with the specific Payload content temporarily empty. Only after proof aggregation and block propagation, i.e., after the PTC recognizes the validity of the payload, will it be assembled into a complete block (Full Block).

In summary, EIP-7732 ePBS can address:

1. A transparent block auction scheme without the need for a trusted third party intermediary.

2. Separating the consensus layer and the execution layer to reduce the computational load on validators, thereby improving network efficiency and speed.

3. Validators can immediately focus on validating the consensus and defer the validation of execution payloads to a later time, introducing additional time windows and voting mechanisms to ensure efficient operation and fairness of the system, while allowing more time to process execution payloads.

However, some issues that need to be discussed are also raised:

1. Essentially, this only replaces the work of the third-party Relayer in the past to achieve decentralization and transparency in the block proposal process, but it still does not solve the poor MEV experience for users.

2. This upgrade is a change at the consensus layer and is not backward compatible. If the ePBS mechanism design is proven to fail in practice, subsequent patches will be difficult.

3. Suppose in a slot, a proposer publishes a block, but the builder delays the publication of the execution payload for some reason. At this point, some validators may verify based on the proposer's block, while others may wait for the builder's execution payload, leading to network forks. Such forks will increase network instability and maintenance costs.

4. If a proposer intentionally publishes a block close to the proof deadline, it may cause some validators to see the block while others do not, making the behavior of the N+1 Slot Proposer unpredictable and greatly increasing the likelihood of on-chain forks.

PEPC

EigenLayer has also proposed some solutions, including the AVS component PEPC (protocol-enforced proposer commitments) to address the issue of MEV. This component also aims to solve the trust issue of third-party middleware Relayers. The main idea is that when a Proposer submits a CL block, they should attach a PEPC signature as a commitment. The Builder will execute the payload after verifying the Proposer's PEPC, introducing a trust mechanism within the protocol. Through the built-in trust mechanism, the potential trust issue of Relayers as third parties can also be resolved.

References

"The MEVM, SUAVE Centauri, and Beyond": https://writings.flashbots.net/mevm-suave-centauri-and-beyond

"Blockchains, MEV and the knapsack problem: a primer": https://arxiv.org/html/2403.19077v1

"MEV ECOSYSTEM EVOLUTION FROM ETHEREUM 1.0"

"The Future of MEV" by Blockchain Capital

"FRP-18: Cryptographic Approaches to Complete Mempool Privacy" by Flashbots

"Execution Tickets": https://ethresear.ch/t/execution-tickets/17944

"Payload-timeliness committee (PTC) – an ePBS design": https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054

Disclaimer:

The above content is for reference only and should not be considered as any advice. Before making any investments, be sure to seek professional advice.

About Gate Ventures

Gate Ventures is the venture capital department of Gate.io, focusing on investments in decentralized infrastructure, ecosystems, and applications that will reshape the world in the Web 3.0 era. Gate Ventures collaborates with global industry leaders to empower teams and startups with innovative thinking and capabilities, redefining the interaction patterns of society and finance.

Website: https://ventures.gate.io/Twitter: https://x.com/gate_venturesMedium: https://medium.com/gate_ventures

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