Partnered With:

The Next Five Years of MEV: Understanding the Latest Trends in the MEV Space.

Read this article in 25 Minutes

MEV is not theft, nor is it an enemy to be defeated. It is an indispensable part of our practice process.

Original Title: "The Next Five Years of MEV: Understanding the Latest Trends in the MEV Field"

Original Author: James Prestwich

Original Translation: aididiaojp.eth, Foresight News

Recently, I wrote an article titled "The First Five Years of MEV: Starting from Before the Birth of Flashbots", which serves as a prequel to this article.

Seeing the development of MEV over the past year, I am hopeful that it will play an important role in the cryptocurrency ecosystem. The story of MEV so far has been about specialization, and this article is also about what specialization means for the future of MEV.

Three Roles in the MEV Market

During the bear market, some coordinated measures will be taken to promote the development of the MEV supply chain in other ecosystems, such as Solana, Cosmos, Near, etc. From our perspective, the Searcher-Builder-Proposer (SBP) structure seems to be replicated in all of these ecosystems and specialized to win in complex markets. The SBP structure will continue to dominate as simple boundaries allow each role to specialize without coordinating with other roles. It is currently difficult to see the possibility of other market structures forming in the current landscape.

However, some fee markets are completely different from Ethereum, such as Penumbra, which will not form an SBP market structure due to batch auctions and threshold encryption transactions. The Osmosis team has also spent a lot of research time on MEV countermeasures, but it is currently unclear what the MEV market structure will be on these chains, and at least a mature MEV supply chain cannot be formed temporarily.

The MEV market and protocol fee market are currently in a tense state, with value tilting towards the highest price auction. If we try to alleviate this tension by dividing the fee market into MEV and abnormal MEV, the normal fee market will be led towards the SBP structure, which can generate enough accessible MEV to make software development valuable, and the abnormal fee market may see a unique MEV supply chain.

Source Link

争论的死灰复燃

translates to

The Resurgence of Debate

We have had a wonderful debate about whether MEV belongs to theft in moral or legal terms. During the bull market, everyone was busy with MEV acquisition, and many things were overshadowed by the heat of the market. Currently, on-chain financial activities have eased, and I expect to see a "moral return" to MEV acquisition. Twitter will also replay some old episodes, and fans will have some fierce debates about who deserves MEV. But searchers will not care, MEV acquisition will continue.

MEV-Aware Hard Fork

MEV fee market will shift to first-price auction. Core developers have considered MEV in protocol design. From my interactions with several ecosystems, core developers tend to lean towards two camps.

The first camp of core developers has designed mechanisms to increase the cost of MEV extraction. These mechanisms look like batch auctions, threshold encryption, and pre-consensus. They hope that these mechanisms can increase the cost of extracting MEV. If extraction requires collusion with validators in the face of potential punishment, it may not be possible at all. However, these mechanisms increase the cost and complexity of user interaction and protocol incentives. The specific mechanism design has not yet reached a widespread consensus.

Another group of protocol developers has adopted a method to create elegant mechanisms and build a more civilized blockchain, focusing on minimizing the loss of value flow, mitigating the impact of MEV on the protocol itself, and ensuring fair distribution for participants. These three questions are: first, how to minimize the impact of MEV on protocol users? Second, how to mitigate the impact of MEV on the protocol itself? Third, how do you ensure fair distribution of MEV to the protocol?

Using EIP-1559 as an example, although it is not an explicit MEV EIP, it considers these three issues. EIP-1559 minimizes the impact of fee spikes on users by allowing block space expansion and user fees to float with the base fee. It mitigates the impact of fee spikes on the protocol by adjusting the relationship between block capacity, GAS usage, and base fees. Finally, it increases the participation value by increasing the base fee ratio.

Source Link

Complex mechanisms like EIP-1559 are difficult to be widely used and are not truly suitable solutions. I believe developers will follow in the footsteps of EIP-1559 to lower proposers' commissions. The shadow cost market of MEV benefits proposers and MEV builders, but harms all other users. Like the fees before EIP-1559, MEV block production and inclusion dynamically create a fundamentally unfair market. Therefore, I hope we can see a mechanism similar to 1559 specifically aimed at improving the relationship between builders and proposers.

Regardless of whether they are proposers or useless speculators, their income should be suppressed. My prediction for the future is very simple: in the next 5 years, we will see multiple hard forks in different ecosystems that specifically target the MEV market of certain chains. They can target MEV extraction costs or MEV profit sharing. Ideally, we will see a close integration of the MEV supply chain with L1.

Vertical Integration

There has been much debate in the vertical integration market regarding proposers, builders, and searchers. The basic idea is that proposers may retain an internal builder to gain builder revenue, or builders may prioritize specific searchers. Vertical integration may squeeze out smaller businesses and lead to a market dominated by a few major builders.

I think this fear is a bit exaggerated. The protocol randomly selects proposers, and the search and construction of the market will be fiercely competitive. The horizontal cooperation between proposers (who have all the power in the market) seems more worrying. The price-fixing arrangement between proposers can be enforced through a soft fork activated by stakeholders. The protocol may have to become a proposer-trust destroyer to prevent harmful PBS market effects on user experience. Worse still, as long as colluding proposers have adjacent slots, they can extract multiple MEVs, which may have an unstable impact on the finality of the blockchain.

Vertical integration will definitely occur in special situations. A certain amount of MEV is generated by the interaction between bundles. Builders have the right to access this cross-bundle MEV and may integrate an internal specialized searcher. There may be other special situations that make it economically feasible for searchers, builders, and proposers to have a closer and more trustworthy relationship.

MEV-Aware Application Design

This is like cheating because it's already happening. For example, the CowSwap team has already launched MEV-Aware applications. Minimizing MEV will be the focus of discussion for a period of time because we need to make trade-offs. The research here is driven by a single core question: What do we have to give up to remove MEV?

Although the design space of the protocol is very limited, it is actually difficult to reach a consensus protocol. However, there are many options for applications to minimize MEV. The effective method depends on the application, and we will see MEV minimization mechanisms (such as batch processing) that are not suitable for lending protocols. New research will drive some changes in each dApp vertical field. However, the new MEV minimization model needs to counteract the momentum of existing applications. It is currently uncertain which dApps will see widespread adoption of anti-MEV designs and which dApps will accept the current level of MEV generation.

However, we will not stop at designing protocols to minimize MEV. Instead, MEV will become a tool in application design, and application designers will choose when and how to generate MEV. We will propose a unique framework to determine when MEV can be accepted, as well as a set of standard techniques for adjusting the amount of MEV generated by the system.

Explicit MEV

The inevitable extension of MEV-Aware application design is co-opting MEV and using it as a tool. Unexpectedly, the MEV supply chain provides guarantees that normal transactions cannot access, namely that MEV transactions will never be reverted and builders will not waste block space on unprofitable chains. MEV transaction confirmations are faster, and searchers convert this MEV into shadow fees, giving transactions higher priority. Applications will begin intentionally using MEV to access these features, which I call "explicit MEV".

Explicit MEV can give applications a certain superpower. It allows users to choose to waive the EIP-1559 fee and still be able to confirm their transactions quickly. Applications can intentionally release MEV opportunities and combine them with critical system operations. For example, we can add 0.1 ETH MEV to oracle updates. This MEV opportunity creates a race among searchers, with the first searcher to confirm the transaction receiving the MEV. Prior to PBS MEV, this would result in a priority gas auction, which could be very expensive for participating searchers. However, modern MEV supply chains eliminate the cost of losing this race, as searchers know that the reverted transaction will be removed by the builder.

The logical conclusion of MEV-aware design is MEV-inclusive design. Applications will explicitly create MEV, incorporating it into their design and using it to purchase privileged positions in the block space market. Explicit MEV transactions will effectively replace standard transactions for high-value use cases.

MevWeth

Explicit MEV requires two things:

First, a standard needs to be created. To avoid expensive Gas, all explicit MEV should use the same on-chain state, regardless of which contract created it. This allows MEV to be linked across many transactions without significantly increasing complexity. Searchers need a simple way to understand if an application is creating explicit MEV. They should be able to look for specific, predictable state changes. They do not need to scan through a large number of contracts to detect explicit MEV. If each contract manages its own explicit MEV, searchers cannot obtain it without performing a lot of state lookups and changes. A single specific contract should be able to manage explicit MEV.

Secondly, a separate accounting system should be established for explicit MEV, which should be priced in ETH. As searchers bear the risk of gas prices, their payments should be in gas assets, which greatly simplifies everything. However, this poses new requirements for contracts that generate explicit MEV: contracts must track how much ETH they can spend on MEV. It would be disastrous for a DEX to accidentally spend user ETH on explicit MEV. Therefore, any contract that uses explicit MEV and ETH must maintain a balance between MEV-able ETH and non-MEV-able ETH.

So we need a standard for creating MEV and an accounting system for MEV. With a clear, obvious, and intuitive solution that combines these requirements, we can easily build a system to track the user balance of MEV-able ETH. We know exactly how to build contracts that accept ETH and hold them for users, and implementing explicit MEV functionality tracking and management is also easy.

We can refer to it as "MEV Wrapped ETH" or MevWeth.

This code may appear to be an extension of WETH10 with an explicit MEV management interface. It may be hosted on GitHub and may have already been deployed on the mainnet.

MevWeth is an ERC20 that provides a standard for the following aspects:

Use the addMev() function series to create MEV.

Retrieve MEV through the getMev() series.

Through the Mevitize.sol basic contract, explicit MEV creation is added to the contract.

负 MEV

translates to

Negative MEV

in English.

Explicit MEV cannot be separated from the transaction that creates it. Explicit MEV is added to implicit MEV in transactions. They are used together to subsidize faster confirmations (as well as all other benefits of modern MEV supply chains). However, certain categories of transactions already have a lot of MEV. Clearing, DEX transactions, etc. have generated enough MEV to get priority confirmation without any explicit value creation. Adding any explicit MEV to the overall will pay too high a cost for accessing the MEV supply chain.

Regardless, these transaction costs are too high. Uniswap users aren't going to sit down and calculate the MEV they're creating with their trades, nor will they compare it to some concept of "priority fee market clearing MEV." No one has yet treated MEV as a priority fee, and even if they did, there's no effective way for them to capture that value. Negative MEV can change all of this.

Negative MEV is explicit MEV below zero. On-chain operations with negative MEV require payment in MEV through MevWeth. If payment is not made in advance, the operation cannot be completed. It is important to understand the existing power relationships in the MEV supply chain, where users and application creators create extracted value but have not yet participated in the extraction supply chain. Proposers charge rent to other supply chain participants, and negative MEV acknowledges that proposers ultimately cannot control this process and rely on the value created by users and applications.

By specifying negative MEV, users or protocols can recapture MEV created by valuable operations. We can seize MEV from proposers and return it to the people who created that value. Negative MEV provides a simple and direct way to play a role in the MEV supply chain. With negative MEV, users become participants in the value extraction process rather than its targets.

For example, Uniswap users may resist MEV by narrowing the range of transaction slippage. However, this often makes the transaction worse or less likely to complete. Negative MEV provides an off-chain way to improve transaction results without changing the transaction itself. Users can attach a small amount of negative MEV to the transaction instead of narrowing the slippage range. This effectively provides a fee rebate through interaction with the searcher. Users get better results. The transaction itself is not affected. The atomic coupling of transactions and payments to users allows users to explicitly share the value created by users.

The negative MEV will change how the protocol controls access to high MEV processes such as clearing, and will also change the way users perform high MEV operations such as executing DEX trades.

MevWallet

MevWallet is an intelligent contract wallet that allows users to attach explicit MEV to transactions. It follows the very standard EIP-712 meta-transaction standard and allows users to specify prompts for their transactions. Once the transaction is signed, anyone can broadcast it. MevWallet verifies transaction details and executes some basic conditions before executing the transaction. Like any smart contract wallet, transactions are executed from the wallet, not from any EOA. msg.sender is the wallet and tx.origin is the searcher.

After the transaction is executed, MevWallet calculates the gas usage and adds a tip. If the result is positive, it compensates the searcher in MevWeth. If the result is negative, it retrieves some stored MEV from MevWeth. Users can pay negative transaction fees and receive rewards if the transaction generates enough MEV to fully offset the execution. By requiring compensation for the MEV they produce, users can regain the value they would have otherwise surrendered to block proposers through the MEV supply chain.

MevWallet supports time locks and deadlines for transactions, as well as repeat payment protection based on random numbers. This combination allows for complex fee adjustments based on time. For example, a transaction may generate more explicit MEV over time until it is confirmed. This creates a Dutch auction among searchers, ensuring that the transaction is confirmed at the lowest price available on the market. Many other interesting fees can be implemented with the automatic escalator model without on-chain expenses. Because fee auctions occur among searchers and transaction confirmations can be rolled back, users and searchers do not incur additional gas costs no matter how complex the gas auction becomes.

MevWallet has code libraries in TypeScript and Rust, which can be deployed to create new MevWallets through a minimal proxy factory. The code has been licensed and is available on GitHub. The main thing that MevWallet currently lacks is a way for searchers to see transactions. I am still looking for the best way to achieve this. I have considered a simple CRUD API and a dedicated memory pool, but I am not sure if this is a viable long-term solution.

MEV's Future Five Years

I look forward to and hope that the future five years of MEV will be as amazing as the first year. As MEV research moves out of adolescence and into maturity, we should welcome its presence in our application design. We should look for its advantages and let it contribute to our applications and protocols. MEV is not theft, nor is it an enemy to be defeated. It is an indispensable part of our practice process.

The story of MEV now belongs to the profit space, which makes it predictable. Profit margins breed stability and reliability, and the more money earned through market regulations, the greater the stickiness of the regulations. The story of the next five years will consolidate the existing and stable supply chain, and use it to build systems that did not exist before.