In this article we take a look at the latest developments in MEV and what that could mean for the future of The Ethereum Network.
Currently MEV searchers use services like Flashbots to avoid front running. This has been hugely profitable for validators to the extent that the majority of validators now run Flashbots. Although Flashbots is working on fully decentralising its Relay right now it is centralised.
In August 2022, one month before The Merge was due to take place, The US Government announced a set of OFAC sanctions. For the first time these OFAC sanctions included lists of Ethereum addresses. This created a legal precedent for censorship and was a major test for The Ethereum Network.
Flashbots, being partly based in The US, was then compelled to add censoring code to its relay which in turn led to de facto censorship across a majority of validators.
The Important part: The Ethereum network design still prevents full censorship as long as a small percentage of the network validators are non-censoring. Essentially OFAC transactions can still get into a block by waiting until a non-censoring validator wins a slot and includes their transition. Right now 67% of blocks are censored. However at its peak it reached 78%.
Actually The OFAC Sanctions did not have a drastic effect from a technical standpoint. However it did serve as a wake up call which led to fast tracking and prioritisation of MEV solutions and the open sourcing of The Flashbots Relay and later the Flashbots Builder.
Since peak censorship on 21st November 2022 the amount of non-censoring relays has slowly increased with the open sourcing of Flashbots Relayer & Builder. New players have also entered the block building space to offer non-censoring MEV services. For a full list of relayer services see mevboost.org. Currently about 73% of blocks are produced using Flashbots software.
Relying on the community to diversify block building has prevented full censorship so far but in the long term the aim is to create a system that is resilient at the protocol level. In the interim one of the latest technical solutions from Flashbots has been to add the min-bid parameter.
-min-bid 0.06 \
-relay $YOUR_RELAY_CHOICE_A \
-relay $YOUR_RELAY_CHOICE_B \
The min-bid flag is made possible by The MEV-Boost “sidecar” design. This allows MEV-Boost software to be run as an add-on to any validator client without modification. This is a big improvement over the original Flashbots Relay design which required all validators to run a custom version of geth called mev-geth.
With Mev-Boost validators can fallback to build blocks locally if the Flashbots Relay goes down. With Min-bid the validator will only accept MEV blocks that bid above the min-mid and fallback to locally built blocks when the min-bid is not met. Flashbot is calling this The Cost of Resilience.
With min-bid validators can get the best of both worlds. Trading some censorship resistance when Mev blocks rewards are high while also having the ability to produce blocks locally when the rewards are low.
The Long Term Roadmap
Now after years of research and discussions there is substantial consensus on the technical MEV roadmap. To reflect this Vitalik officially added a new track to his roadmap diagram in early November 2022. The track, called ‘The Scourge’ sets out protocol level changes related to MEV.
See Vitalik Tweet
- In-protocol PBS (Proper/Builder Separation) is now a key milestone.
- PBS to make use of inclusion lists.
- MEV burn proposed (simpler form of MEV smoothing)
- A Distributed Builder Track will look to decentralize the builder layer
PBS (Proposer/Builder Separation)
PBS is a design pattern that splits the proposer and builder functions into separate roles to isolate the validation of blocks (the proposer) from the negative externalities of MEV and block construction (the builder).
Mev-boost is essentially an off-chain implementation of PBS. In the future we will likely see more of the block building, bundle auctioning and relaying functionality go on chain. This should make block building & MEV less problematic and the network much more resilient.
The PBS spec is subject to heavy iteration but currently the two most prominent schemes are:
Both allow for builders to bid for block space while keeping block contents private. Both are in-protocol and provide decentralised, censorship resistance.
Inclusion Lists (formerly crList)
In the interim before PBS is fully enshrined at the protocol level we might see some variation of inclusion lists. Inclusion lists are a straightforward way to enforce transaction inclusion and reduce censorship risks. The idea is that block proposers specify a list of transactions that must be included in the block. This removes the ability for the builder or relayer to censor the network. However, including the list may reduce the MEV profit for the builder and thus reduce the block bid. So the most profitable thing for a proposer to do is leave the list empty. Similar to the minimum bid idea of Flashbots there is a cost of resilience.
One variation of inclusion list is forward inclusion lists. In this setup proposers create inclusion lists for the block immediately after their own. A builder is not forced to include all the transactions as long as they can fill the block. If they don’t fill the block they must include the transaction list. This solves the cost of resilience problem and prevents builders from losing MEV while making it expensive to censor transactions.
This is essentially a simplified version of MEV smoothing. Right now high levels of competition see builders sacrificing a majority of their MEV profits to validators in order to ensure their block makes it into a slot.
MEV Burn award slots to the propoper who can provable burn the most ETH. The ETH burned would essentially be the block builder’s bid and thus close to the total MEV for a current slot. Not only would this regularise the validation reward it would also have a deflationary effect on Ether.
The nice part about this idea is…
It also enhances and protects ETH’s monetary premium: any opportunity that extracts value would result in the burn of an amount of ETH of equivalent value, even if the MEV opportunity doesn’t involve ETH at all (e.g. if a given token is paired with USDC and there is an arbitrage opportunity for 100 USDC, then 100 USDC’s worth of ETH will have to be burned for this arbitrage to be exploited).
The Distributed Builder Track
This track is mostly about using various ZKP, or secure enclaves to create complex distributed builder commit reveal architectures. You can read about it here
What will be the role of Flashbots once PBS becomes part of the core Ethereum protocol? Flashbots plan to build SUAVE — the Single Unified Auction for Value Expression. This will be a standalone blockchain that can act as a ‘plug-and-play mempool and decentralized block builder ’ for any blockchain.
SUAVE is aiming to tackle cross domain MEV and so could still turn out to be an essential part of the overall blockchain MEV landscape.
Two years ago MEV was an existential threat to Ethereum. Today Ethereum, when it comes to MEV, is the most highly researched and battle tested blockchain. Although problems still exist the theoretical solutions are there and simply need the time to be implemented. The Ethereum community is really pushing the envelope when it comes to protocol design and 2023 should be super exciting for the MEV space.
To stay up to date and get involved with the latest research and discussions in MEV check ethresear.ch: