TL;DR
What is MEV: MEV stands for Miner Extractable Value (also known as Maximum Extractable Value), which refers to the additional income that miners can obtain by manipulating transactions (adding, deleting, and rearranging transactions). The ways to obtain MEV can be divided into DEX arbitrage, liquidation, Front-Running, Back-Running, sandwich attacks, etc.
Impact of MEV: Front-Running and sandwich transactions will lead to poor user experience and more serious losses, but at the same time, DEX arbitrage and lending liquidation can help the Defi market reach equilibrium faster and maintain market stability.
How big is the MEV market: After Ethereum The Merge, the MEV revenue received by Ethereum’s Block Proposer using Flashbots alone has exceeded 206,450ETH.
Flashbots: MEV-Geth allows Miner and Searcher to share MEV revenue; MEV-Boost allows MEV to be distributed among Proposer, Builder, and Searcher, while protecting users' transactions from being front-run; MEV-share is committed to enabling users, wallets, and Dapps to capture the MEV generated by their transactions; MEV-SGX uses SGX trusted hardware to completely replace the trusted MEV-Relay role and achieve permissionlessness; SUAVE attempts to solve the centralized risks brought by MEV. As a dedicated chain, it provides transaction sorting and block building services to all existing chains.
Chainlink: As the largest oracle platform on the market, it attempts to alleviate the MEV problem by sorting transactions at the oracle network level.
What is MEV
MEV stands for Miner Extractable Value (also known as Maximal Extractable Value), which refers to the additional income that miners can obtain by manipulating transactions (adding, deleting, and reordering transactions). In general public chains, all transactions must first be submitted to the Mempool memory pool and wait to be included in the block. Miners/validators, as the role responsible for block generation in the blockchain ecosystem, can decide which transactions are included in the block and have high power.
At first, miners only decided the order in which transactions were included in the block by sorting them from high to low according to the transaction fee. Later, people found that by monitoring transactions in the memory pool, miners could add transactions, delete transactions, or change the order of transactions in the block to obtain benefits other than block rewards, and MEV appeared.
In real practice, there are often dedicated searchers who use complex algorithms to find profit opportunities. Since searchers compete with each other in the public Mempool, when searchers find MEV opportunities, they will increase the transaction fee to ensure that their submitted transactions are included, so miners and searchers share the MEV income. Depending on the strategy, the ways to obtain MEV can be divided into DEX arbitrage, liquidation, Front-Running, Back-Running, sandwich attacks, etc. For blockchains that use probabilistic finality consensus algorithms (such as Bitcoin and Ethereum 1.0 that use the PoW consensus algorithm), Fee Sniping attacks may also occur.
DEX arbitrage: The prices of different DEXs may differ. By leveraging the atomic transaction feature of blockchain, you can buy on a low-priced DEX and sell on a high-priced DEX to achieve risk-free arbitrage.
Lending and liquidation: When the collateral ratio of a lending agreement is lower than a pre-set ratio, the agreement usually allows anyone to liquidate the collateral and immediately repay the lender. During liquidation, the borrower usually needs to pay a huge liquidation fee, part of which belongs to the liquidator, which also brings MEV opportunities.
Front Running: It can be understood as running ahead of the competition. When monitoring profitable transactions, submit the same transaction with a higher transaction fee, so that the transaction submitted by oneself can be included in the block before the original transaction, and obtain profits. Of course, Front Running does not only refer to repeatedly submitting the same transaction, but also refers to inserting a transaction before a transaction to obtain profits.
Back Running: For DEXs that use the AMM automatic market making mechanism, large-scale transactions will produce significant slippage. When a large-scale transaction occurs, the market is in an imbalanced state. Back Running refers to adding transactions after a large-scale transaction to buy assets at a price lower than the market equilibrium price.
Sandwich Trading: Sandwich Trading is a combination of Front Running and Back Running. Sandwich Trading means buying at a low price before a large-scale transaction, and selling at a high price to obtain high profits after the large-scale transaction pushes up the price.
Fee Sniping Attack: The recent hot market of BRC-20 has caused the Bitcoin network to be blocked, and transaction fees have continued to rise. People have begun to pay attention to the possible Fee Sniping attack again. On the blockchain network with PoW consensus, if the potential benefits are large enough, miners can roll back or reorganize the last few blocks to obtain more benefits by reordering or including certain specific transactions. Note: Ethereum before The Merge also adopted PoW consensus, but Ethereum called it Time Bandit.
The impact of MEV
MEV harms users and even the entire blockchain network, but it also makes the market more efficient.
1. Benefits
DEX arbitrage and lending liquidation can help the Defi market reach equilibrium faster and maintain market stability. Similar to traditional finance, MEV searchers are actually a prerequisite for the existence of an effective financial market. For this type of MEV, the income obtained by MEV searchers comes from the market.
2. Disadvantages Front-Running and sandwich transactions will lead to poor user experience and more serious losses. Competing MEV searchers will cause network congestion through Gas auctions, raising Gas Fees. For the probabilistic final PoW chain, the more serious is the possible Fee Sniping attack. The Time-Bandit attack violates the "immutability" principle of the blockchain and will seriously undermine the security and stability of the blockchain network. Therefore, the recent BTC community is concerned about the status quo brought about by the Oridinal protocol. For PoS chains, especially for the current ETH2.0, MEV may lead to the centralization of validators. A larger staking pool will obtain higher MEV returns, and then there will be more resources to improve the MEV extraction capacity, leading to the Matthew effect, and ultimately leading to the centralization of validators and reduced security.
MEV harms users and even the entire blockchain network, but it also makes the market more efficient.
1. Benefits DEX arbitrage and lending liquidation can help the Defi market reach equilibrium faster and maintain market stability. Similar to traditional finance, MEV searchers are actually a prerequisite for the existence of an effective financial market. For this type of MEV, the income obtained by MEV searchers comes from the market.
2. Disadvantages Front-Running and sandwich transactions will lead to poor user experience and more serious losses. Competing MEV searchers will cause network congestion through Gas auctions, raising Gas Fees. For the probabilistic final PoW chain, the more serious is the possible Fee Sniping attack. The Time-Bandit attack violates the "immutability" principle of the blockchain and will seriously undermine the security and stability of the blockchain network. Therefore, the recent BTC community is concerned about the status quo brought about by the Oridinal protocol. For PoS chains, especially for the current ETH2.0, MEV may lead to the centralization of validators. A larger staking pool will obtain higher MEV returns, and then there will be more resources to improve the MEV extraction capacity, leading to the Matthew effect, and ultimately leading to the centralization of validators and reduced security.
The development history of MEV
MEV follows complexity.
Early budding (2010-2017)
In 2015, Bitcoin core developer Peter Todd proposed the concept of "Replace By Fee (RBF)" on Twitter, which is the predecessor of the Front Running concept mentioned above. It points out that users can submit at least one transaction with the same input to replace the original transaction by increasing the transaction fee. Based on RBF, the Bitcoin community gradually evolved the research on Fee Sniping. Fee Sniping refers to miners intentionally re-mining one or more previous blocks to obtain the fees of the miners who originally created these blocks. Although the probability of re-mining previous blocks is smaller than extending the chain with new blocks, if the previous blocks are more valuable in terms of transaction fees than the transactions in the miner's current memory pool, then this method may be more profitable. Fee Sniping was later extended to the EVM model and described as a "Time Bandit" attack in the "Flash Boys 2.0" paper.
Officially launched (2018-2019)
MEV will only be generated when there is a state dispute and a submitted but unconfirmed state transfer. Bitcoin has almost no shared state, and state transfer is strictly regulated, so MEV on Bitcoin is limited to Fee Sniping and double-spending attacks. attempt. On Ethereum with Turing-complete smart contracts, the opportunities for MEV increase significantly.
In 2016, Ethereum's first DEX, EtherDelta, was launched. It adopted a sub-matching order book design, which actually provided the market with a wide range of MEV opportunities, but no one took full advantage of it at the time. In 2017, the first algorithmic stablecoin on Ethereum, DAI, appeared, providing Defi with a clearing function, and the market saw large-scale but infrequent MEV opportunities (Spike MEV). In 2018, Hayden Adams founded Uniswap, the first DEX on Ethereum to use the AMM automatic market-making mechanism. The AMM mechanism actually relies on MEV extractors to maintain market efficiency, which greatly increases the MEV opportunities in the market. Flashbots appeared in April 2019, when "Flash Boys 2.0" was published, and the research on MEV entered the mainstream vision. At the end of 2019, a group of like-minded digital nomads formed Pirate Ship, which was later renamed Flashbots and used a robot expression as its logo.
Early flashbots logo ideas
In January 2021, Flashbots Auction (mev-geth and flashbots relay) was officially released. Riding on the popularity of Defi Summer, the amount of MEV extracted increased significantly.
Current situation: MEV is flourishing, but Flashbots stands out
As the MEV market grows, many projects have also joined the ranks of openness. Flashbots currently only supports the Ethereum mainnet, so the current mainstream Alt Layer1 and Layer2 are learning Flashbots and trying to implement the MEV auction function. Some projects have chosen a different path and tried to completely solve the MEV problem by encrypting the transaction pool. Flashbots itself is also constantly innovating. After Flashbots Alpha in early 2021, it has successively implemented Flashbots Protect, MEV-Boost, and MEV-Share. The next stage of SUAVE is also under development. How big is the MEV market? Theoretically, the MEV benefits that may be contained in transactions submitted by users are infinite. However, the size of MEV benefits cannot be determined through limited calculations, and the MEV benefits discovered by people constitute the lower bound of possible MEV. Usually, people estimate the possible MEV market situation through realized MEV (Realized MEV, REV).
According to data provided by Flashbots, after the Ethereum Merge, 206,450 ETH of REV has been extracted. However, this is only the MEV income received by Block Proposer, and the income of Searchers has not yet been calculated.
Would things be better without market competition?
From the historical experience accumulated by human society so far, the "invisible hand" is a better choice in most cases. However, almost no one denies that the market economy is not applicable in certain specific areas, and the abuse of the market will lead to serious consequences. The problem of increased Gas Price caused by Front Running is rooted in Ethereum's price mechanism. Can the Gas Price be maintained at a fixed level to avoid the Searcher's Priority Gas Auction? However, an obvious result of doing so will be collusion off the chain. Searchers with MEV opportunities will bribe miners to get their transactions included in the block earlier, which will breed a small-scale market off the chain, which runs counter to the open and permissionless concept of Ethereum. Of course, we can let the miners/validators in the network pass some kind of authoritative certification to ensure that they will not do evil, but this will introduce a very strong trust assumption and completely turn it into a permissioned chain. In short, it is probably difficult to completely cure the MEV problem while maintaining the existing characteristics of Ethereum.
How to mitigate the adverse effects of MEV
Protocol-level PBS — the Ethereum community’s solution
In PoS, validators take turns to be the proposer of a block, and validators reach a consensus to decide whether the block is written to the chain. In PoW, the work of proposing blocks and reaching consensus is done by miners, which is essentially the same. PBS is mainly to solve the problem of validator centralization brought about by the current MEV. In the default MEV process, the block generator has two tasks: 1) building the best block from all available transactions (block building), and (2) proposing the block to the network together with proof of work or equity (block proposing). When MEV is not fully mined, step 1) is actually to sort the transactions from large to small according to the transaction fee, and simply include the transactions in the block from the front to the back. At present, as MEV profits are gradually increasing, larger mining pools/validator pools actually obtain more MEV profits with their market share, resulting in the Matthew effect, and the consensus network will become more centralized. In addition, the actual block-proposing entity of the decentralized mining pool will have the opportunity to obtain MEV, but other members cannot share the profits. The unfairness of the mechanism will reduce the adoption rate of decentralized mining pools. The degree of centralization of the consensus network will further increase. The roles that may be involved in MEV can be divided into the following categories:
Producer: Block Producers (Miners, Validators)
Proposer: Block selector (selects the block constructed by the Builder with the highest MEV)
Builder: Block builder (responsible for determining the content of the block)
Searcher: Search for MEV in transactions
User: Submit a transaction that may contain MEV. Of course, at this stage, many roles are actually performed by the same entity. For example, in the ordinary Ethereum consensus process, Producer, Proposer and Builder are the same role.
Vitalik's early solutions
As early as the beginning of 2021, Vitalik proposed two solutions, each with different focuses. It is worth noting that the solution discussed in this section is at the Ethereum protocol level, and PBS is enforced by the protocol, rather than private negotiations such as Flashbots. PBS attempts to achieve the following five goals:
Trustless proposer-friendly: builders do not need to trust proposers
Trustless builder-friendly: Proposers do not need to trust builders
Weak proposer friendliness: proposers do not require high computing resources and high technical difficulty
Bundle non-stealing: Proposers cannot steal the profits from the blocks submitted by builders
Simple and secure consensus: To maintain the security of the consensus, it is best not to modify the current block proposal mechanism.
plan 1
Builders create bundles and send bundle headers to the proposer, which contain a hash of the bundle body, payment to the proposer, and the builder’s signature.
The proposer selects the bundle header with the highest benefit, signs and publishes a proposal containing the bundle header.
After seeing the signed proposal, the builder publishes the complete bundle
The analysis was conducted according to five objectives:
Can the proposer collect the fees paid by the builder but prevent the builder from receiving MEV profits, for example by posting the proposal at the end of the slot, so that the builder does not have time to publish the complete bundle? This does not meet goal 1.
Submitting the bundle header ensures that payment is received from the builder. The proposer does not need to trust the builder, which satisfies goal 2.
Only involves simple network communication and basic signature operations, meeting goal 3
The proposer cannot obtain the bundle content exclusively and can only see the header, which satisfies goal 4.
Due to the introduction of a new role builder, the fork rule needs to be modified, and the possible cases are increased from 2 to 3, which increases the complexity of fork selection and may bring new uncertainties, and does not meet goal 5.
Scenario 2
Builders create bundles and send bundle headers to the proposer, which contain a hash of the bundle body, payment to the proposer, and the builder’s signature.
The proposer selects a list from the bundle headers it sees and signs a statement about the list.
After seeing the declaration, builders publish the corresponding bundle body
The proposer selects a bundle header from the list it has signed and publishes a proposal containing it.
The analysis was conducted according to five objectives:
Only when the bundle is fully included in the proposal will the builder complete the payment to the proposer, satisfying goal 1.
The builder can publish multiple expensive bundle headers, but does not publish the actual bundle body, which results in the proposer being unable to publish a valid bundle, thus failing to meet goal 2.
If the number of bundles that can be received is not limited, the proposer may receive too many bundle bodies, resulting in high network bandwidth and failure to meet goal 3.
The proposer signs a statement in advance, which means that it can only propose a limited number of bundles in the list in the slot, and cannot steal profits, meeting goal 4.
The builder does not directly participate in the consensus process, the proposer behaves the same as before, and there is no increase in forks, meeting goal 5
Two Slot PBS vs Single Slot PBS
The two routes are improvements and refinements of Vitalik’s early solution. Two Slot PBS and Single Slot PBS correspond to Solution 1 and Solution 2 respectively.
In the Two Slot PBS, a new block type will be added, called "Intermediate Block", which is used to store the block content of the winning builder. In Slot n, the Proposer will propose an ordinary Beacon Block, which contains a commitment to the block content of the winning builder. Then, in Slot n+1, the winning Builder will propose an Intermediate Block, which contains the winning block content. The two can be regarded as two parts of a large block, but they are completed in two stages (slots). The first stage is equivalent to the block header, and the second stage is the real block body. If there is no Beacon Block, it means that no Builder won the bid, and there will be no subsequent Intermediate Block.
Both blocks need to be voted by the Committee's Attestation. The Beacon Block has only one commitee responsible for voting, while the Intermediate Block will be voted by all remaining commitees in the slot. The vote for each Block (whether it is a Beacon Block or an Intermediate Block) will appear in the Block of the next Slot.
If the builder has not seen the Beacon Block, it may mean that the Beacon Block has not been released in time, so the builder will not release the Intermediate Block. In addition, in order to avoid the loss of the builder caused by the Beacon Block appearing after a period of time, the solution uses a well-defined Fork Choice Rule to make the Beacon Block be rejected.
Two Slot PBS Solution Design
Single Slot PBS uses a decentralized committee as an intermediary to keep the content of the block. The builder sends the bundle header to the Auction subnet and sends the encrypted bundle body to the commitee. After the commitee vote exceeds the threshold, the proposer sends a proposal. After receiving it, the commitee decrypts the bundle body and broadcasts it, so that the PBS can be completed in a single slot.
Single Slot PBS Design
Ethereum needs PBS at the protocol level, not only because of MEV
Implementing PBS at the Ethereum protocol layer may shake the foundation of consensus and generate various new problems. Why must the protocol layer be modified instead of solving it through other solutions above the protocol? It can be said that the Ethereum community is not interested in the issue. In addition to alleviating the MEV problem, PBS is also of great significance to the long-term development of Ethereum.
In PBS, the proposer does not need to deal with transaction sorting, thus achieving statelessness. It does not need to save the complete state of Ethereum, but only needs to verify the validity of transactions in the blocks packaged by the Builder based on Merkel Proof. With Danksharding gradually being put on the agenda, the storage burden will become increasingly heavier in the future. The stateless feature is very critical, which reduces the storage requirements for the Proposer, allowing more people to become proposers and improving the degree of decentralization.
The Ethereum community proposed the PBS solution, which is actually the same as EIP-1559. Miners/validators, as the roles that determine the transaction content in the block, have extremely high privileges. Once miners/validators make too much profit, they will become more centralized and their power will be too great to affect the security of the entire consensus network. What PBS needs to do is to weaken the status of miners/validators, reduce their income, and disperse power to the people.
In addition, in the PBS scheme implemented by Flashbots MEV-Boost, due to the trust assumption of Relay, transaction censorship issues will arise, which is a serious damage to Ethereum's anti-censorship and permissionless vision.
Transaction review can account for up to 80%
PBS at the Ethereum protocol level does not require a trusted relay. It can force the Builder to include censored transactions through the Proposer's constraints on the Builder, or it can directly include censored transactions on its own, thereby improving Ethereum's anti-censorship capabilities.
Summary: Ethereum protocol-level PBS realizes the distribution of benefits between builders and proposers, lowers the threshold for proposers, improves the level of decentralization of Ethereum, and enhances its anti-censorship features, but does not improve the general user experience.
Flashbots - the absolute leader in the MEV field
Flashbots attempts to alleviate the MEV problem through market auctions and bring benefits to MEV participants. In the official documents of Flashbots, they are classified according to 1) Flashbots Auction 2) Flashbots Data 3) Flashbots Protect 4) Flashbots MEV-Boost 5) Flashbots MEV-Share, but in fact, MEV-Boost is a phased solution in Flashbots Auction. I will describe the development of Flashbots in chronological order.
Flashbots Auction actually consists of two stages, namely MEV-Geth of ETH1.0 (Before The Merge) and MEV-Boost of ETH2.0 (After The Merge).
MEV-Geth
In early 2021, Flashbots released MEV-Geth and MEV-Relay. MEV-Geth is a patch on the Go-Ethereum client with only a hundred lines of code; MEV-Relay is a bundle forwarder, responsible for forwarding transaction bundles between Searchers and Miners. MEV-Geth and MEV-Relay provide a private transaction pool and sealed bidding block space auction, allowing MEV to transform from a dark forest to a market economy. Bundle, as a new transaction type, is used to express a preference for transaction order. Flashbots Auction introduces a new RPC called "eth_sendBundle" to standardize bundle communication. The bundle includes a series of signed transactions and the conditions under which these transactions are included.
At the same time, Flashbots also provides Flashbots Protect RPC nodes. Users can simply modify the RPC nodes in their wallets to prevent their transactions from being attacked by Front Running in the public transaction pool. In addition, since Flashbots Protect submits user transactions through another block process, reverts will not occur, and users do not have to pay for failed transactions. (But it brings exclusive order flow EOF)
MEV-Geth quickly gained over 90% adoption by Ethereum miners, greatly increasing the miners' profits. However, the simple auction design has some significant shortcomings, including 1) the need to trust miners 2) only compatible with Geth and lack of diversity 3) the auction service runs on a centralized server, which presents the risk of a single point of failure. In addition, due to the general competition among searchers, most of the revenue goes to the miners, which will bring centralization risks to Ethereum.
MEV-Boost
After The Merge, Ethereum changed to PoS consensus, and the centralization problem brought by MEV became more obvious. Flashbots designed MEV-Boost to deal with this problem. MEV-Boost can be considered a variation of Single Slot PBS. Unlike Ethereum protocol-level PBS, this solution provides services as an optional middleware, rather than through protocol enforcement, and does not modify the consensus process. Relay no longer acts as an intermediary between User/Searcher and Miner, but as an intermediate node between Builder and Validator. According to the transaction flow submitted by User/Searcher, each role of Builder, Relay, and Validator will choose the block to submit to the downstream based on the maximum benefit.
MEV-Boost adopts the commit-reveal scheme proposed in Single Slot PBS. Only when the Validator commits a block header, the Builder will reveal the entire content of the block. The specific process is shown in the figure below: Before Proposal, the Validator needs to register with MEV-Boost and relays to ensure that block builders can construct blocks for a proposal of a specified validator.
Users/searchers submit transactions to block builders through public/private mempool
Block builders construct execution payloads based on received transactions. In terms of profit distribution, the builder sets its own address as the payload’s coinbase address, and the last address of the block is set to transfer money to the proposer’s address.
The relay verifies the validity of the block and sends the ExecutionPayloadHeader to MEV-Boost. MEV-Boost selects the one with the highest profit from the ExecutionPayloadHeaders submitted by different relays and forwards it to the Validator.
Validator signs the header, calls submitBlindedBlock and sends it back to MEV-Boost, which forwards it to the relay. After verifying the signature, the relay sends the complete payload body to MEV-Boost and forwards it to consensus, so that the Validator can use it when proposing SignedBeaconBlock to the network.
Compared with MEV-Geth, MEV-Boost is more versatile and can be used as a plug-in for Consensus Client, supporting multiple clients while eliminating the original Miner centralization problem. However, after PBS, Builders gained higher power, and the dominant Builders in the market can obtain the ability to review and monopolize the transaction order flow. Currently, the only way to prevent centralization risks is to encourage competition among Builders. The trust in Relays is also further weakened, but it may still pose a risk to Builders and Proposers by submitting virtual bids. Currently, this problem is alleviated by monitoring the honesty of Relays and allowing Validators and Builders to freely choose Relays.
MEV-Share
MEV-Geth allows Miners and Searchers to share MEV revenue; MEV-Boost allows MEV to be distributed among Proposers, Builders, and Searchers, while protecting users' transactions from being front-run. However, neither of them takes into account the user's benefits. In the concept of Web3, the value generated by the data created by users should be returned to the users themselves, and MEV-Share is a practitioner of this concept. MEV-share is committed to enabling users, wallets, and Dapps to capture the MEV generated by their transactions.
MEV-Share introduces the role of Matchmaker as an intermediary between User, Searcher, and Builder. It maintains user privacy by limiting the user transaction information exposed to Searcher. At the same time, Searcher is restricted to inserting its own transaction only after the user transaction, that is, Back Running to avoid user loss of interest. Back Running will not cause user loss, and the income obtained through Back Running is actually generated by market imbalance.
Users can simply connect their wallet to the Flashbots Protect RPC to send transactions to the Matchmaker, or they can send private transactions through the Matchmaker API, where they can specify the Builders they want to submit.
For Searcher, it is necessary to listen to the selective partial transaction information sent by Matchmaker through SSE Event Stream. SSE is a technology that enables the server to actively push information to the client without the client initiating a request, allowing the client to obtain real-time updates on the blockchain status. Searcher will select transactions from it and insert a self-signed tx after it to create a bundle.
Searchers can share some of the transaction information in the bundle with other searchers to obtain MEV feedback and increase the chances of their bundles being included in the block. Searchers can also specify Builders in the privacy field in the bundle, and the bundle will eventually be sent to builders recognized by both Users and Searchers.
SGX Cryptography - Trusted Hardware Eliminates Trust Assumptions
The exploration and discussion on the use of SGX to mitigate the MEV problem in the market was initially initiated by Flashbots.
The MEV-SGX solution was systematically expounded on the Ethereum forum in June 2021. It was mainly aimed at the trust issue of MEV-Relay in the Flashbots Alpha (initial version of Flashbots MEV-Auction) solution released in early 2021. It hopes to build a completely private and permissionless MEV auction method through MEV-SGX. The article discussed 1. Send only block headers and hide transaction trie 2. Deposit block header 3. Time lock encryption 4. Secure isolation zone and other solutions. Finally, it was decided to use secure isolation zone (the most widely used is Intel's SGX) to provide complete privacy and permissionlessness.
In the MEV-SGX solution, SGX, as a Trusted Execution Environment (TEE), replaces the single trust intermediary in MEV-Relay. The searcher and miner each use an SGX. The tamper-proof feature of SGX can ensure that the other party runs specific code in an environment that cannot be tampered with or invaded. The searcher's SGX is responsible for ensuring the validity of the block and the profitability of the miner (proposers do not need to trust builders); the miner's SGX is responsible for decrypting and broadcasting the block content (builders do not need to trust proposers, and proposers cannot steal the profits from the blocks submitted by builders privately).
It should be noted that when this plan was proposed, Ethereum was still in the PoW consensus, so the term "miner" was used instead of "validator", but in fact the functions of the two in the consensus are the same, both of which package transactions and propose blocks.
When Ethereum entered the 2.0 phase after The Merge and turned to PoS consensus, the popularity of MEV-SGX as a complete solution gradually decreased, and was replaced by MEV-Boost and MEV-Share. However, SGX was not completely abandoned, but MEV-SGX was difficult to implement, so the community chose the more realistic MEV-Boost and MEV-Share, and will use SGX in the form of patches to improve the defects of the current solution.
On December 20, 2022, the flashbots community announced that Geth (the Go implementation of the Ethereum client) was run in SGX for the first time, verifying the technical feasibility of applying SGX to MEV. On March 3, 2023, the flashbots community announced that the block builder was run in SGX, taking another step towards the privacy of transactions and the decentralization of builders.
Executing the block building algorithm in a secure isolation zone ensures that participants other than the user cannot see the content of the user's transaction, thus maintaining privacy. At the same time, by running a verifiable block execution algorithm, the economic efficiency of the block can be proven without compromising privacy. In the long run, running the builder in SGX can provide the proposer with verifiable and valid blocks and provide real bids, which may completely replace the trusted MEV-Relay role and achieve permissionlessness.
SUAVE - The future of MEV
MEV-Share solves the distribution of benefits brought by MEV, but it still cannot eliminate the centralization risk brought by block building power. At the current stage of Flashbots, due to 1) exclusive order flow and 2) cross-domain MEV, the Builder market has a positive flywheel effect, which is prone to centralization risks.
SUAVE (Single Unified Auction for Value Expression) attempts to solve the centralization risk brought by MEV. SUAVE is another attempt at modular blockchain, trying to provide a plug-and-play memory pool and decentralized Block Builder for all blockchains. As a dedicated blockchain, it provides transaction sorting and block building services to all existing chains.
The feature of supporting multiple chains effectively improves the efficiency of extracting cross-domain MEV; as a blockchain, its decentralized attribute will solve the centralization risk of Block Builder in previous solutions.
SUAVE consists of three main components:
Univeral Preference Environment Preference can be understood as a type of transaction improved on the bundle, reflecting the user/searcher's needs for transaction execution (for example, transaction parameters, time, order), maintaining the pre-confirmation privacy and irrevocable properties of the bundle. Universal reflects the multi-chain characteristics of SUAVE, aggregating transactions submitted by users/searchers on all chains to SUAVE, providing a universal sorting layer, which can aggregate user preferences to improve MEV extraction efficiency, and allow Block Builders between different domains to cooperate to improve efficiency.
Optimal Execution Market: Executors participate in bidding based on the preferences submitted by users, provide users with the best execution, and are able to complete cross-domain preference expressions, returning as much MEV revenue as possible to users.
Decentralized Block Building In a decentralized blockchain network, Block Builder builds blocks for each domain based on user preferences and the optimal execution path, and provides blocks with the maximum MEV to Validators of each chain while maintaining decentralization. The premise for the implementation of this component is that Block Builders share order flows and bundles without leaking content.
Of course, it must be pointed out that SUAVE is still a very early solution, the technical route is still unclear, the solution design is also ambiguous, and the details are still being promoted. This may be a very difficult thing. Flashbots calls MEV the Millennium Prize Problem in the Crypto world, calling on everyone to work together to create a decentralized future.
Chainlink Fair Sorting Service (FSS) — Arbitrum’s MEV Mitigation Solution of Choice
As the largest oracle platform in the market, Chainlink attempts to alleviate the MEV problem by sorting transactions at the oracle network level. I personally think that the inspiration should be to prevent the front running of oracle reports. Since oracle reports have a great impact on prices, manipulating the order of oracle reports in blocks will bring high MEV.
Fair Sequencing Services (FSS) can be simply described as follows: Decentralized Oracle Network (DON) provides tools to decentralize transaction ordering and implements it according to the strategy specified by the creator of the dependent contract, ideally a fair strategy (usually FCFS sorting by arrival time chronological order) that does not give advantages to participants who want to manipulate transaction ordering. These tools together constitute FSS. FSS consists of three components. The first is transaction monitoring.
Transaction monitoring: In FSS, the oracle node monitors the MAINCHAIN memory pool in O and allows off-chain transaction submission to be completed through a dedicated channel.
Transaction ordering: Nodes in O order transactions for the dependent contract SCON according to the policy defined for that contract.
Transaction release: After the transactions are sorted, the nodes in O jointly send the transactions to the main chain.
FSS diagram
Potential benefits of FSS include:
Fair sorting: FSS includes tools to help developers ensure that transactions input to a specific contract are sorted in a fair manner, and users with rich resources or technology cannot gain an advantage. The usual fair sorting strategy is FCFS.
Ordering of transactions for a specific contract
Reduce or eliminate information leakage: By ensuring that network participants cannot exploit knowledge about upcoming transactions, FSS can mitigate or eliminate attacks such as front-ending transactions based on information available in the network before a transaction is submitted. Preventing attacks that exploit such leakage ensures that adversarial transactions that depend on the original pending transaction cannot enter the ledger before the original transaction is submitted.
Reduced transaction costs: By eliminating the need for participants to seek speed when submitting transactions to smart contracts, FSS can greatly reduce the cost of transaction processing.
Prioritization: FSS can automatically provide special prioritization for critical transactions. For example, to prevent pre-transaction attacks on oracle reports, FSS can retroactively insert oracle reports into a series of transactions. Compared with the solution to mitigate MEV in smart contracts, FSS implemented using DON can achieve lower latency because its MEV defense solution is executed off-chain. The latency will be millisecond network latency instead of multiples of 12s block latency.
In my opinion, the Ethereum Foundation actually has a negative attitude towards MEV. However, in the current blockchain ecosystem, the centralized miners/validators have great power, and it is difficult to solve the problem in one step through means such as transaction encryption. Otherwise, it will cause violent market fluctuations, which is not conducive to the sustainable development of the blockchain ecosystem. Therefore, the gradual improvement plan of teams such as Flashbots introduces multiple parties to participate in MEV, checks and balances each other, gradually weakens the centralized voice, minimizes the impact of MEV on users, and eventually migrates to the privacy transaction plan with less friction (as Vitailik emphasized in The Three Transitions). MEV has gradually transitioned from the initial dark forest zero-sum game to the check and balance stage of separation of powers, and may be moving towards comprehensive privacy.