Illuminating the Dark Forest: Unveiling the Mysteries of MEV

With the surge of on-chain activities and the evolution and enrichment of on-chain infrastructure, on-chain MEV has always been regarded as the most dangerous part of Ethereum's dark forest, directly causing profit losses and degraded user experiences for users' on-chain financial activities. The goal of this article, "Illuminating the Dark Forest," is to focus on analyzing the inherent centralization and trust issues brought about by this mechanism, based on the block generation mechanism of Ethereum 2.0 and the technical evolution of proposer-builder separation (PBS), which is in stark contrast to Ethereum's values.

The intensification of on-chain MEV is indeed a double-edged sword, with both positive and negative externalities. The positive aspects include reducing price differences on DEXs and assisting in transaction liquidation; the negative aspects include harm to users from sandwich trading. Therefore, solutions to MEV are more about mitigating negative externalities rather than eradicating them. In our exploration of mechanisms to alleviate the negative externalities of MEV and address the current issues with third-party trust middleware Relayers, we mainly categorize the measures into three types: improvements to auction mechanisms, enhancements to consensus layers, and upgrades to application layers. Each of these improvements will have varying degrees of impact on the modern landscape of MEV; however, some solutions do not effectively address the issue of sandwich attacks faced by users. User transactions remain in the public pool, hence it is necessary to introduce more privacy pool technologies to protect the optional privacy of user transactions. These MEV solutions are worth combining and experimenting with.

In addition, MEV, as an unavoidable byproduct of mechanism design, will become even more complex in the future. We also explored in the text the potential technical challenges and opportunities for more MEV that may arise under the implementation of new transaction types such as Layer 2 architecture and EIP-4337 account abstraction.

Finally, we hope to use this article to explore potential solutions to mitigate the negative externality of MEV, and to provide a comprehensive understanding of the pros and cons of current MEV solutions, not only to illuminate the dark forest that users find themselves in for the future, but also to illuminate the dark forest for industry researchers to further study MEV.

Ethereum 2.0

Since The Merge, Ethereum has adopted the POS mechanism to ensure the security of the network, while abandoning the compute-intensive competition in block production in favor of proof of stake. After the merge, Ethereum is divided into an execution layer and a consensus layer. The entire block production has also changed; each Epoch represents a POS cycle, and each Epoch is further divided into 32 Slots, with each Slot corresponding to a block time unit of 12 seconds.

The entire network will randomly select a committee from the validators in each Epoch. The proposer of the block is randomly chosen from the committee members. The block proposer needs to package the transactions and order them to finally produce a block. Other committee validators will supervise this process and then vote for the block. This committee will be reselected after each Epoch. Additionally, certain operational time limits are imposed to ensure the efficiency of block generation and voting. Here, we standardize the terminology for readers; Payload refers to the execution load, meaning state changes of transactions, which can be considered part of executing the block. The block proposer will implement the execution load (Execution Payload, which means implementing the state changes of the transaction results ) and the block proposal.

PBS Architecture

In fact, when validators are selected to be block proposers, often the proposers have no incentive to execute the Payload, meaning sorting and executing transactions, because this requires a large amount of computational power to execute state changes. The original thought was that if we elect through a decentralized committee, and include the execution load in this, then transaction sorting and the like would become decentralized matters. However, validators seem to naturally want to hand this part over to third parties to complete, while they focus on proposing blocks. This led to the concept of PBS, which separates block proposing and construction, with node proposers only responsible for validating blocks and not participating in block construction. The separation between proposers and builders promotes an open market, where block proposers can obtain blocks from block builders. These builders compete with each other to construct blocks and offer the highest fees to proposers, which we call "block auctions."

We briefly introduce the entire PBS( Proposer Builder Separate) sealed first auction model. When users submit transactions through the RPC proxy, the RPC acts as a running node that submits transactions to the public Mempool. Multiple Builders find the most suitable transactions to sort in order to generate a profit-maximizing block(. Profit maximization refers to transaction fees Base + Priority + MEV). Then, multiple Builders interact with the Proposer through the MEV-Boost Relayer. The Relayer is the bridge for interaction between multiple Builders and the Proposer, where Builders submit bids to the Relayer, and the Relayer submits multiple block headers along with the corresponding bids to the Proposer. The Proposer usually accepts the block with the highest bid. Among them, the Relayer implements the MEV-Boost specification, which is a technical specification proposed by Flashbots on how to standardize the bidding interaction between Builders and Proposers. In this process, all information is sealed; the Relayer only submits block headers to the Proposer, thus ensuring the Proposer's censorship resistance.

Various Participants and Games under PBS

Its main participants are Builder, Relayer, Proposer, MEVbot(, Searcher).

Builder

The Builder is mainly responsible for constructing block contents. After using MEV-Boost technology, it is in a more advantageous position in bidding, as it not only supports Gas Fees but also MEV profits. Builders can directly review transactions between users and Searchers, which has always been a point of criticism, especially after the U.S. government announced OFAC. A large number of Builders participated in OFAC Compliant. Compared to the beginning, although the proportion of blocks being reviewed has decreased recently, we can see that during the block construction process, Builders have a direct impact on the review of transactions.

From the current market share of Builders, a purely unregulated Build is gradually expanding its market share, all driven by profit.

Searcher

Essentially, the work of profit maximization requires collaboration between Searchers and Builders. Searchers often collaborate with specific Builders, which leads to the formation of a Dark Pool or Private Pool, where the trades of Searchers are only visible to specific Builders. Some Builders then gain MEV trades that maximize profits and bid for block space. Theoretically, if Builders engage in malicious behavior or censorship, Searchers can choose other Builders, which would gradually reduce the market share of the offending Builders. Therefore, being dependent on Searchers, Builders often consider the hidden costs of malicious actions. The above figure shows the situation of MEV and daily Gas earnings, indicating that the MEV contributions from Searchers can be as much as twice the daily Gas earnings, especially during significant market fluctuations.

For Searcher, it is divided into CEX-DEX( off-chain ) arbitrage and two major categories of DEX, mezzanine, and liquidation ( pure on-chain ).

Currently, a certain trading platform occupies the first market share in CEX --- DEX arbitrage trading.

For pure on-chain MEV opportunities, there is a gradual trend towards studio formation, with one studio capturing an astonishing 37.2% market share, specializing in sandwich attacks on Ethereum chain users, once becoming the highest gas-consuming user on the chain, accounting for about 1.5% of the entire day's gas consumption. From February 2023 to June 2024, this bot spent a total of 76,916 ETH, which, based on the value at the time of executing these transactions, is equivalent to approximately $175 million. Due to the close connection between Searchers and Builders, in practice, many Searchers tend to send their order flow to the top three Builders, whereas in reality, it could be broadcasted to all Builders. However, some smaller Builders may split the Searcher’s order flow, leading to the failure of the Searcher's MEV strategy, thereby increasing the risk of losses. Additionally, binding to Builders can help maintain their influence within the ecosystem.

Relayer

The Relayer is responsible for gathering bids and then acts as an intermediary to submit the block header and the auction price of the block to the Proposer, at which point the Proposer is unaware of the transaction details within the block. Once the Proposer selects and signs the block header, the Relayer will release all transaction content to the Proposer. We find that the Relayer, as a third party without economic incentives, has gained significant trust; the Builder relies on the Proposer for pricing, while the Proposer relies on the Relayer's pricing and block content. Historically, similar issues have occurred; a certain Relayer had a potential vulnerability that allowed the Proposer to extract over 20 million dollars in MEV. Although these vulnerabilities can be patched, the Relayer itself can still choose to act maliciously and steal MEV.

The above chart shows the market share of Relayer. We can see that the market share of Builders running purely on MAX Profit has gradually expanded since the Merge. Therefore, in a free market, it is impossible to artificially control MEV through Builders.

At the same time, Relayers also face a problem, which is the lack of economic incentives. As a result, a certain company has withdrawn from Relayer development. Currently, Relayers rely on the MEVBoost specification proposed by Flashbots to build, and Ethereum depends on third parties to provide PBS, which is not a long-term solution. Therefore, the Ethereum community is also exploring the integration of PBS at the protocol level.

Proposer

For the Proposer, an algorithm randomly selects a committee from all validators, and within each slot, a block proposer is chosen. The block proposer has the capability to execute the load, but since proposers naturally want to outsource this part, it can easily lead to vertical cooperation between Builders and Proposers. The Relayer of MEV-boost hopes to act as an intermediary in this manner to reduce the collusion arising from direct communication between the two. Currently, we are in a situation where mining pools serve as validator pools, but these mining pools and LSD validator pools both exhibit strong scale effects. Especially with the emergence of LSD, the potential of originally staked tokens is released, enhancing capital efficiency, and the influence of the DEFI building blocks behind it leads to a more centralized trend in the validator pool.

A certain LSD platform currently accounts for approximately 28.7% of the market share, with a certain trading platform and a certain LSD platform ranking second and third. In the past, when the MEV-BOOST PBS solution was not actively implemented, the Proposer needed to be responsible for the Builder's tasks, which involved executing load (Payload). However, most Proposers gave up their ability to execute transaction ordering because this heavy computational work would severely burden verification performance. It is better to outsource the execution load and let third parties auction the blocks.

User

Finally, let's talk about the user. Users are often in the weakest position in the entire architecture design because their transactions are placed in the Mempool and can be exploited for MEV profits by various MEV bots, but these profits do not flow to the users. However, this is not always a downside; for example, in a DEX, when there are significant on-chain market fluctuations or when a user's trading volume exceeds the DEX's liquidity, MEV bots can use arbitrage to mitigate slippage and the price differences across platforms. Therefore, the existence of MEV has both positive and negative externalities, which need to be discussed separately, and this is also part of its complexity.

To prevent users from being monitored by MEV bots, which could cause harm to users.