Further reading: Gate Ventures Research Institute: In-depth analysis of MEV, illuminating the dark forest (Part 1)
MEV mitigation exploration direction
In the past, the PBS solution within the Ethereum ecosystem was outsourced to Flashbots, which specializes in studying Ethereums MEV problem and has a latest round of valuation of $1 billion. However, since Relayer has no economic benefits and the realization of Relay requires high technical and economic barriers, Blocknative gave up the research and development of this track project. In order to solve the problems of decentralization and zero economic incentives, Ethereum is also considering using e-PBS protocol-level improvements to avoid the existence of Relayer based on the third-party protocol mevboost.
At present, MEV seems to be a problem that cannot be solved well, because it is essentially the inevitable product of the increased complexity of the ecosystem and the information asymmetry within the user time period. For the dark forest of Ethereum, especially under the influence of the hacker idea of permissionless and censorship-resistant, Ethereum cannot review and improve at the protocol level to cut off MEV at one time. This is impossible and will not happen. In the Ethereum ecosystem, more efforts are made to reduce the negative externalities of MEV and enhance its positive externalities. Many projects, community members, developers, and VCs are exploring some ways worth trying, which has derived many potential opportunities. Next, we will briefly introduce some attempts to mitigate negative externalities. In general, all attempts are in three directions: protocol level, application level, and auction mechanism.
SUVAE
SUAVE (Single Unifying Auction for Value Expression) was proposed by Flashbots to improve the negative externalities of MEV. Similarly, it does not resort to solving MEV, but guides MEV to become decentralized and transparent.
SUAVE chain architecture, source: Flashbots
It builds a new blockchain SUAVE with a built-in MEVM virtual machine that can run EVM smart contracts. At the same time, the supporting 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 converted into smart contracts on decentralized blockchains. This greatly reduces the threshold for creating new MEV applications, maximizes competition between different mechanisms, and brings decentralization and transparency. Finally, it helps to disperse the centralization problem of the MEV industry chain by enabling centralized infrastructure (builders, relayers, centralized RFQ routing, etc.) to be programmed as smart contracts on decentralized blockchains.
Rollup transaction supply chain, source: dba:
SUAVE can be used as a decentralized sorter and intent recognition machine to submit to the Proposer on the chain, and finally use Ethereum as the settlement layer. The execution node will be executed off-chain, using a trusted execution environment or zero-knowledge proof technology. Users can use intent transactions, hand over the transaction to SUAVE for parsing, and maximize transparent MEV to conduct MEV auctions between smart contracts, so that negative externalities can be effectively mitigated through transparent market mechanisms. At the same time, according to Paradigms application tax article, for example, the imposition of application taxes on MEV bot behavior is also more suitable for implementation on SUAVE. And Paradigm happens to be the consultant and investor of this project.
OFA
Let’s take OFA (Order Flow Auction) as an example to take a look at its improvements to the auction mechanism.
OFA auction mechanism, source: Frontier Research
The order initiator (wallet/application) sends the order to OFA, and OFA selectively discloses some information, including the order value, etc. This is a design space.
Bidders bid, obtain the corresponding information and propose a price that can be paid for this order flow, and then Bidders will perform MEV on this order flow.
This part of private order flow can only be seen by Bidders, and after the introduction of market competition, MEV can be made more transparent and minimize user losses.
Currently, there are many projects based on the OFA auction mechanism under development in the industry. The overall operating mechanism and process are very similar. The difference lies in the details and implementation methods of the four core components.
Private Trading Pool Encryption
OFA is similar to building a private transaction pool, but these user orders can only be extracted by bidders who win under a certain auction mechanism, and the auction fee is returned to the order owner. In fact, there is still some MEV extraction under this architecture under the auction mechanism. The memory privacy pool hopes to solve the confidentiality problem of Searchers, because Searchers are the main participants in MEV. Therefore, only through the privacy transaction pool, the orders can only be seen by relayers and block builders. Among them, encryption means that users transactions may need to pay higher Gas, which should be optional in itself. There are currently several encryption methods worth exploring.
Multi-party computation (MPC): Multiple parties use MPC, which hides transaction details from multiple parties. MPC can also be applied at the shared sorter to disperse the centralized power of a single sorting node.
Verifiable Delay Function VDF: This function takes a certain amount of time T to calculate, and once the calculation is completed, its correctness can be quickly verified. By using VDF, the transaction order can be changed to serial execution, but it will make the experience very bad in a large number of user environments. The delay time T is a value under a trade-off.
Threshold encryption TSS: allows multiple participants to participate in the encryption and decryption process without requiring any single participant to have the complete key. Threshold encryption can effectively prevent front-running attacks by encrypting the transaction content to prevent attackers from seeing the transaction details before the transaction is confirmed. Compared with MPC, TSS is simpler and more suitable for single signature and private key generation. Shutter Network uses TSS, which allows validators to sort and package transactions without knowing the transaction content, thereby preventing MEV attacks.
Zero-knowledge proof ZKP can verify the correctness of information without publishing specific information. At present, its development is mainly affected by the development of hardware, which is costly and takes time to commercialize. Automata Network proposed a privacy relay network called Conveyor, which uses multi-party computing (MPC) and zero-knowledge proof to protect transaction privacy while allowing verifiers to perform necessary calculations.
Comparison of private trading pool encryption schemes, source: Flashbots
There are many optional encryption algorithms for private transaction pools, including MPC, TSS, VDF, ZKP, etc., but each encryption algorithm has its drawbacks that developers need to weigh. Among them, the exploratory projects include Shutter Network, which uses the TSS algorithm, and Automate Network, which uses MPC and ZKP to solve MEV, which are worth paying attention to.
Execution Tickets
Execution Tickets is a solution to MEV proposed by Justin at the Columbia Cryptoeconomics Workshop. It is an improvement on the consensus level and goes through three steps:
It proposes a Tickets market, where people who obtain Tickets can obtain the qualification to propose execution blocks at a certain time in the future. Through the dynamic pricing mechanism, the number of Tickets in circulation and the price of existing supply can be adjusted in real time. The specific slot for each Ticket is also randomly selected.
It divides blocks into two types: execution and proposal. Block proposers are selected randomly, and a Ticket is required to be eligible for block execution.
The ticket holder of the execution block has the right to propose the execution block within the allocated time period and obtain the relevant execution layer rewards (EL Rewards = TX Fees + MEV). The execution block proposer needs to provide a mortgage to ensure that they generate the execution block in the allocated slot. If they double spend or go offline, the mortgage will be confiscated.
Slots are divided into execution rounds and beacon rounds (consensus rounds). When a Ticket is destroyed, the corresponding ETH is destroyed, which increases the deflationary pressure of ETH. Since the execution block and the consensus block are randomly selected, this greatly increases the possibility of collusion between the two. The problem is:
However, this mechanism will lead to the problem of multiple MEVs, that is, purchasing execution tickets for multiple consecutive blocks, which may increase the profit of MEV to offset the cost of purchasing tickets. Therefore, this mechanism requires a good design of the ticket price change function.
This mechanism still does not solve the problem of user MEV sandwich attacks, but only compensates users losses with the deflation of the entire network.
e-PBS
In fact, after Merge, Ethereum did not implement PBS, that is, both builders and block proposers need to choose from validators, but in order to maximize the economic benefits of the network, MEV-Boost is used as a third-party PBS protocol solution, which currently has a 90% Relayer market share.
e-PBS (enshrined PBS) is Ethereums solution to deal with the trust middleware built by MEV-boost Relay as a third party. It incorporates PBS into the consensus level, and no longer relies on Flashbosts, a third party to provide an out-of-protocol solution. The proposal is codenamed EIP-7732. The goal of this protocol is to enable the Ethereum protocol layer to implement a trust-minimized PBS solution, capture the vast majority of MEVs through mechanisms within the Ethereum protocol, and distribute the captured MEVs to participants in a way that maximizes the benefits of the Ethereum protocol. The e-PBS is similar to the workflow we mentioned in the PBS section, but its feature is that the Relayer role is eliminated, and the Builders bid to the Proposer is written into the consensus layer code.
ePBS execution flow chart, source: mikeneuder
The figure above shows the Slot N process under the ePBS mechanism:
Block broadcast: At t = 0, the selected POS validator proposes a consensus layer (CL) block for slot N, which contains the Builders auction block bid but does not contain execution liabilities.
Proof deadline: At t=t 1, the committee will select the correct block according to the fork rules and prove it.
Aggregate proof and payload propagation: At t = t 2, the aggregate proof of Slot N is broadcast for verification. At the same time, the bulider publishes their ExecutionPayload to build a complete version of the block.
PTC voting broadcast: t=t 3, PTC is responsible for supervising whether the Builders Payload is carried out in accordance with the rules and judging whether its timing is valid.
At t=t 4 , it is crucial whether the proposer of the next block regards the block of slotN as an empty block or a correctly constructed full block, which requires the proposer of the next block to judge based on the vote and proof of PTC.
It is important to note that in order to ensure that the Builder can submit the block load in a timely manner within a Slot (on Ethereum 2.0, it is also necessary to ensure that the validator committee votes and proposes blocks within a certain period of time), in the protocol-level PBS, the Builder still tends to publish the Payload content later, so that there are more opportunities to find MEV. Therefore, the PTC (Payload-Timeliness Committee) is introduced in the protocol. As the name suggests, it is a supervision mechanism for Payload builders. PTC can promote builder to publish payload in time from an economic perspective to ensure the security of Ethereum. If the Builders Payload is defined as untimely, the Builder will not be able to obtain the reward for the corresponding execution load.
Block analysis diagram, source: mikeneuder
Therefore, in ePBS, a complete block needs to be assembled from two parts. One is an empty CL Block, which is constructed by the proposer at the beginning of the slot. It contains the Execution Payload Header and Builder Bid, but the specific Payload content is temporarily empty. Only in the proof aggregation and block propagation stage, that is, after the PTC recognizes the validity of the payload, will it be installed into the block to form a complete block (Full Block).
In general, EIP-7732 ePBS can solve:
A transparent block auction scheme without the need for a trusted third party.
Separating the consensus layer and the execution layer reduces the computational load on validators, thereby improving network efficiency and speed.
Validators are able to focus on validating consensus immediately and defer the validation of the execution load to a later time. The introduction of additional time windows and voting mechanisms ensures the efficient operation and fairness of the system while allowing more time to process the execution load.
However, some issues were raised for discussion:
In essence, this only replaces the work of third-party Relayers in the past to achieve decentralization and transparency in the block proposal process, but it still does not fundamentally solve the users poor MEV experience.
This upgrade is a change to the consensus layer and is not backward compatible. If the mechanism design of ePBS is proven to fail in practice, subsequent patches will be difficult.
Suppose in a slot, the proposer publishes a block, but the builder delays publishing the execution payload for some reason. At this time, some validators may verify based on the proposers block, while others may wait for the builders execution payload, causing the network to split. Such a fork will increase the instability and maintenance cost of the network.
If a proposer deliberately publishes a block close to the proof deadline, it may cause some validators to see the block while other validators do not see the block. Then the behavior of the Proposer of N+1 slots will become unpredictable, greatly increasing the possibility of on-chain forks.
PEPC
At the same time, EigenLayer has also proposed some solutions, including the AVS component PEPC (protocol-enforced proposer commitments) to solve the MEV problem. This component also hopes to solve the trust problem of the third-party middleware Relayer. It is mainly hoped that the Proposer can attach a PEPC signature to commit when submitting the CL block. The Builder verifies the Proposers PEPC before executing the load, which introduces a trust mechanism into the protocol. Through the built-in trust mechanism, the potential trust problem of Relayer as a third party can also be solved.
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 regarded as any advice. Please always seek professional advice before making any investment.
About Gate Ventures
Gate Ventures is the venture capital arm 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 works with global industry leaders to empower teams and startups with innovative thinking and capabilities to redefine social and financial interaction models.
Official website: https://ventures.gate.io/ Twitter: https://x.com/gate_ventures Medium: https://medium.com/gate_ventures
