🎉 [Gate 30 Million Milestone] Share Your Gate Moment & Win Exclusive Gifts!
Gate has surpassed 30M users worldwide — not just a number, but a journey we've built together.
Remember the thrill of opening your first account, or the Gate merch that’s been part of your daily life?
📸 Join the #MyGateMoment# campaign!
Share your story on Gate Square, and embrace the next 30 million together!
✅ How to Participate:
1️⃣ Post a photo or video with Gate elements
2️⃣ Add #MyGateMoment# and share your story, wishes, or thoughts
3️⃣ Share your post on Twitter (X) — top 10 views will get extra rewards!
👉
The Double-Edged Sword of MEV: Analyzing the Ethereum PBS Architecture and Exploring Solutions
Illuminating the Dark Forest: Unveiling the Mysteries of MEV
With the dramatic increase in 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 the Ethereum dark forest, which directly leads to profit losses and a degradation of user experience in 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 stands in stark contrast to the values of Ethereum.
The intensification of on-chain MEV is indeed a double-edged sword, with both positive and negative externalities. Positive aspects include reducing DEX price discrepancies and assisting in trade liquidation; negative aspects include harm to users from sandwich trading. Therefore, MEV solutions 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 issues related to third-party trust middleware Relayer, we mainly categorize measures into three types: improvements in auction mechanisms, enhancements in the consensus layer, and upgrades in the application layer. These three improvements will impact the modern landscape of MEV to varying degrees, but some solutions do not fundamentally address the issue of sandwich attacks faced by users, as user transactions remain in the public pool. Therefore, it is necessary to introduce more privacy pool technologies to protect the optional privacy of user transactions, and these MEV solutions are worth trying to combine.
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 of 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 explore potential solutions to mitigate the negative externalities of MEV through this article, and to provide a comprehensive understanding of the pros and cons of current MEV solutions, not only to illuminate the dark forest in which users find themselves in the future, but also to shed light on the dark forest of further research on MEV for industry researchers.
Ethereum 2.0
Since The Merge, Ethereum has adopted a POS mechanism to ensure the security of the network, while abandoning computation-intensive competition in block production and switching to Proof of Stake. After the merge, Ethereum is divided into the execution layer and the consensus layer. The entire block production has also changed; each Epoch represents a POS cycle, and each Epoch is 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 this committee set. The block proposer needs to package the transactions and execute them in a sorted manner 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 the readers: Payload refers to the execution load, which means the transaction state changes and can be seen as part of the execution of the block. The block proposer will implement the execution load ( Execution Payload, which means implementing the state changes of transaction results ) and the block proposal.
PBS Architecture
In fact, when validators are selected to become block proposers, proposers often have no incentive to execute the Payload, that is, to sort and execute transactions, because this requires a lot of computational power to execute state changes. The initial thought was that if we could incorporate execution load into decentralized committee elections, then transaction sorting and other tasks could become decentralized as well. However, validators seem to naturally want to hand this part over to third parties, while they focus on proposing blocks. This led to the conception of PBS, which separates block proposing and constructing, where the node proposer is only responsible for validating blocks and does not participate in block construction. The separation between proposers and builders fosters an open market, in which 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 will briefly introduce the entire PBS( Proposer Builder Separate) sealed first auction model. When users submit transactions, 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 acts as a bridge for interaction between multiple Builders and the Proposer. Builders submit bids to the Relayer, which then submits multiple block headers and corresponding bids to the Proposer. The Proposer generally adopts the block with the highest bid. Among them, the Relayer will implement the MEVBboost 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, and the Relayer only submits block headers to the Proposer, ensuring that the Proposer has censorship resistance.
Various Participants and Game Theory under PBS
The main participants include Builder, Relayer, Proposer, MEVbot(Searcher).
Builder
The Builder is mainly responsible for constructing the block content. After using MEV-Boost technology, it is in a more advantageous position in bidding, as it supports not only Gas Fees but also MEV profits. Builders can directly audit transactions between users and Searchers, which has always been criticized, 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 audited blocks has decreased recently, we can see that in the block construction process, Builders have a direct impact on the auditing of transactions.
From the perspective of the current market share of Builders, the unreviewed Builds are gradually expanding their market share, all driven by profit.
Searcher
Essentially, the work of maximizing profits requires cooperation between Searchers and Builders. Searchers often collaborate with specific Builders, resulting in the formation of a Dark Pool or Private Pool, where the trades of Searchers are only visible to certain Builders. Some Builders will then obtain MEV trades that maximize profits and compete for block space. Theoretically, if Builders engage in malicious activities or censorship, Searchers can choose other Builders, which would gradually reduce the market share of the Builders. Therefore, constrained by the Searchers, Builders often consider the implicit costs of malicious behavior.
For Searcher, it is divided into CEX-DEX( off-chain ) arbitrage and two main categories of DEX, mezzanine, and liquidation ( pure on-chain ).
Currently, Wintermute holds the largest market share in CEX - DEX arbitrage trading.
For pure on-chain MEV opportunities, there is a gradual trend towards studio formation, with jaredfromsubway.eth capturing an astonishing 37.2% market share. He excels at sandwich attacks on Ethereum chain users and has once become the user with the highest gas consumption on-chain, consuming about 1.5% of the gas for an entire day. 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 USD. Due to the close ties between Searchers and Builders, in practice, many Searchers will send their order flow to the top three Builders. In reality, it could have been broadcasted to all Builders, but some smaller Builders may split the Searchers' order flow, causing the Searchers' MEV strategies to fail and leading to a risk of loss. Furthermore, binding Builders can also help maintain their influence within the ecosystem.
Relayer
The Relayer is responsible for aggregating bids and then acts as an intermediary to submit the block header and the bidding price for 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 the transaction contents to the Proposer. We find that the Relayer, acting as a third party without economic incentives, has gained significant trust, with the Builder relying on the Proposer for quotes, and the Proposer depending on the Relayer's quotes and block contents. Historically, similar issues have occurred, presenting a potential vulnerability that allowed the Proposer to extract over $20 million 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 Relayers. We can see that the market share of Builders running pure MAX Profit has gradually increased 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, some companies have also withdrawn from the research and development of Relayers. 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 currently exploring the incorporation of PBS at the protocol level.
Proposer
For the Proposer, an algorithm randomly selects a committee from all validators and chooses a block proposer in each slot. The block proposer has the capability to execute workloads, but due to the proposer's inherent desire to outsource this part, it easily leads to vertical collaboration between Builders and Proposers. MEV-boost's Relayer aims to act as an intermediary in this manner, reducing the vertical collusion brought about by direct communication between the two. Currently, we are all in a mining pool as a validator pool, but both this mining pool and the LSD validator pool have strong scale effects. Especially with the emergence of LSD, the potential of the originally staked tokens is released, enhancing capital efficiency, and with the influence of the DEFI building blocks behind it, the validator pool is trending towards more centralization.
A certain LSD project currently occupies about 28.7% of the market share, with a certain trading platform and a certain project 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 is to execute the load (Payload). However, most Proposers gave up their ability to order transactions because this heavy computational work would severely burden verification performance, and it is better to outsource the execution load and let a third party auction the blocks.
User
Finally, let's talk about users. Users are often the most disadvantaged party in the entire architecture design because their transactions are placed in the Mempool and are subject to various MEV bots that extract MEV profits from them. However, these profits do not flow to the users. But this is not always a drawback. For example, in DEXs, when there are significant fluctuations in on-chain prices or when a user's transaction volume exceeds the liquidity of the DEX, MEV bots can use arbitrage to reduce slippage and 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 its complexity.
In order to prevent users from being monitored by MEV bots, which could cause harm to users, many service providers can help users place their transactions in a non-public Mempool. For example, users can interact directly with Builders through their services. A relatively novel approach is to compensate users for MEV profits through OFA(Order Flow Auction), where OFA operators establish partnerships with Searchers. By auctioning users' orders to Searchers, Searchers can maximize MEV, thereby allowing the entire...