# Understanding MEV and Flashbots

James Olsen, Douglas Atherton

Constructing a new blockchain network has revealed itself to be a task heavily dependent on ensuring a well-aligned incentives framework for all participants. Without such a framework participants may partake in behaviour negative towards said network. Ethereum’s initial development of an incentives framework never accounted for the possibility of what has come to be conceived as MEV, and the following implications of this behaviour has required continued research. Organisations including Flashbots have been on the forefront of this research, and have sought to define the manners in which MEV could become aligned with a healthy network. Throughout this article investigation is made of what MEV is, what the implications of it have and could be, and how MEV could be standardised or limited through cryptographic or cryptonomic approaches.

# FAQ

## What is MEV?

Miner Extractable Value, or Maximal Extractable Value, is a concept used to describe the value that blockchain network participants extract from blocks by reordering transactions. For example, if a participant includes their own transaction buying an asset before another transaction buying said asset by another participant, this would constitute front-running that allows the participant the possibility of profit.

## Why can MEV be negative?

All value extracted by participants on a blockchain network typically must be extracted from somewhere, and as such will constitute lost income for other participants not partaking in this behaviour. Additionally in networks such as Ethereum participants will offer large gas fees to ensure their transactions are included in a block, driving up the price of gas for all users.

## Are there proposals to reduce MEV?

There are numerous proposals that have been put forth by open source research organisations such as Flashbots that can be commonly categorised into one of three groups: MEV auctions, batch auctions, and transaction ordering consensus. MEV auctions allow participants to ‘sell’ the right to extract value from a block to the highest bidder, and transaction ordering consensus allows participants to ‘vote’ on the ‘correct’ order of transactions in a block (and by extension ‘vote’ on what value can be extracted and by who). On the other hand, batch auctions are used to settle all transactions in discrete units, making it impossible to use efficient computational resources to attempt front-running or arbitrage.

## What is an MEV auction?

As in auctions that commonly occur outside of blockchain networks, MEV auctions allow owners of an asset (in this case being the right to extract value from a block) to the highest bidder. Only participants with the most efficient computational resources will be able to win any ‘bidding war’ for the right to MEV. Hence, the inefficiencies brought about by many participants competing to fill blocks with transactions only for the purpose of MEV, driving up gas fees in the process, will be theoretically reduced. To be implemented without flaw though, the properties of complete privacy and finality are required - challenges in their own right that require further work.

## How does the theory of ‘Priority Gas Auctions’ influence Ethereum?

One of the most noticeable implications of MEV that has been observed across blockchain networks such as Ethereum is the inflationary pressure on gas fees. Any rational participant will offer up to as much gas fees as value they can extract from a block to have their transactions included in said block. Any rational participant will also choose the transactions that offer greatest gas fees to include in their proposed blocks. Hence, as long as the MEV that can be discovered in a block increases, gas fees will likely increase too. Most solutions for MEV, either to reduce the possible usage of or to incorporate it as behaviour positive for the network, contend with this primary implication of its existence.

## Who are Flashbots?

Open-source research organisations including Flashbots seek to either reinforce and standardise the existence of MEV, or control and limit said actions. Flashbots first brought attention to their mission in 2019 in publication of their whitepaper, and have since developed or worked on tools to track the use of MEV across Ethereum and to implement MEV auctions in practice. Their most recent theoretical developments involve attempting to satisfy the properties of complete privacy and finality for their implementation of an MEV auction.

## What is MEV-geth and MEV-SGX?

Flashbots have in their time researching MEV implemented an MEV auction called MEV-geth, which takes significant amounts of computation typically performed on a blockchain network to an off-chain environment. By taking such computation related to MEV out of the blockchain network, increasing gas fees and blocks filled with ‘failed transactions’ can be tempered. However, this implementation so far has not been perfect due to not satisfying the property of complete privacy. Instead, MEV-SGX has seen development with the purpose of using new cryptographic schemes to allow for satisfaction of this property.

# Introduction

Miner Extractable Value, or Maximal Extractable Value (MEV), is the process of reordering, adding, or removing transactions in a block to extract value in the form of profit. As only nodes selected by the network to propose blocks may decide how to order transactions in a block, any node seeking to extract value from said block must be the proposer or have influence over the proposer themselves. Understanding this concept is important for all market participants because it can change the potential choices another rational participant will have available to them or choose to enact. In the initial architecture of most blockchain networks the design of incentives are set to ensure that the rational economic choice for a market participant is aligned with the long term health of the ecosystem. Many whitepapers that detail the technical or incentive architecture of these networks employ concepts of game-theory to appropriately adjudge how cryptonomics may be utilised to prevent malicious behaviour. However, MEV was never considered in the original design of Ethereum, or many other networks, and hence the design of Ethereum must either adjust for or accommodate these new cryptonomic influences. The incentives associated with extracting value where possible from blocks will only grow as the scope and magnitude of activities grows, and the consequences of inaction will become steadily more essential to understand. Hence, the urgency to consider MEV in the future design of blockchain networks and protocols cannot be ignored.

Several research and development organisations have been formed with primary aims including both tracking MEV and developing solutions to the negative implications of MEV. Flashbots is one such organisation that since publishing a number of papers in 2019 have continuously brought attention to the subject and their mission in response to said subject. Their tracking of MEV is in an effort to 'illuminate the dark forest'. While a potentially overused term in relevant literature, the 'dark forest' is an apt name for the arena nodes that intend to extract value through such mechanisms operate in. To any blockchain developer or researcher that has attempted to analyse Ethereum's blockchain data, it is known that it can rapidly escalate in complexity once one has moved beyond UIs such as Metamask. This systemic complexity is what shields the ‘dark forest’ from easy exploration, and although illuminating it does little to solve the issues raised by MEV in solitude of other actions, it is a necessary step to being able to make an informed decision on the future ramifications of the proposed solutions. It is for this reason that Flashbots and numerous other public research organisations have come into existence in the years since 2019, with varying aims, objectives, and proposals in response to the core questions at hand. While these efforts to control MEV across Ethereum and other networks are controversial to some in the community, they are undoubtedly successful and understanding their purpose, motivations, and strategy is vital to understanding the ongoing debate around MEV.

This article will highlight both the research conducted by some of these organisations including Flashbots and the previously referenced rationale behind these teams. Through such a scope the purposes of these individuals and organisations in this space can be understood, and importantly how the future of Ethereum looks to be shaped by potentially conflicting interests and perspectives. Covering this topic is also particularly relevant as an example of the directions other individuals and organisations can take in shaping their analysis of MEV and other incentive-aligned topics. Guided by the lessons of understanding MEV and the work done to resolve issues caused by this concept, current and future solutions and frameworks can be designed.

# Understanding MEV

In its simplest form, MEV can be illustrated as the capability of nodes to extract value through reordering transactions located in a block. To visualise how transactions are structured and how nodes can take these transactions and construct a block, reference can be made to this exploration of the journey of Ethereum transactions. Viewing the design of these transactions, and the methods in which they are executed within a block provides a solid foundation to understanding how value can be extracted simply through the process of reordering. Common examples of MEV include situations such as arbitrage, transaction front running, or any other pure revenue opportunities. While financial theory has often inspected these forms of attacks on institutions like the stock market, it is typically infeasible in these centralised contexts to extract value without sufficient complexity or support from trusted insiders (with exceptions dependent on the exact legal implementations of said centralised markets).

Simplified overview of how a block is constructed - the header (roof) of the block is more or less a separate structure from the body (floors) of the block, meaning a valid header can easily be applied to new bodies (with some extra work done).

In essence these situations are extended cases of standard market inefficiencies that would usually be nullified through the actions of other market participants or by the inability to so readily interact with a centralised financial platform. Instead, without appropriate incentives to encourage other market participants to not partake in MEV, or without the securities of centralised protection mechanics, it is sufficiently less feasible to prevent nodes from performing these behaviours. Although it would seem intuitively from the prior descriptions that only the value being directly extracted by the nodes through the insertion of their own transactions would be classified as MEV, this is not necessarily the case. For instance, in pure revenue opportunities there is a range of nodes all directly competing for the opportunity to include and reorder the transactions of participants in a block to extract the value that potentially exists. In this scenario (in the case of Ethereum and similar networks) the rational conclusion is for each participant to raise the gas price they offer to have their transaction included until the potential value from front-running or arbitrage for example is almost entirely eliminated. However, in this scenario the majority of the value is still going to the nodes in the form of gas fees paid by participants.

## Implications and Consequences

Concern over MEV is conceptualised into two broad categories of thought that can be reasoned through, those of a technical and those of an ethical nature. These concerns however are not necessarily exclusive; either overlapping or not representing the entire set of relevant implications that exist. As an example, remuneration for nodes is intended to allow for the paying of transaction fees as an incentive for acting in a manner that benefits the blockchain. Nodes as such will be encouraged to search out for any transactions they can find, and include as many in a block as they can (to an extent), and ensure that said block is executed and appended to the chain. In terms of the technical nature of challenges associated with MEV, the best interest of a node may not necessarily remain aligned with the blockchain’s best interest.

In exploration of this notion, using Flashbots MEV-explore tool, it can be seen that the average daily amount of MEV extracted in the period of a month is approximately \$4M or above. In contrast, in the same period, revenue earned from transaction fees averages between \$15M and \$60M, meaning that MEV can form anywhere between 5% and 20% of total revenue earned by nodes. Not all nodes tend to perform this behaviour though, meaning that the distribution would vary significantly from node to node in contrast to the average (i.e. some nodes may earn in excess of 50% of their income from MEV). Such significant magnitudes of revenue earned from this behaviour introduces a multitude of external incentives that could motivate negative actions. Examples of actions that might be taken include nodes submitting their own transactions to fill up large amounts of a block for the purpose of maximising their direct profit (without providing additional functionality in exchange). Alternatively nodes may drive up the prices of assets and gas for users in attempts of front-running. This increasingly profitable externality could eventually pose a threat to the consensus of Ethereum, as nodes become incentivised to act in unexpected or unimagined ways. It is in this capacity that the technical nature of challenges derived from the discovery of MEV can transition into challenges of an ethical nature. Arguments focused on the ethical aspects of MEV are generally based around the idea that most MEV extraction performed by a node is to the detriment of participants on the network. For participants using decentralised applications (dapps), MEV generally represents excess costs they are paying through inflated pricing of assets, increased service costs to submit transactions, or other restrictions that block desired functionality. Therefore from the perspective of many on a network, the existence of extractable value without any theoretical conception of a counter-balance in the design of Ethereum’s (or other blockchain’s) architecture is negative. Hence, further effects can snowball as further game-theory analysis may reveal, for example: less participants on the network reducing the security or liquidity of said network, more expensive assets increasing centralisation of resources to fewer participants, or there being incentive to attempt to censor transactions. For dapp designers, excessive MEV can be seen as a cost their users are paying which if reduced would be reflected as a direct benefit and therefore a competitive advantage for that platform. However, not all projects and organisations will typically view MEV through the same lens. Some see it as an integral component of the blockchain network - something that exists as a natural continuation of a functioning economic system. In comparison to the stock exchange where stockbrokers collect fees for their services in properly maintaining the exchange of assets or where organisations naturally appear to provide financial services such as upkeeping order books, MEV can be conceptualised as an alternative financial service. Alternatively, to control it presents an ethical challenge in of itself. Blockchain was intended to serve as a decentralised foundation for the creation of an economic system where the only law is what is written in code. Attempting to remove certain behaviours that some consider undesirable goes against this ethos and by some definitions could be depicted as censoring. There are a myriad of proposed avenues to address the existence of MEV, with projects adopting different solutions based on how the technical and ethical implications of this behaviour is viewed, positively or negatively. ## Responses to MEV ### MEV Auctions (MEVA) For those that view MEV as an inevitable continuation of blockchains to not be interfered with and censored, but fear the instability in consensus that is potentially caused by a negative incentives framework, there has been proposals and implementations of Maximal Extracted Value Auctions (MEVA). Conceptions of an auction have been applied to a variety of contexts in blockchain networks. By ensuring that there exists incentives to perform particular roles on behalf of the network, many negative consequences that might come about as the result of actions such as value extraction can be mitigated. Auctions target this theory by allowing certain roles as described to be ‘auctioned’ off to the highest bidder in a manner such that participants are able to visualise opportunities to earn profits for particular services. It can be theorised that any rational market participant bidding on an MEV auction for the right to extract value will bid up to just below the amount of MEV they believe is extractable from the blocks the auction pertain to. Standardisation of the right to extract MEV will in this scenario creates a more efficient market, as only the actors with capability to best extract additional MEV will consistently be able to win auctions and earn a profit. In addition, a percentage of all extracted value as described previously will end up being directed into the accounts of other participants depending on the exact roles specified by the auction. To demonstrate how this may be implemented an example of a possible MEV auction is put forth and illustrated below. Assuming the operation of a network where all participants hold perfect knowledge of the said network, two bidders can be emphasised from the set of participants; bidders$A$and$B$. One bidder,$A$, is described as having average value extraction capabilities, where extractable value is typically proportional to the computational resources said node has access to. They may only be looking to insert their own transactions as arbitrage transactions by copying existing transactions that have already been created to allow another node an arbitrage opportunity, allowing$A$to earn$x$value. In contrast$B$has marginally better capabilities for value extraction, perhaps only concerning themselves with arbitrage as well, but instead of just copying existing transactions they instead perform their own analysis on identifying arbitrage opportunities. The greater capability demonstrated by$B$allows the bidder to extract$x+r_{1}$worth of value. Example of how an MEV Auction would occur in a typical blockchain network. In an efficient market it would be assumed that an auction between the two bidders$A$and$B$would eventually set a value of$x$for the right to MEV for a given block, as bidder$A$would be willing to bid up this value until there is no profitable purpose for paying further. Any surplus extraction ability would therefore allow$B$to earn a value of$r_{1}$in profit following their purchase of the right to MEV. As$A$would be in a position that they are not currently able to earn any profit with their current capabilities, and as it can be assumed that the computational resources required to maintain said capabilities would need be earned back, they would seek to improve these capabilities to allow for the opportunity for profit. Innovating in a manner to create a new system that, for example, allows$A$to insert their own transactions right before every large transaction on a DEX in a way that takes advantage of the slippage tolerance on that swap (a sandwich attack), would be one likely course of action performed. Using this new system,$A$may be able to extract$(x + r_{1}) + r_{2}$value from any given block, meaning that they will earn$r_{2}$value. The pattern would then continue with$Blooking to achieve a similar or better improvement in their capabilities. Such patterns of behaviour are incredibly common and have been well researched with respect to any free market (as decentralised systems are ideally meant to represent). ### Batch Auctions While MEVA may be seen as an economic solution, baked into the architecture of a given blockchain network through a complex framework of incentives, there are also technological solutions to the subject at hand that can be codified into ‘law’. The primary difference between economic and technological solutions would be seen that while economic considerations attempt to realign the interests of market participants with those of a network, technological considerations attempt to block avenues for going against the interests of blockchains. Both solutions can work in the right contexts, but as has been mentioned previously there appears to be a potential need to focus on the economic incentives that drive nodes to perform unintended actions. Considering what has been proposed so far though in the form of auctions as an economic solution, there is potential room for a new perspective on a different type of auctions as a technological solution. It has been found through MEV exploration tools such as those developed by Flashbots that a majority of extracted value is derived from arbitrage and transaction front running through decentralised applications including decentralised exchanges (DEX). Changes in the settlement process for these DEXs to a system that supports batch auctions would significantly reduce the amount of value that can be extracted through either of these processes. Batch auctions are notably used in markets such as stock exchanges at the close of market ensuring that all transactions of specified types during specified time frames are grouped together to be settled as ‘one transaction’. This ‘one transaction’ means that, as an example, all trades performed to purchase an assetX$or sell an asset$Y$will be grouped together where the value of$X$or$Y$are set as the same for all these grouped transactions. If a DEX has taken the action of settling all transactions purchasing an asset$X$or selling an asset$Y$at a single price, then the timing or order of said transactions cannot be used to extract profit (in either the case of arbitrage or front-running as examples respectively). Typically if a node has knowledge of an impending transaction that seeks to purchase$\alpha$shares of$X$at a price of$s_{1}$per share, said node can insert their own transaction to purchase$\alpha$shares of$X$at that price which will drive up the price of each share to$s_{2}$. The original participant will be forced to buy$X$at this new price, and in their purchase will drive up the asset to a new value of$s_{3}$. As$s_{3}>s_{1}$the node can then sell their shares of$X$at this new price - this is how profit is earned in terms of MEV by the node as defined previously in this article. For the participant that originally submitted the transaction though they are required to pay this profit out to the node as a consequence of being front-ran alongside other participants intending to purchase$X$followings its inflated pricing. If both transactions, the one sent by the node and the one they originally viewed from the participant, are grouped together before execution though then both transactions will pay some aggregated price$s_{i}$per share. If a third transaction, the one where the node sells their shares of$X$to earn profit from MEV, is also grouped together with these transactions then a new aggregated price$s_{j}<s_{i}$will be set. Hence, neither the original participant will be forced to pay as much of an increased fee (if any increased fee at all) nor will the node be capable of selling for additional profit to earn MEV. There are certain events in a blockchain network that closely mimic the effects seen when a stock exchange or any other market is closed. One such common event is the execution of a block and appending of said block to the chain. Without any agreed upon or necessarily reliable tracking of time across blockchain networks, due to both the fact that time in of itself is typically agreed upon by a centralised committee and the fact that there is no such committee on a blockchain generally, these block events serve as integral atomic units. From a more market instead of scientific perspective it can be said that any transactions that are recognised to have occurred between any given two executions of a block (i.e. between any two atomic units of time) are described to have occurred at the same time. To contrast this new statement to how transactions are ordered in blocks currently, recognising all transactions as having occurred at the same moment prevents the current application of recognising all transactions as having occurred in an order since the last event. In the latter, and current, version, transactions looking to purchase and/or sell the same asset can do so at varying prices dependent on the order of transactions within the block. It is this property that allows for front-running to occur and for the price of shares to differ dependent on said transaction order. In the former version though, such extractable value would not exist as all transactions would be merged together (where possible). While for the most part this system ensures that the responsibilities held by participants do not differ to an unsatisfactory extent from what is currently the case, it does once again introduce a new responsibility that must be properly managed. There must exist some algorithm or agreed upon constraints to decide upon an aggregated price for the transfer of any assets as described. It would typically be up to the specifications of some program (codification of this system) or a central entity (unlikely due to going against the ethos of most blockchain networks) to decide upon these mechanisms. Hence, the decision-making would exist outside of the framework set by rational participants of a free market, which while not inherently negative, could lead to further unintended consequences or unforeseen limitations to the functionality of said market. There exist some potential schemes to pass back authority over ordering transactions and ascertaining the values of assets back to market participants in a manner that would enlarge the number of nodes that share this responsibility. ### Transaction Ordering Consensus Instead of assigning the responsibility for both the discovery and selection of transactions to include in a block as well as authority over the ordering of said transactions in the block, these two tasks can be split. It can be visualised that the right to propose a block is an exercise of consensus where multiple nodes must compete for the aforementioned discovery of transactions and to structure the block in the most efficient manner possible. However, a two step process could be illustrated as an alternative wherein nodes must not only compete for being the most efficient at discovering transactions, but also must compete separately for being the most efficient at structuring blocks. Hence, this creates two separate specialisations. Any specialisation of roles allows for satisfactory improvements in the efficiency of a market, and for decreases in the ability of any one participant to control said market. While no specific standard has been crafted yet to guide any future architecture, there are two primary proposals put forth to allow for voting for a transactions based on one of two resources: computational resources to propose valid blocks, or random selection by the network. The former method would involve collating a significant number of block proposals from across the network, where each proposed block would include differing transactions in differing orders. If for instance there are block proposers$A$,$B$, and$C$they may then propose blocks$x$,$y$, and$z$respectively. Block x = new Block(timestamp, nonce, { { index: ++transactionIndex, data: { sender: 0x711e70..., receiver: 'A', amount: 75, token: 'MNOP' } }, { index: ++transactionIndex, data: { sender: 0x613c7e..., receiver: 'B', amount: 75, token: 'MNOP' } }, { index: ++transactionIndex, data: { sender: 'A', receiver: 'C', amount: 75, token: 'MNOP' } } }); Block y = new Block(timestamp, nonce, { { index: ++transactionIndex, data: { sender: 0x613c7e..., receiver: 'B', amount: 75, token: 'MNOP' } }, { index: ++transactionIndex, data: { sender: 0x711e70..., receiver: 'A', amount: 75, token: 'MNOP' } }, { index: ++transactionIndex, data: { sender: 'A', receiver: 'C', amount: 75, token: 'MNOP' } } }); Block z = new Block(timestamp, nonce, { { index: ++transactionIndex, data: { sender: 0x613c7e..., receiver: 'B', amount: 75, token: 'MNOP' } }, { index: ++transactionIndex, data: { sender: 0x711e70..., receiver: 'A', amount: 75, token: 'MNOP' } }, { index: ++transactionIndex, data: { sender: 'A', receiver: 'C', amount: 75, token: 'MNOP' } } }); It can be seen from the above proposed blocks that the node$A$has sought out an MEV opportunity by including their own order to purchase 75 \$MNOP tokens prior to $B$ purchasing 75 \$MNOP tokens themselves, before then inserting another transaction to sell those tokens at the new heightened price. In other words, a textbook front-running opportunity. However, using the currently described form of transaction order consensus it can be seen that nodes$B$and$C$have proposed blocks that differ from$A$’s. As the two blocks$y$and$z$are identical most forms of aggregation across all three blocks would identify the “correct” transaction order to be that of the blocks$y$and$z$, nullifying any front-running opportunity sought by$A$. However, this is not the only possible outcome. It can be seen why$B$proposed$y$as their block, but$C$could have just as easily proposed an identical block to$A$as their situation does not particularly change between the two scenarios. In fact the node$C$who has no change to the price of the assets they purchase regardless of if they propose a block identical to$x$or$y$may offer$A$the opportunity to ‘vote’ for their front-running opportunity as long as$C$gets a percentage of the earnings for themselves. Similarly in the latter proposed method of transaction ordering consensus random committees of participants would be selected for each block to vote on their preferred choice of order in much a similar way as to how the previous architecture encouraged nodes to ‘vote’ through proposing their own order. Primarily the difference comes about in that those who get to vote get to do so by being randomly selected regardless of their access to resources, instead of the votes always being made by the same ‘committee’ each block. Where each committee is made up of nodes including$C$that are unable to discover MEV opportunities efficiently themselves, they would earn the most income by selling their vote as in the former scenario. Both of the proposed architectures may not necessarily remove the unintended incentives that encouraged the refinement of MEV in blockchain networks such as Ethereum. In either sense the ‘problem’ being contended with may simply be pushed along to a new point, rather than solved. In the case of the former proposition it would likely be the case that nodes with the greatest computational resources are able to propose the most blocks of all nodes, meaning that exact block design will likely end up being either the exact aggregated block or similar. For instance if there were twenty proposed blocks including the aforementioned blocks$x,y,z$and$A$has proposed eleven of them, their front-running opportunity would be likely to be included without change. If there were some mechanism to prevent each node from proposing more than one block it would still not necessarily be a perfect design. In fact it might become a slightly varied version of MEVA as mentioned before. In contrast the latter proposition may encourage nodes that are not efficient finders of MEV (as they have been randomly selected to form a committee) to attempt to search for MEV but in a less efficient manner. While less efficient acquisition of MEV would eventually encourage nodes to acquire more resources to either become more efficient or to no longer attempt to discover value to extract, these options are not the only cases. Scenarios wherein MEVA is replicated as discussed previously is one such case. It can be seen that any attempt to construct a solution that does not inherently reshape the incentives involved with MEV will be difficult to implement to a satisfactory degree. Changing the mechanisms for transaction ordering consensus more or less can be seen as the design of a new consensus mechanism to an extent, and MEV is known to be viable across all consensus mechanisms. # Understanding Flashbots Seeking improvements among some of the existing proposed schemes as well as novel schemes to target the incentive frameworks that have initially driven MEV, Flashbots and other public research organisations have been working in tandem with stakeholders in the community. As previously explored, the initial goals, and primary goals, of these organisations have been to reduce the negative effects of MEV extraction. While some reference has been made to these negative effects, especially in the forms of inflationary effects and bloated blocks, no specific definitions have been applied. Below this is achieved and illustrated in detail for the purposes of creating an understanding as to one of the most significant consequences Flashbots has intended to alleviate through an effort to control MEV. ## Priority Gas Auctions (PGA) Most notably among the broader base of participants impacted by MEV on blockchain networks are the 'gas wars' that arise from nodes attempting to search out opportunities for extractable value (especially prevalent when these attempts are inefficiently conducted). As referred to previously, through the market competition occurring on these networks, an inflationary effect on gas prices is witnessed leading to greater congestion with slower and more expensive execution of transactions for participants. These effects are observed as rational nodes will attempt to increase the gas fees they offer to include a transaction in a block up to the value of$x$where$x$is the total value that could be extracted. When more and more nodes are submitting transactions of larger gas costs no rational block proposer will include a transaction that offers a gas fees of significantly less than$x$. To demonstrate the theory in a practical manner evidence of this can be seen in tracking the total gas that has been spent by nodes seeking MEV across both successful and unsuccessful attempts (i.e. transactions that successfully and unsuccessfully targeted an MEV opportunity). Using the MEV-Explore tool created by Flashbots, it can be seen that from the beginning of 2020 till the beginning of 2022 that the amount of gas spent on failed transactions have increased. Earnings from failed transactions represent ‘wasted’ gas, where gas was spent to promote transactions that inevitably were not included in a block on the chain. In the described two year period gas fees spent on these failed transactions cumulatively represented an approximate 4500 blocks that were dedicated to unsuccessful transactions. Inefficient nodes that lack the computational resources to readily target MEV opportunities, and that as such likely represent a large majority of the nodes responsible for the described failed transactions, will only apply further upwards pressure on gas costs in an attempt to reach opportunities otherwise missed. The approach Flashbots and other organisations have taken to address this issue, especially through the development of MEV-geth, has been to help facilitate the arrival of an efficient market in a manner that does not impact upon the blockchain network. In the attempt of achieving this they have established a permissionless side-relay that allow MEV searchers to communicate directly with nodes and other participants beyond the mechanisms typically provided of networks such as Ethereum. Therefore, theoretically, instead of directly competing on the network in searching for viable MEV opportunities across the mempool using the rudimentary measures provided for such competition (i.e. higher gas fees), participants can instead communicate directly with each other off-chain. Rational nodes are willing to pay the most gas possible up to$x$to ensure an extracted value of$x, but rational nodes will also seek out the opportunity to pay as little gas fees as possible. As such, the magnitude of failed transactions that occur and the amount of gas paid for submitting MEV transactions to the blockchain network would decrease. In a certain perspective, this is the implementation of an MEVA that attempts to contend with the same challenges associated with this solution in an alternate manner. ## MEV-geth To understand how MEV-geth works the architecture and layout of the solution, especially in perspective of it being derived from the concept of an MEVA, must be analysed. Primarily, there is an intention to represent certain actions that would otherwise be performed on a blockchain network (in this case Ethereum) to an off-chain environment. As mentioned earlier this is to avoid the Priority Gas Auctions that occur when nodes of varying efficiencies compete for access to MEV opportunities. Below, the actions that are represented off-chain are put forth through the definition of three roles that are identified as discrete responsibilities in a typical MEV-seeking environment: searchers, relayers, and miners. ### Searchers Participants with access to efficient computational resources dedicated to the discovery of transactions and the prospects of extracting value from said transactions, can be said to be searchers. These participants are those that are monitoring the present state of the blockchain and/or the pending transactions from the mempool to be potentially included in future blocks. In doing so they are looking for opportunities where they could submit their own transaction and extract the value they originally prospected. As often referred to throughout the article such opportunities are typically those of arbitrage where it has been detected that one or more DEXs are listing an unequal price for an asset, or those of front-running where a transaction to purchase a asset is included before a similar transaction so that said asset can be sold for a profit at a later time. Typically searchers are the most efficient at their particular responsibility in the life-cycle of MEV. Hence, encouraging the growth of this role would presumably allow for greater reductions in the inflationary effects observed to occur on gas price (i.e. Priority Gas Auctions). When other participants with significantly less efficient resources seek to find MEV opportunities they will often need to pay significantly larger gas fees to ensure that their transactions are included prior to those of searchers. This behaviour both hurts participants on a blockchain network who are required to pay larger costs for executing transactions, and searchers who must pay larger gas fees (cutting into their profit) to continue to extract value. It is in this manner that searchers, who would otherwise be at a significant advantage of extracting value from transactions without the requirement of collaboration off-chain with other participants, are encouraged to partake in an environment such as MEV-geth. However, participating in this environment does come with the additional disincentive of being required to share a portion of their extracted value with the miners that eventually include the transactions submitted by searchers in their proposed blocks (if said block is eventually executed). ### Relayers Once a given searcher has detected an opportunity for value extraction, they will collate a bundle of transactions inclusive of transactions from the mempool and their own submitted transactions (that they have not submitted to the mempool themselves) in a specified order. This bundle is aptly defined a transaction bundle. Searchers will transmit their constructed bundle to the relayer, being the MEV-geth client itself, through a relay network that avoids any transactions being shared across the mempool. Avoidance of the public distribution of transactions is important to avoid other searchers prospecting the MEV-geth network for arbitrage and front-running opportunities to submit to the blockchain themselves first. Responsibility of relayers is to validate transactions in each bundle and then propagate them to the network of miners supporting MEV-geth to be added to a proposed block and eventually executed (as of March 2021, over 58% of Ethereum hash rate supported MEV-geth). In the case of Ethereum or other EVM-Compatible networks these are some of the validation checks relayers must replicate off-chain. While the role of a relayer is not as distinctly clear as a role that currently exists in the current MEV environment on Ethereum, it is appropriately thought of as a division of the labours of miners currently. Often overlooked when analysing the framework of incentives between different participants and their role in extracting value from the chain is the pressures placed on miners. Where miners for the purposes of this section can be envisioned as the nodes responsible for proposing a block and deciding which transactions will be included in said block, they will typically be required to validate all transactions they receive and attempt to yield the greatest value for themselves from block proposal. In MEV-geth however, relayers take over the responsibility for validating all transactions and ordering transaction bundles forwarded to the miners by their prospects to yield maximal gas fees. As such there is a reduced chance of any miner being subjected to a DDoS attack from receiving many ‘pointless’ or invalid transactions at once (either maliciously or unintentionally), and reduced requirements to check if a given block will yield maximal gas fees. Through the appropriate completion of the requirements of this role, relayers are necessary to ensuring that only the most efficient transactions of greatest value to the network are forwarded through to blocks. Theoretically, the number of failed transactions included in any given blocks and by extension the amount of gas to be paid to successfully execute a transaction, will decrease. While relayers do not receive any portion of the fees for completion of this role, the miners who are required to run MEV-geth to access this network and whose clients perform this relayer role do receive a portion of the fees. Hence, this role is incentivised to exist as a necessity for any miners who are incentivised to perform the role of a miner originally. ### Miners In the specified model miners conduct a similar role as they do with regards to a traditional Ethereum block; they receive transactions, verify said transactions and order them in the manner that maximises their profit (though this requirement is relaxed by trust in the relayer), and then propose a block to be appended to the chain and executed. Some of their traditional responsibilities have however been pruned to a degree as referenced above. Searching for transactions, and a magnitude of the responsibility for verifying and ordering said transactions, are instead delegated to searchers and relayers respectively. Therefore miners are encouraged to optimise their computational resources to the task of proposing a block and ensuring its appropriate execution. On top of reduced costs to perform multiple responsibilities, miners also receive a guaranteed cut of the extracted value as profit on top of their typical rewards, incentivising said miners away from attempting to take advantage of MEV opportunities themselves without efficient resources. An alternative form of visualising miners and their purpose in this environment is to denote that the role is to replicate what relayers perform, but on-chain in a slightly varied form. While miners will not need to search out for transactions to add to any proposed blocks, unless they have complete trust in the ability of the relayer they will need to perform validation checks on transactions and make the final decisions on how to order a block themselves. These final decisions are what are inscribed onto the blockchain network, essentially completing the life-cycle of MEV and bringing back all consensus and transactions to the chain. Therefore, the ability to distinctly separate the roles of a relayer and a miner relies on both how much trust the miner has in the relayer, and if the cost of relying on the relayer outweighs the costs of prospecting for MEV individually. ## Adjustments to MEV-geth Design In admission by their own design Flashbots does not perfectly implement an MEV Auction; achieving this would require the properties of both complete privacy and finality. Without meeting these criteria there are possibilities for loopholes in the incentives framework that is intended to be constructed. Where there exists loopholes, there exists incentive misalignments as referred to previously in the MEVA section that could bring about either new forms of attack on the network or encourage new forms of MEV. These terms, and the reasoning behind why they are not implemented to a perfect extent, are detailed upon below. ### Complete Privacy Research into the topic of MEV has identified two forms of privacy in the context of transaction ordering that must exist to satisfy the property of complete privacy: pre-trade privacy, and failed trade privacy. None of these, purposely, are satisfied by Ethereum and most blockchain networks in the typical journey of a transaction. Failed trade privacy involves ensuring that transactions that are unsuccessful in acquiring an MEV opportunity are not included in a block to avoid blocks becoming congested with such transactions. This property is already guaranteed by MEV-geth where no failed transactions will be relayed onto the miner to propose in a block. However, pre-trade privacy is the ability for transactions to remain unknown to all except for the searcher and the relayer before said transactions are executed in a finalised block (one that has already been appended to the chain). Such a property is proposed to avoid other searchers watching the relay network for MEV opportunities to include in their own proposed blocks, and as such circumventing the need to partake in any sharing of fees and undercutting other searchers. In Ethereum this is not the case because of the publicly available mempool required by peer to peer transaction propagation. In contrast MEV-geth, to an extent, allows for the preservation of pre-trade privacy as potential transactions are routed through the private relay network. However, this preservation is to a weakened extent. Privileged participants such as the relayers and miners do have advanced knowledge of transaction bundles prior to the proposal and execution of a block, meaning that these participants have the opportunity to ‘steal’ MEV opportunities for themselves. Complete privacy requires that there are no such privileged participants that are capable of observing transactions prior to their execution on the chain. Currently there are no feasible solutions that have been implemented to achieving complete privacy. Theoretically some form of encryption of a particular nature is believed to be required to satisfy this property. Some examples potentially include SGX (Intel Software Guard Extensions), ZKP (Zero-Knowledge functions), and MPC (Multi-Party Computing). Initial work has been presented on a potential implementation of MEV-SGX, but as alluded to this potential implementation is not currently feasible to a necessary extent. Below is presented a theorised design for MEV-SGX where it is assumed a searcher and a relayer/miner are directly communicating with each other, and an explanation as to where the limitations lie. 1. Prior to sending a transaction bundle, each participant’s client would cryptographically perform a ‘handshake’ to ensure that each participant is: 1. Running in the correct and secure enclave environment (where an enclave environment is a secure computational environment cryptographically separate from other computational environments). 2. That the miner's enclave offers complete privacy to the searchers transaction bundle until any proposed block is appended to the chain. 3. The searcher is instead operating the role of a relayer through their client to validate blocks so that the miner is sure that a block they propose on behalf of the searcher is valid. 2. Searchers would identify an MEV opportunity and construct a block with their transactions ordered to extract said opportunity. 3. The proposed block would then be validated in the client, and once validated it will be encrypted. 4. MEV-SGX relays blocks to be sent to the miner’s enclave in its encrypted form along with an unencrypted block header hash and the expected profitability value of the block. 5. Any given rational miner would then select the block with the highest profitability, and after retrieving the unencrypted block hash it attempts to execute the block so it may be appended to the chain. 6. Once the block has been executed it will be decrypted by the miner’s client in the secure enclave. Illustrated depiction of the MEV-SGX workflow. While this design attempts to ensure complete privacy is satisfied across the whole life-cycle of an MEV opportunity, there remain limitations that either hinder the incentives of using this client or undermine the purpose of it all together. If a miner is able to decrypt the SGX encryption prior to executing a block they may instead be able to claim the MEV opportunity for themselves. Even in the situation that the encryption is infeasible to solve though, the miner will break the property of complete privacy upon execution of a block but prior to appending to the chain (as they must know the decrypted block before being able to add said block to a chain). Therefore this only requires that miners perform the extra effort of taking the MEV opportunity themselves and re-executing the block to undermine the searcher’s efforts and reward. While re-execution of a block might be too costly for a miner, as long as the value that can be extracted exceedsx$where$x$is the cost of re-execution, a rational miner will perform this action. These highlighted points bring forth another significant change in the incentives framework between MEV-geth and MEV-SGX. Where prior it was expected that miners also dedicate resources to the responsibility of the relayers, and this behaviour was incentivised by ensuring miners received a fee and cheaper validation, this role now resides with searchers. Searchers must not only perform the responsibilities of transaction discovery, MEV prospecting, and propagation of said prospects, but they must also propose a block themselves and validate the block. This is the case as otherwise there is no other feasible mechanism available for a miner to ascertain if a block they are received is valid before performing work on it. However, it also means that searchers are more or less performing the entire role of a traditional node except for that of the final execution of a block. Assuming that MEV is of sufficient value, such that the value acquired from it is greater than the cost to operate an efficient node capable of executing blocks, than any rational searcher will instead attempt to take advantage themselves of any MEV they find. This would increasingly become the case the more often it was that a miner would ‘steal’ MEV upon removing the complete privacy of an MEVA. ### Finality Finality in this context can be described as a challenge in regards to the idea that if the potential extractable value from a block becomes too great then nodes will attempt to perform reorganisations to extract said value. Reorganisation of a blockchain is where a node rewrites the history of said blockchain by attempting to replace old blocks with their own blocks. Typically reorganisations require tremendous access to computational resources, and as such bring about great costs. However, individual nodes or syndicates may be incentivised to perform up to$x$blocks of reorganisation in a chain at the cost of$y\$ as long as the MEV on offer was of greater value. If this became commonplace than networks would respond with requiring significantly increased times waiting on a block following execution and appending to the chain before deeming the block to be canonical (and as such transferring services for funds etc.). As such, the usability and security of the network would decrease to points where participants may be unwilling to continue using the described blockchain.

Similar to the privacy issue already discussed, the issue of finality is not easily solved. It has been proposed that a third requirement of complete privacy may be required for any given MEVA, post-block privacy. This property would require that even when a block has been executed and appended to the chain, that no other participants on the network would be able to witness the transactions contained within, and therefore the MEV opportunities within. However, this is unlikely to be possible without further forms of cryptography such as Zero-Knowledge functions. It would require that all participants can verify the validity of a block and its transactions without being able to observe the transactions themselves. Currently there does not exist a feasible Zero-Knowledge function to perform this specific responsibility, but if it does come into existence it would be of a design to allow the miner or relayer to prove they know the contents and validity of the transactions without sharing the transactions.

1. Searchers would identify an MEV opportunity and construct a block with their transactions ordered to extract said opportunity.
2. The proposed block would then be validated in the client, and once validated it will be encrypted.
3. MEV-SGX relays blocks to be sent to the miner in its encrypted form along with an unencrypted block header hash, the expected profitability value of the block, and a Zero-Knowledge proof of the validity and contents of the block.
4. Any given rational miner would then select the block with the highest profitability, and after retrieving the unencrypted block hash it attempts to execute the block so it may be appended to the chain.
5. Once the block has been executed it will NOT be decrypted by the miner’s client (only the searcher can decrypt the block).
6. When the block has been propagated by the miner and eventually appended to the chain, any participants will be able to extract the Zero-Knowledge proof that came with the block and run a verification check to affirm the validity of the block.

Implementing such a solution would bring about an MEVA that holds complete privacy all throughout the MEV life-cycle across all three identified requirements. Therefore, ideally, all participants would be incentivised to as much as possible support the extraction of value in this economically rational manner. While the above design is extremely theoretical, estimations can be made of potential reasons why the underlying incentives framework might not align as intended. Producing Zero-Knowledge proofs and verifying them can be computationally expensive, to an extent sufficient enough to potentially cause latency for any miners attempting to propose a block before other miners do. If it takes too long to perform the described life-cycle, then miners may opt to resort to discovering MEV opportunities themselves. It is possible though that costs associated with generating Zero-Knowledge proofs may decrease in the foreseeable future as research on the topic increases.

# Conclusion

While this entire article has served the purpose of presenting what MEV is, and how research organisations contend with the underlying incentive structures that encourage its occurrence, there are also messages that can be applied to the wider development of blockchain networks. Developing applications in a decentralised system is a novel and recent challenge, but understanding that underneath all the technical complexity exists an intricate layer of interactions between participants that drive their behaviours is significant. Decisions over the advantages or disadvantages of MEV’s continuance is not necessarily one that can be declared as right or wrong, but either way it is necessary to ensure continued rational economic actions to the benefit of any network. In seeking an economic system that is widely available to all participants beyond that brought about by existing stock markets there are always important cryptographic and cryptonomic decisions that must be made.