Problem with post-merge MEV (Dark forest is darker than you think)

Maximal Extractable Value - also known as Miner Extractable Value or MEV - is the ability to capture profit from optimizing the transaction sequence when constructing a block, and most MEV is captured by miners and searchers who have been profiting from MEV activities throughout the bear and bull of the crypto cycles. MEV arises fundamentally from information asymmetries in the market. To alleviate the information asymmetries and reduce the negative externalities of MEV, numerous innovations have come up, among which were Flashbots.

Cumulative extracted EVM

To this date, over $650M of MEV were extracted through Flashbots, and that figure is still growing. However, the following graph shows that MEV is still a miners’ game as they extract nearly two-thirds of the entire MEV profit.

Visual representation of MEV landscape

Numerous problems exist with MEV for the current Ethereum ecosystem. With its upcoming upgrade, those problems will carry over and even introduce new problems. In this article, I will explore the MEV problems for pre and post-merge Ethereum (I will be using post-merge synonymously as post-Splurge for simplicity) and seek potential solutions to address those issues. Before diving into it, I will first go over how MEV is currently extracted. 

1. How MEV is extracted? Flashbots and Miners?

As previously mentioned, MEV is currently extracted mostly by miners and searchers (from flashbots). Those two work differently in design, which I will dive into later, but both find MEV opportunities from a pool of pending transactions, known as the mempool. They insert their transactions in the right places to achieve their intended MEV extractions. Here are some of the popular MEV techniques: arbitraging, liquidation, frontrunning, sandwich attack, and backrunning. Most of them have varying levels of impact on the usability of Ethereum. Some may even pose an existential risk, which will be discussed later. 

1.1 Brief explanation of how MEV work for Flashbots?

There are three main components for Flashbots: searchers, relayers, and miners. Searchers are essentially the ones that submit transactions for reasons such as arbitrage, liquidation, frontrunning, privacy, MEV protection and more. Relayers are the middleware between the miners and searchers that validate the bundled transactions received from searchers and push them to Flashbots miners. Relayers are crucial as they provide flexibility around the handling of the transaction bundles, such as bundle merging, and prevents DOS threat to miners. Miners run mev-geth, which is a flashbots-specific geth that uses first-price sealed-bid auction for ordering, and participation as a miner for flashbots is permissioned and mainly operated still by trusted entities.

1.2 Brief explanation of how MEV work for non-flashbots miners

Regular miners, on the other hand, have access to transactions in mempool, which aggregates non-committed transactions waiting to be processed. Some may also accept private transactions directly from users without going through mempool, which is fairly common - over 85% of MEV is extracted using private transactions sent to miners and 50% of it is from flahsbots. Miners sequence those transactions in the order of gas fee and also insert their own transactions in between as the MEV opportunities arise.

2. What are the problems with the current MEV landscape?

Some MEVs, especially malicious ones, can erode the network usability due to PGA and miner control. Those issues typically appear in the forms of high gas fees, failed transactions, and network congestions.

As previously mentioned, there are different MEV techniques, such as arbitrage, liquidation, frontrunning, backrunning, sandwich attack etc. While some may be benign, like arbitrage and liquidation, others may be malicious (although not always), such as sandwich attacks and frontrunning. Malicious MEV techniques incur additional costs on the users instead of making the market more efficient and may even cause network congestion as miners compete for MEV. Hence, the usability of the network will be discounted as users experience higher slippage, higher gas fee from constant bidding, and delayed transaction processing.

Besides network usability, some MEV techniques could cause existential risk to the network. Time-bandit attack involves forking of the chain to reorder transactions in the Nth block (previous block). Miners perform time-bandit attack when the economic incentive from MEV across the blocks surpasses the block rewards from mining the N+1 block. This will cause major instability for the blockchain as the top miners, who typically have over 10% of the entire hashrate of the network, pull off such forks to attempt extracting cross-block MEV. Since those attacks can be only performed by large miners, such as F2Pool (23.94% of hashrate) and Ethermine (12.57% of hashrate) etc. (theoretically needs 10+% of the hashrate to have a chance at pulling it off), this shows the centralization risk associated with the concentration of the mining power to a single entity and the extent of control that miners have over the entire network.\

Miner control of the transaction ordering also leads to another major problem: transaction censorship. The concept is simple: miners simply do not include victim transactions in the blocks. Censorship may seem harmless at first, but it can cause a catastrophic impact on dApps in certain situations. Let’s say an algostable coin needs to repeg by selling a large volume of treasury assets, but what happens if there was a coordinated attack with miners to censor the selling of treasury assets? Such censorship would artificially induce death spirals for the targeted pegged assets or any assets that need to be rebalanced. While those attacks may not pose an existential threat to the network, they can cause a massive drawdown for the onchain ecosystem.

All the problems I mentioned above are not limited to the Ethereum mainnet. Rollups would also suffer from such malicious MEV techniques as long as they have sequencers whose transactions are publicly viewable, except for privacy-concerned rollups where the transactions are encrypted before committing the block. Since appropriate sequencing is a crucial component for the stability of the network, even more so for rollups, many have proposed and discussed some possible solutions. This is still an actively researched area, but I will introduce a couple of proposals that seem to have gained builders’ attention.

2.1 MEV Auction, aka MEVA, by Optimism

MEVA is a solution proposed by Karl Floersch, CTO of Optimism, to reduce the network congestion from bidding. MEVA allows whoever wins the auctions to manage the sequencing for the day. This is a fairly simple and blunt solution to reduce bidding activities, but there are also significant downsides to it. Because the MEV is harvested by winning bidders, the mining revenue for other sequencers will have to be supplemented by the users, which will result in a higher cost for users. Furthermore, MEVA incentivizes centralization of the sequencer network as smaller sequencers try to collaborate to outbid larger sequencers, resulting in an overall more centralized consensus. 

2.2 Fair Sequencing Service, aka FSS, by Chainlink

FSS attempts to solve the sequencing fairness by inserting an oracle network in between the mempool and relayer contract, SCON. The oracle network will fetch the transactions from the mempool and sequence them in the order of transactions entering the mempool. This sequence of transactions will subsequently be sent back to the mempool and then to the relayer contract for committing to the network. This would be a more reliable mechanism to provide sequencing fairness and also have high compatibility with the existing consensus architecture. However, this would also introduce the risk of oracle collusions and may potentially increase the user cost, as the incentivization of oracle providers may incur an additional fee.

2.3 Threshold encryption

Some projects attempt to use threshold encryption, where private keys are distributed across miners and require above a certain threshold number of miners for decryption. This allows transactions to be encrypted before the consensus is reached. This solution provides strong privacy around transactions and potentially eliminates a large amount of MEV. However, it also introduces a complicated validation procedure and requires a large number of miners, which may be unfeasible. 

2.4 Randomizing transaction order

Randomization of the transaction order is another way to mitigate MEV. Miners will first pick a batch of transactions that will be committed. Then, miners will receive a random permutation, based on the hash of the current and previous block, and the ordering of the batched transactions will be performed based on the permutation. Such a mechanism can reduce the MEV and also increase the cost of performing MEV because multiple bundles of transactions need to be submitted in order to have a higher chance of extracting the intended MEV. The probabilities will increase as the cost of the transactions increase in this case. 

2.5 Some thoughts about the current solutions and problems

Currently proposed solutions minimize MEV through various angles of approach. However, I believe it is crucial for the solution to have a more selective minimization of the MEV. For example, if randomization or threshold encryption is implemented, it would be economically unfeasible to perform good MEV, such as arbitraging and liquidation. Therefore, MEV minimization solutions shall not have an all-or-nothing approach, but rather have optionality in design to achieve selective MEV minimization. 

3. Proposer builder separation and associated MEV problems for post-merge Ethereum

Finally, time to talk about an MEV problem with post-merge Ethereum. This is the exact reason I originally started thinking about writing this article; there is a problem with the post-merge consensus for Ethereum. Before diving into it, let me elaborate on an upgrade in Ethereum relevant to MEV; proposer builder separation, aka PBS.

3.1 What is PBS? Why does Ethereum need it?

PBS refers to the separation of the traditional miners into two different parties, proposers and builders. Builders will be in charge of creating an exec block (ordered transactions that will be the payload for the N+1 block), and proposers will be in charge of bidding on the block without knowing the content of the block (the highest bidding block will be committed). Such pre-confirmation privacy of the block will provide protection against MEV stealing by miners, which essentially negates miners of the authority over block sequencing tasks (one of the problems I mentioned previously was miners having too much control). This can also reduce transaction censoring as it would be harder for the proposer to coordinate with a builder to block victim transactions. For more details on the theories behind it, please check out Vitalik’s proposal. 

Economic incentives for proposers and builders will also be a key design that makes PBS feasible. Proposers will receive both the gas fee and the proposer fee, which is a % of the MEV extracted by the builder submitting a given block, while builders will own most of the MEV profit. With such an incentive scheme, proposers would generate an increased APY of +5% on top of existing APY, theoretically, on the staked ETH while builders can compete for extraction of MEV without MEV stealing.

3.2 So what is the problem?

There is a major centralization risk for the builder network. With the introduction of PBS, most miners will turn into proposers with staked ETH from the likes of Lido and Rocketpool. However, only a portion of players who can perform MEV well will become builders, as the bulk of the economic incentives will be driven by MEV from “block optimization”. In addition, MEV is a competitive landscape in nature and has a higher barrier of entry compared to just being a miner. In Q1 2022, Ethereum validator number was reported to be around 340k, among which some performed MEV. For flashbots, the number of searchers is around 56k, but their active monthly searchers are only 9k. Given that only a portion of the miners who are actually capable of MEV (knowing how to do MEV and doing it well is a challenging task unlike just running a bunch of GPUs) and some flashbots searchers would become builders, it’s very possible that the Ethereum post-merge (post-Splurge to be accurate) will have significantly more proposers than builders, which poses the centralization risk on the consensus network. 

Furthermore, there will be competition among builders to best optimize the block. But, most likely, a handful of experienced MEV searchers/miners (a bit of exaggeration here) will dominate, whose blocks will more likely get committed to the blockchain as they can afford to pay a higher proposing fee to the proposers. Such centralization risk unattended may lead to consensus security instability, which will erode the decentralization, permissionlessness and neutrality of the network.

3.3 Ok, we get the problems, but is there any solution?

Currently, a handful of players are trying to create a solution for the problems as far as I know: Flashbots, Blocknative, and BloXroute (not 100% sure). How those solutions will look like and if each can work in harmony is still uncertain, but here are a few potential approaches that we may see upcoming. 

One approach is providing MEV SaaS for anyone who wants to participate as a builder and do so profitably. One of the biggest challenges to being a searcher and builder is to know how to do MEV and generate sustainable revenue from that (less revenue, less incentive, fewer builders). A high barrier to entry can bar a lot of people who would be interested in participating otherwise. Hence, a SaaS solution can significantly lower the hurdle and flatten the learning curve for non-searchers, aka curious people like me, to enter this MEV space and become a builder to support the consensus network.

Another approach will be from infrastructure middleware. Flashbots has recently started testing their new feature called MEV-boost. This is essentially the PoS version of the MEV-geth where the validators/proposers can start running MEV-boost to accept blocks from both builders and Flashbots. This will boost yields while further supporting the decentralization of the builder network through competitions and more searcher participation through Flashbots. 

4. Conclusion

MEV used to be an untethered space where fierce competitions raged on among searchers and miners. However, the competition has reached a degree where it started eroding the network performance and usability. At some point, people started calling it Dark Forest as everyone hide in the dark to snatch as much value as possible out of the hands of unaware users/traders. While there are some good forms of MEV, the Dark Forest is still festered with malicious ones. Many have proposed various solutions, but most still struggle to selectively minimize MEV’s negative externalities. With the introduction of PBS, we will encounter another major problem, the centralization of the builder network. When an MEV player is not a stakeholder within the consensus mechanism for pre-merge Ethereum, the centralization of authority over MEV, which is an existing problem, may not pose as much threat as when a player is an independent stakeholder within the consensus mechanism. Even though PBS is intended to mitigate transaction censorships and the concentration of miner authorities, the centralization of builders may well threaten the future of Ethereum. I believe this is a problem that needs to be tackled imminently to build a healthy and decentralized future for Ethereum.