What is MEV?

Maximal Extractable Value or ‘MEV’ refers to the maximum value that can be extracted permissionlessly through the inclusion, censoring or re-ordering of transactions within a single block.

There are various flavours of MEV ranging from the necessary to the purely value extractive. The MEV exposed by certain protocols is by design and necessary for their continued correct function. Liquidations on lending protocols for example create opportunities for anyone to update the state and prevent the creation of bad debt in return for the liquidation bonus. In this case, MEV is essentially a permissionless incentive for maintenance of the protocol. The same can be said for certain arbitrage trades which keep prices across DEXs in sync with the wider market.

On the other end of the spectrum is oracle arbitrage, generalised frontrunning, flashloan and sandwich attacks (a combination of front- and back-running transactions) which serve no purpose other than to generate profit at the expense of others. These forms of MEV result in unnecessary network spam, state bloat and higher gas prices. Somewhere in the middle lies Just-in-Time liquidity (a form of sandwich) that results in better execution for traders on AMMs but reduces the fees available to LPs in the pool. There is a long tail of MEV which covers a wide variety of esoteric opportunities.

A straightforward example of MEV can be illustrated with a simple sandwich attack. Consider a scenario where a trader places a buy order on a decentralised exchange (AMM). This transaction ($T_1$) enters the public mempool (a collection of pending transactions) where it is visible to all. Depending on certain factors such as order size and slippage settings, this can present an opportunity for searchers (MEV bot operators) who identify this. By placing a buy order ($T_F$) immediately in front of and a sell order ($T_B$) immediately behind the target transaction, the searcher is able to buy the token, wait for the target transaction to execute then sell the token at a higher price, pocketing the difference. These transactions, along with the target transaction can be bundled together and executed atomically. Since this opportunity is visible to anyone watching the mempool, searchers compete to be included in the block ahead of their competitors.

The business of MEV extraction can be highly lucrative - to date more than $675 million has been extracted since the start of 2020 - this figure represents the lower bound for MEV extracted to date as quantifying and tracking all possible forms of MEV is easier said than done. Left unchecked however, MEV can be detrimental to Ethereum as the economics of MEV threaten the decentralisation and stability of consensus networks by introducing ‘perverse’ incentives.

MEV-driven Validator Centralisation

MEV can be captured by validators a.k.a proposers through careful selection and ordering of transactions. Transactions are sourced from the public mempool along with any transactions received through other means e.g. transactions sent directly to the proposer through a private communication channel. These transactions can then be arbitrarily ordered along with the proposers inserted transactions and are then committed to the chain as a block.

The precise ordering of transactions within a block is at the discretion of the validator with the right to propose that block. Under Proof of Stake (PoS) on Ethereum, this right is awarded to a pseudo-randomly selected set of validators who stake ETH as collateral. The chance of being selected increases with the amount of ETH staked. There are 32 slots in an epoch lasting 12 seconds each. Every slot can be thought of as the time window during which the validator designated for that slot can propose a block.

Under Proof of Work (PoW) on Ethereum, mining pools were a popular way for miners to smooth the variance of the block rewards they received by pooling hash power and proportionally distributing rewards. This resulted in a handful of large mining pools being the dominant ‘block proposers’ on the network and has parallels to what is happening today under Proof of Stake (PoS) on Ethereum with validator pools.

There are a multitude of reasons why solo stakers might choose to join a validator pool. Running a solo validator requires 32 ETH which can be prohibitively expensive (~$48,000 at today's prices), and the process of maintaining a validator requires some technical expertise. Validator pools allow anyone to stake arbitrary quantities of ETH and relieve stakers of the operational overhead. Meta-pools such as Lido go one step further, allowing users to get liquidity on their locked stakes through the issuance of liquid staking derivatives (stETH) that can be used as collateral on other protocols for additional yield.

MEV introduces yet another powerful economic incentive to do so. Due to the block subsidy being significantly reduced under PoS compared with PoW, profits from MEV extraction are more relevant as they represent a larger share of the total ‘yield’ for validators.

Optimising MEV extraction requires sophisticated infrastructure and specialised knowledge. Validator pools with a large share of the total quantity of staked ETH benefit from significant economies of scale in finding sophisticated MEV opportunities, encouraging smaller validators to pool with them. Larger validators also benefit from having more opportunities to propose blocks and therefore extract MEV on a more frequent basis, the profits of which can be invested in growing the validator’s stake, further centralising the network. This effect is amplified by the economics of multi-block MEV.

Multi-block MEV

MMEV or Multi-block MEV refers to any MEV strategy that is conducted over N>1 consecutive blocks. MMEV strategies are increasingly relevant following Ethereum’s recent change in consensus algorithm. To understand why this is, it can help to look at some key differences between PoS and PoW.

MMEV and PoW vs PoS

The probabilistic nature of solving the ETHash puzzle under Proof of Work, meant that there was no guarantee that a particular mining pool, no matter how large, would solve this puzzle for consecutive blocks. Even if mining pools were to strategically withhold and release blocks to the network in a strategy known as selfish mining, there remained an element of chance and therefore risk to the miner that they are unable to find the next block before anyone else. In this case, the miner would not only miss out on the MEV opportunity, but also the block reward for the initial block.

Under Proof of Stake however, the entire validator set for all 32 slots in an epoch is known 1 epoch or 6.4 minutes in advance. This is due to the epoch $N$ seed being based on the RANDAO mix from the end of epoch $N-2$ - as set by the MIN_SEED_LOOKAHEAD parameter. Thus, validators within epoch $N$ are able to know ahead of time i) whether they will have the opportunity to propose a block, ii) consecutive blocks and iii) the identities of all other proposers in epoch $N$.

Multi-block Strategies

There are several new strategies that are made possible by this e.g. multiblock statistical/atomic arbitrage, novel sandwich attacks, TWAP manipulation to name a few. Let us consider the following scenario for simplicity: $T_a$ at block $N$ creates a profit opportunity that can be capitalised on with $T_b$ at block $N+1$. There are several permutations of this particular trade, 3 of which are listed below:

1. Validator A has been selected to propose a single block in the current epoch at slot $N+1$. Armed with this knowledge, they submit $T_a$ through a private mempool to be included in the block being proposed at slot $N$. By using a private mempool $T_a$ never hits the public mempool and only becomes public knowledge once the block has been proposed. The profit opportunity is now visible to all and searchers rush to capitalise on it by submitting $T_b$ to be included in the next block. Unfortunately for them, Validator A is in control of the transaction ordering for the block during slot $N$, and places their own $T_b$ at the top of the block capturing the profit.
2. Validator A has been selected to propose a block in the current epoch for consecutive slots $N$ and $N+1$. The Validator submits the same transactions as above, but doesn’t need to rely on private relays or builders for $T_a$ who could theoretically censor the transaction or frontrun it themselves. Furthermore if the span of blocks that Validator A was selected for was greater than 2, there could have been additional MEV to be extracted in slot $N+2$ due to second order effects of $T_a$ and $T_b$.
3. Validator A has been selected to propose a single block in the current epoch at slot $N$. Validator B has been selected for the following slot $N+1$. Validator A knows who the proposer is for slot $N+1$. If Validator A can convince Validator B to co-operate and share the profit then a similar sequence to the above can take place.

In the absence of reorgs (which are significantly less frequent under Gasper vs Nakamoto consensus) or consensus attacks, the aforementioned ‘element of chance’ under PoW has been removed - MEV can now span multiple consecutive blocks with significantly less risk to the validator. As before, this dynamic favours large validator pools who benefit disproportionately from multiblock MEV rewards. It should be noted that block builders could also take advantage of multi-block opportunities albeit with an element of risk due to the need to win consecutive blockspace auctions.

MEV Mitigation

MEV is an inherent property of permissionless blockchains - auditability, arbitrary complexity of interoperable smart contract chains and atomicity of execution fosters such an environment. Of course some MEV is necessary and beneficial. Current efforts are directed towards MEV minimisation and democratisation at all levels of the stack - recent work has shown that MEV redistribution can reduce the likelihood of certain economically insecure equilibria for PoS systems.

Proposer-Builder Separation (PBS)

Pushing back against the centralising force that is MEV is the idea of separating block proposing from block building. PBS has been put forward as a means of democratising access to MEV revenue to validators of all sizes, thus preventing validator centralisation. The complexity of MEV extraction is outsourced to block builders who absorb the economies of scale and purchase blockspace from proposers ensuring that their execution payloads are included in the block. In theory, this would allow validators of all sizes to reap the rewards of MEV and remain decentralised.

MEV-Boost

MEV-boost is a sidecar implementation of PBS built by Flashbots. It exists as a middleware layer between validators and block builders rather than being an in protocol addition to the consensus layer. MEV-Boost allows proposers to access the most profitable block submitted by block builders via relays - trusted intermediaries that check blocks for validity and act as a data availability layer for proposers, whilst escrowing and routing the execution payloads on behalf of builders.

It should be noted that there is nothing stopping validators from using these tools to build blocks themselves. It is therefore conceivable that the current implementation could be used by validator pools to extract even more MEV than they otherwise would - from their proposed blocks and other validator's blocks by leveraging their aforementioned economies of scale.

Risks of Builder Centralisation

Unfortunately PBS as it is today simply redirects the centralising forces from proposers towards block builders themselves. Access to data, greater incentives to co-locate with block relays and validators (due to deterministic block times) and algorithm development all point to the emergence of highly specialised block builders, with the necessary resources to invest in these optimisations.

It is conceivable that a handful of the best block builders will consistently outperform the rest, building the vast majority of blocks included in the canonical chain. By virtue of having a high inclusion rate, a successful builder is able to attract more order flow from end users and searchers that want their transactions to be included as quickly as possible. This additional order flow results in more profitable blocks being built, which bolsters the builders dominance in what becomes a self-reinforcing cycle. PFOF (payment for order flow) is yet another centralising force which risks making the builder market uncompetitive for new builders with large incumbents dominating the market.

Decentralising Builders

Builder centralisation increases the risk of censorship - the effects of which can be readily observed in many of the blocks proposed today. As a result, development efforts are focussed on 2 main areas:

• Constraining builders: some initial ideas put forward are based on the concept of partial block auctions; namely crLists and (pre-commitment) proposer suffixes. The idea is to prevent builders from being able to decide on the entire contents of a block, limiting their ability to censor by allowing honest validators to add a list of transactions to be included.
• Decentralising builders: the challenges here are many and include aggregator-proposer collusion as well as the technical feasibility of making a decentralised builder that is competitive with centralised ones. At the middleware layer, projects such as SUAVE are aiming to tackle this problem with an encrypted mempool and progressively decentralised builder. Research to find an optimal way to implement an in-protocol PBS (IP-PBS) is currently underway.

MEV skews the distribution of validator rewards where a select few capture the most value. The variance of MEV between block producers could be reduced with ‘MEV smoothing’ which results in a more equitable distribution of MEV to stakers.

At the application layer, dApps could be built to capture the MEV they produce and distribute a portion of it back to their users. Existing projects such as Rook offer ‘backrunning as a service’ where a portion of the MEV is distributed to users submitting transactions through their RPC.

MEV Minimisation

At the protocol layer, there are several proposed methods for MEV minimisation which have varying tradeoffs in UX or trust depending on the use case.

• Timelock encryption: a.k.a on-chain commit-reveal schemes e.g. using VDFs (verifiable delay functions) where transactions are submitted in an encrypted state, hiding any MEV, are ordered and subsequently decrypted only after being committed to the chain. This however can result in delayed execution that will inevitably result in arbitrage opportunities and reverted txs for time critical transactions such as DEX trades.
• Threshold encryption: a.k.a off-chain commit-reveal e.g. an m of n committee combining signatures to decrypt transactions - this relies on a ⅔ honest majority and will need to be permissioned reducing decentralisation.
• Fair ordering: e.g. FSS or Wendy, where a committee receiving incoming transactions, orders them such that the ordering is fair if honest nodes see T before T′. This relies on an honest majority of oracle nodes, does not eliminate all kinds of MEV (e.g. backrunning) and could in fact move MEV to this network layer in the form of latency wars.
• Trusted third party ordering services such as segregated mempools or P2P matching networks can be used to hide a transaction in a private mempool/order book where it is safe from front-running and sandwich attack bots scanning the public mempool - currently however users must trust the operators of these centralised services not to censor or frontrun the transactions or blocks themselves.

At the application layer designing dApps to only expose the MEV that is strictly necessary, or at the very least minimising what cannot be eliminated. In the context of DEXs this includes:

• DEX aggregators which reduce sandwich attack profitability by splitting orders into multiple smaller orders
• Optimising slippage tolerance prior to order submission
• Novel AMM designs that aim to capture MEV and return it to LPs
• Concentrated liquidity on Uniswap V3 allows users to set tighter slippage and requires significantly more upfront capital for an attacker to move the price, making sandwich attacks less attractive
• Off-chain RFQs - although a user cannot receive a worse price than they were quoted, unfortunately these can still be frontrun by a byzantine market-maker on other venues e.g. centralised exchanges

Interesting sidenote: at the height of sandwich attacks in early 2021, projects such as Salmonella were designed to (successfully) trap would be attackers in a reflection of the communities frustration with the status quo

A one size fits all solution is highly unlikely as the appropriate tradeoff will vary between applications and the chains they run on.

Closing Thoughts

It has barely been a month since the Merge, but there are already some interesting patterns emerging around validator behaviours, builder/relay dominance and censorship. What remains to be seen is how external factors will influence block construction over time. Will high profile validators only propose blocks with 'benevolent MEV' (avoiding exploitative MEV) due to regulatory or social pressures? In doing so, are they leaving money on the table and allowing a subset of opportunist validators to profit from this, increasing their stake and therefore influence in the network? Where will the battle for order flow be fought and how can we mitigate against it?

Another interesting and largely under-explored area is the combinatorial explosion of opportunities created by multi-block, cross-domain MEV - that is MEV spanning multiple blocks across multiple blockchains. It stands to reason that validators who are proficient at extracting multi-block MEV on Ethereum Mainnet will be well equipped to run validators or sequencers on other blockchains - what happens when these proposer slots are concurrent? How will MEV fragment and concentrate across Ethereum L1 and L2s?

Conclusion

The MEV landscape on Ethereum today is significantly more complex than it was a few years ago. It is reasonable to expect additional complexity to emerge as the industry continues to mature. Left unchecked, MEV can have detrimental effects on decentralised networks, however these issues are known and there is a concerted effort to address them.

This primer kicks off what will be a multipart exploration of the dark forest. If you're as excited by complexity as we are, don’t be a stranger! You can reach me by email at ahmad@numeus.xyz.

We’ll be posting our research on a regular basis so follow us on Twitter and consider subscribing to our newsletter to stay notified!