Introduction
MEV, or Maximal Extractable Value, is a uniquely DeFi phenomenon that emerges as a byproduct of blockchain design. At its core, MEV is simply an instance of profit-maximizing behavior, whereby the validators that operate a blockchain seek to maximize their profit on their task of transaction-validating. While one can argue that MEV can be beneficial through improving capital efficiency, MEV can significantly affect the user experience in using decentralized applications, including higher gas fees, slippage, as well as the risk of collusion and centralization of validators. Within this essay, I will first examine MEV as a theoretical concept, as well as the systemic risks that it poses to the ecosystem. Next, using Flashbots as a case-study, I will examine how the DeFi community has attempted to resolve all these negative externalities of MEV, before explaining why the story of MEV is an emblematically DeFi story: one that exposes many of the underlying questions, challenges, principles, and tradeoffs towards building a truly decentralized financial system.
The “Flash Boys” Club
MEV is a feature, rather than a bug of blockchain technology. Within a given blockchain network, it is the validators (or the miners in a traditional PoW model) that decide what data is put onto the chain. Specifically, they can control what data is included and excluded, as well as how this data is ordered on-chain [1]. And as it turns out, some transactions are more profitable for validators than some others. Thus, as rational economic agents, validators will arrange transactions in a way that maximally profits themselves in terms of transaction fees.
This concept of MEV was first formalized in detail by smart contract researcher Phil Dainan in a seminal paper called “Flash Boys 2.0,” in which researchers highlighted how there exist a myriad of bots and arbitrage agents that attempt to “anticipate and exploit” ordinary users’ DEX trades, similar to how high-frequency traders in traditional finance aggressively optimize for transaction latency [2]. And to get a sense of the scale of this phenomenon, just within the last 24 hours of writing, 2578 ETH, or around 4.9 million USD of profit has been realized through MEV operations [3].
Although MEV is a generic umbrella term that encompasses many different arbitrage methods and scenarios [4], there are several key features that underwrite many of DeFi’s MEV opportunities. Firstly, much of MEV is made possible through a process of “priority gas auctions” (PGAs) where users can pay higher transaction (gas) fees in order to have their transactions run first [2]. As many arbitrage bots rely on having their transactions being run first in order to reap profit, these bots will engage in gas-bidding wars, ordering higher and higher prices to have their transactions be run by the validators, in turn causing high network congestion and out-pricing the average user who won’t get their transaction run, unless they too pay an exorbitant transaction fee.
Validators, on the other hand, are one of the key beneficiaries of this practice. Indeed, with great power comes great profit: because validators (at least theoretically) hold the power to determine which transactions are run, they can benefit from “ordering optimization” fees by determining which transactions give them the most cash. In practice though, having the validator do the entire MEV-searching, packaging, and execution pipeline is simply too much work [5]. Thus, most of the “ordering optimization” is outsourced to dedicated searchers, builders, and relayers, intermediaries which you can imagine as the “secretaries of the validators,” that each simplify the process of MEV in exchange for a cut of the profits. Specifically, searchers will find MEV opportunities, builders will bundle those opportunities into full “blocks,” and relayers will send these full “blocks” to the validators, or the actual block builders. Thus, a general picture of the modern MEV ecosystem looks like this:
MEV Ecosystem. Source: https://chain.link/education-hub/maximal-extractable-value-mev
As we’ve hinted at before, although MEV-enabled arbitrage can have some benefits, including higher capital efficiency and ensuring that prices will stay the same across different exchanges, there can be huge externalities for the end user, such as leading to higher transaction fees, slower execution, and higher slippage (such as the case of sandwich attacks). This however, is not the greatest risk that MEV poses for a blockchain – MEV practices can actually undermine the security guarantees of a blockchain’s consensus layer, especially if validators collude together [5].
This security problem arises from a problem of incentive alignment – with all these lucrative MEV opportunities, miners can earn far more by optimizing for transaction fees rather than sticking to the constant block-reward stipend. As Dainan writes, this means that:
As a result, a miner can fork a high-fee block, holding back some fees to attract other miners to build on the fork. In extreme cases, incentives to deviate from the protocol may lead to disruption in miner strategies for economically rational miners, reducing the security provided by block confirmations. [2]
This is known as an “undercutting” attack, and is just one of the several ways in which MEV can undermine the fundamental security guarantees of a blockchain. Other known attacks include a “time-bandit attack,” where instead of colluding to steal lucrative transactions from the current block, validators steal and exploit MEV opportunities from past blocks through colluding to rewrite past history. Furthermore, MEV extraction doesn’t even need to lie on-chain, as it is completely possible for all this to be done through backroom deals off-chain, such as between large traders and validators.
So as we can see, there is much at stake (pun intended) [6].
Flashbots and the Fight Against MEV
Given these potentially dire consequences of unchecked MEV, there have been several projects and teams dedicated to mitigating the negative externalities of this practice. One of the most important teams in the space is Flashbots, a project dedicated to re-align MEV incentives in a way that both sufficiently rewards validators for honest actions in building the chain, while also mitigating the worst effects for ordinary users.
To this end, Flashbots seeks to take three distinct steps: (1) illuminate the MEV “Dark Forest,” (2) democratize the extraction of MEV, and (3) redistribute benefits back to the ecosystem. For the first goal, Flashbots has a dedicated product called MEV-inspect aimed at “illuminating” the “Dark Forest” of MEV in order to quantify the negative externalities caused by MEV and highlight the scale of the problem [7].
The other two goals of “democratizing the extraction of MEV” and “redistributing benefits,” on the other hand are far more complex, comprising of an entire suite of products, gradually evolving as the problem scope and emphasis also shifts. In some respects, one could argue that Flashbots product development history over the past two years itself has been a timelapse of Ethereum’s growth and development [8].
The first major set of products Flashbots released was the MEV-Geth client, or a modified version of Ethereum’s Golang implementation that is better able to prevent MEV manipulation through routing this to a private transaction pool [9]. An MEV auction marketplace was built on top of this new client, using a “first-price sealed-bid auction” method (also known as a “blind auction”), where each participant is only allowed to submit one price, and none of the auction participants know what prices the other participants bid [10]. Through this design, Flashbots mitigated the previously discussed “price-bidding” wars that cause increased network congestion.
The guiding principle behind creating MEV-Geth and an MEV marketplace is to diffuse both the powers and the responsibilities of the validators that build the blocks themselves through a process of incentive realignment called “proposer-builder separation” [11]. Instead of having to do the complicated process of both MEV searching and bundling up transactions, validators using the MEV auction can simply look at the MEV marketplace, find which transactions will give them the highest MEV, and place a single bid that reflects their actual preferences. Moreover, to prevent validators to include their own transactions and profit from frontrunning users’ transactions, actual transaction details (a buy order, a sell order, a liquidation etc.) are not revealed until the block-building is already complete [12].
So why would validators actually use this algorithm and give up the aforementioned lucrative MEV opportunities? This is because this Flashbots algorithm of simply picking MEV transactions from a marketplace was far easier and cheaper to run for validators. And as more and more high-quality MEV transactions go through this marketplace instead of directly on-chain, validators are able to reap higher rewards through sticking with the Flashbots implementation. And the results were incredibly impressive: just soon after MEV-Geth was released, over 90% of Ethereum validators began using this implementation, thus showing the importance and effectiveness of incentive realignment in solving a potentially existential issue [8]. But as the Ethereum ecosystem evolved and moved from a Proof-of-Work (PoW) model to a Proof-of-Stake (PoS) model in September 2022, this change in Ethereum’s underlying consensus structure necessitated an update of how the idea of “proposer-builder separation” is conceived [13].
The main reason why PoS is more efficient than PoW is because instead of having every node build and propose blocks from scratch as in PoW, in PoS there is only a handful of validators that serve as the primary block proposers to append data to the blockchain. While this is great for the environment and great for computation efficiency, with the lucrative appeal of MEV this could pose an additional centralization risk, especially if validators (“proposers”) collude with key “builders” on the seller-side of the market. Even Flashbots itself, running the private transaction pool could fall prey to the lucrative allures of collusion, and of course, placing trust within a single entity, such as Flashbots, goes against the ethos of decentralization.
MEV Boost System Diagram. Source: https://github.com/flashbots/mev-boost
Thus, Flashbots released MEV-boost, which was a piece of software that decentralized the “supply side” of this MEV marketplace. Instead of containing only transactions in the Flashbots private transaction pool (essentially a monopsony), MEV-boost allowed any builder running this software to submit transactions to all participating validators [14]. For the validators, with many more builders participating in the construction of all these different blocks, this allowed greater revenue, and evened out the playing field of which validators had access to which transactions, in turn building a more robust and secure ecosystem [15]. As before with MEV-Geth, this novel design realigns incentives of multiple parties to avoid centralization risk, and had a resounding success, with over 85% network adoption, of which Flashbots only relayed 34% [16].
Flashbots SUAVE
Thus far, however, the quest to mitigate all of the centralization risks and make decentralized finance safe from the most harmful effects of MEV is still unfinished. In implementing proposer-builder separation, Flashbots’ solutions have diffused, or rather redirected, the key power and responsibility of validators to “builders,” introducing these “builders” as separate entities from validators that do the picking-and-choosing of transactions for the validators. As it turns out, there exist significant builder economies of scale, which in turn lead to centralization risks in the builder role.
So what do these economies of scale look like for the builder role? Recall that previously, we’ve mentioned how searchers, builders, and relayers all play separate role, with searchers searching for MEV opportunities, before sending these to builders, who in turn sent full blocks to relayers. This means that searchers must choose who to send their results to. In order to maximize their own return, they will choose the highest-quality builders, who will have their transactions selected by the validator the most often. As more high-quality transactions go to the top builders, this creates a centralizing effect, where the top builders will always get the top MEV transactions from searchers, in turn cementing their position [17].
Builder Centralization Effect. Source: https://simbro.medium.com/mev-driven-centralization-in-ethereum-ec829a214f18
This builder centralization effect is borne out in practice. Within the last 24 hours of writing, the top 5 builders have proposed around 90% of the total MEV-Boost blocks [18]. And with this level of concentration, these oligopolies could start using their dominant positions to manipulate transactions, including collusion and censorship of certain transactions, all of which again could compromise the security of underlying blockchain. This is the motivation behind Flashbots’ latest project: the Single Unifying Auction for Value Expression, a project aimed at disbanding the block-building process from any single blockchain, and outsource this to a separate network, and thus decentralizing the role of the block builder [19].
SUAVE and L1 Blockchain Stack. Source: https://writings.flashbots.net/the-future-of-mev-is-suave/
SUAVE is in effect a separate and dedicated block sequencing chain that will take care of the transaction mempool and builder roles, while the validators of the native chain such as Ethereum will take care of the proposal and attestation roles. As we can see, SUAVE is thus a natural extension of the “proposer-builder separation” principle, where instead of keeping the proposer and the builder on the same chain, we put them onto two completely separate chains, so that they are both sufficiently decentralized and separated from each other. Moreover, the vision of SUAVE is that it will serve as the common sequencing layer for many different chains, such that no matter if you are a validator on Ethereum, Arbitrum, Polygon, or any other EVM chain, you’re able to use SUAVE to find the best MEV opportunities, not only for the native chain that you are on, but also for cross-domain MEV from cross-chain transactions that you could not have gathered from just looking at the transaction mempool of that chain alone [19].
SUAVE Across Different Chains. Source: https://writings.flashbots.net/the-future-of-mev-is-suave/
Nonetheless, although SUAVE has a grand vision of MEV that ultimately benefits all parties involved and allows the Ethereum ecosystem to be more decentralized, in the 6 months since its inception in November 2022, there remain several key design issues to be worked out. One of the core issues, for example is whether to build SUAVE as a separate L1 chain (similar to Chainlink), or use a rollup solution, or use a restaking service that “borrows” Ethereum validators like Eigenlayer [20]. Each of these solutions has its distinct tradeoffs in terms of ease of implementation, validator retention, security, and flexibility, which we won’t discuss in detail here.
Another core question is whether SUAVE will release its own token. Although the SUAVE forum currently denies that it will launch its own token “for now” and keep using ETH as its native token on chain, there are several doubts on whether Flashbots will stick to this, especially since launching a SUAVE token seems to make the most economic sense for Flashbots as a private company in the long run [21]. Moreover, one could make a fair argument that the reason why Flashbots believes it can raise a unicorn valuation of $1 billion in a bear market is the implicit promise of a future SUAVE token launch [22].
So what’s holding Flashbots back from announcing that it is launching a SUAVE token? As it turns out, launching a token brings several headaching design decisions. For example, would this token have utility for certain transactions or simply be “another governance-only token”? If this token were to have utility, how would this utility look like? How could the different stakeholders using Flashbots (eg. different chains, end users, builders on Flashbots etc.) all be incentivized to use and trust this new token, as opposed to more established tokens such as ETH or even L2 tokens such as ARB [21]? There is an intricate and hair-pulling process of incentive alignment that needs to be worked out in either case; thus it completely makes sense for the Flashbots team to avoid for time being.
Beyond Flashbots: The Bigger Picture for DeFi’s Future
Although it is far too early to tell what shape SUAVE will ultimately take form, and whether this brand-new sequencing chain will succeed in its initial goals and align incentives in a way that truly mitigates the negative externalities of MEV, I believe that the phenomenon of MEV and Flashbots represents a quintessential image of the various tradeoffs, questions, and principles in designing a truly decentralized financial system.
Firstly, as mentioned before, MEV is a feature, rather than a bug of blockchain design. These arbitrage opportunities and profit incentives for validators derive from the instant accessibility of the blockchain, and guarantee the capital efficiency of DeFi. The negative side-effects of MEV, including congestion, gas-wars, and slippage for the end user are simply byproducts and negative externalities of this process.
By definition, a negative externality does not affect the agents that engage in the negative behavior. In this case, causing network congestion and slippage for end users doesn’t harm the validators or arbitrage bots that are engaging in this profit-seeking behavior. In traditional economics, it is well-known that a pure market-based system cannot well account for all of these externalities. Traditionally, it is the government or some other regulatory authority and steps in to correct market dynamics and minimize the impact of the negative externality (eg. taxes on tobacco and alcohol).
DeFi, on the other hand, is by its very nature trustless and opposed to any form of human government enforcement. The closest that it has to coming an “enforcement agency” is through encoding rules and regulations in code (such as through smart contracts) that are deterministic and transparent. Thus, as Flashbots’ story shows, reducing the negative externalities of a phenomenon such as MEV is always reliant on an elaborate process of incentive re-engineering and alignment. After all, just like Wall Street quant traders, DeFi arbitrage bots are not known for their high moral standards and goodwill of heart.
This method of using incentive re-engineering to reduce MEV’s negative externalities aren’t just intrinsic to Flashbots either [23]. Beyond Flashbots, there are numerous other teams that attempt to realign incentives to develop protocols that realign incentives to reduce MEV’s impact. For example, Chainlink’s Fair Sequencing Services (FSS) leverages its decentralized oracle network to outsource the “transaction ordering” process away from validators, achieving something analogous to what the SUAVE network seeks to aim for [24]. Another example is the idea of “coincidence of wants” (CoW) mechanism on CoW Protocol (formerly Gnosis chain), which automatically glues transactions together based on if they complement each other (eg. I want 1500 USDC for 1 ETH, and you want 1 ETH for 1500 USDC), and uses a solver algorithm to ensure that everyone trades at an optimal price [25].
But incentive re-engineering, particularly in a decentralized setting without trusting any single party, can be a hair-pullingly difficult task, as fundamentally you are trying to counteract economies of scale. In the case of Flashbots’ builder centralization, for example, builders that have “proved their worth” are more likely to be “trusted” by searchers, who in turn will give them more high-quality transactions and cement their position as market leaders. To identify, solve, and implement a decentralized alternative through incentive re-alignment is essentially playing a game of “whack-a-mole” – you will never know how a newly introduced incentive system may contain loopholes of centralization and hidden economies of scale, and all of these will only retrospectively make sense.
Moreover, in a complex system (such as the blockchain) with many different stakeholders and agents, it is almost impossible to avoid externalities, as there will almost certainly be a corner case where the actions of one stakeholder will spillover and affect the actions of another. And, as Dainan has shown in “Flash Boys v2.0,” many of these externalities can pose very real threats that undermine the stability of the entire system. Thus, any decentralized system – even those with well-engineered game-theoretic principles – will always have this innate intricacy, delicacy, and fragility to it, where a single unforeseen loophole can threaten its very existence.
Compared with centralized systems, in which it is obvious how such a system may be corrupted (so it is possible to create necessary countermeasures), decentralized systems do not contain any obvious “single point of failure” – but it is precisely this that makes decentralized systems sometimes even more lethal than their centralized counterparts. Instead of having no “single points of failure”, every node can potentially be a “single point of failure,” if there is a loophole in system design.
Ultimately, the story of MEV and Flashbots tells us how maintaining the health of a decentralized system will always require a consistent, Herculean effort – a consistent participation in a game of “whack-a-mole.” A diffusion of trust in a decentralized system necessitates a diffusion of responsibility and a diffusion of vigilance, especially as there is so much financial incentive at stake: for better or for worse, MEV is here to stay.
About the Author
0xFishylosopher, or Jay, is an undergrad at Stanford pursuing a double major in Computer Science and Philosophy. He serves as the founding Editor-in-Chief of the Stanford Blockchain Review and Head of Content at Stanford Blockchain Club. Outside of Stanford, he is also a Student Fellow at Rough Draft Ventures, the student branch of General Catalyst, and serves as a Researcher for Web3.com Ventures.
References
[1] https://ethereum.org/en/developers/docs/mev/
[2] The paper name of “Flash Boys v2.0” is a reference to Michael Lewis’ exposé “Flash Boys” on Wall Street high-frequency traders: https://arxiv.org/pdf/1904.05234.pdf.
[3] From Flashbots Transparency Dashboard as of May 6: https://transparency.flashbots.net/
[4] https://www.coindesk.com/learn/what-is-mev-aka-maximal-extractable-value/
[5] https://chain.link/education-hub/maximal-extractable-value-mev
[6] https://writings.flashbots.net/frontrunning-mev-crisis
[7] https://github.com/flashbots/mev-inspect-py
[8] See Section I: https://writings.flashbots.net/the-future-of-mev-is-suave/
[9] https://github.com/flashbots/mev-geth
[10] https://etherworld.co/2022/04/05/mev-research-report/#section111
[11] Vitalik’s discussion on PBS: https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725
[12] https://docs.flashbots.net/flashbots-auction/overview/
[13] Discussion of MEV in ETH2: https://writings.flashbots.net/mev-eth2/
[14] MEV Boost Docs: https://boost.flashbots.net/
[15] https://writings.flashbots.net/why-run-mevboost/
[16] MEV Boost dashboard data as of May 6: https://www.mevboost.org/
[17] Details on builder centralization: https://simbro.medium.com/mev-driven-centralization-in-ethereum-ec829a214f18
[18] Builder centralization statistics, data as of May 6: https://www.relayscan.io/
[19] See Section II and III: https://writings.flashbots.net/the-future-of-mev-is-suave/
[20] Discussions on routes for SUAVE’s technical implementation: https://collective.flashbots.net/t/suave-economic-security-models/1070
[21] See “Is Flashbots a Bad Business”
[22] Flashbots recent raise: https://www.theblock.co/post/203637/flashbots-fundraise-billion-dollar-valuation
[24] Chainlink FSS: https://blog.chain.link/chainlink-fair-sequencing-services-enabling-a-provably-fair-defi-ecosystem/
[25] CoW protocol: https://docs.cow.fi/overview/introduction
All Comments