In-depth analysis of how the MEV market transitions from ‘zero-sum game’ to ‘separation of powers

Analyzing the MEV market's shift from 'zero-sum game' to 'separation of powers

Author: Cynic LeoDeng

TL;DR

• 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, rearranging transactions). The ways to obtain MEV include DEX arbitrage, liquidation, front-running, back-running, sandwich attacks, etc.

• Impacts of MEV: Front-running and sandwich trading can result in a poor user experience and more severe losses. However, DEX arbitrage and loan liquidation can help the Defi market reach equilibrium faster and maintain market stability.

  • Ethereum Futures ETF may be approved what will happen to the price?
  • Reviewing the impact of US bond yields on the cryptocurrency market over the past two years a similar autumn market may very likely occur, just like the spring market this year.
  • Survival Skills in the Cryptocurrency Dark Forest Wallet Security Strategies and Risk Hierarchy Management

• Continuous growth of the MEV market: After The Merge on Ethereum, the MEV revenue received by Ethereum using Flashbots’ Block Proposer has exceeded 206,450 ETH (as of early July 2023).

• Flashbots, as one of the dominant forces in the MEV field, allows miners and searchers to share MEV revenue through MEV-Geth. MEV-Boost allocates MEV among proposers, builders, and searchers while protecting users’ transactions from front-running. MEV-share aims to enable users, wallets, and Dapps to capture the MEV generated by their transactions. MEV-SGX utilizes SGX trusted hardware to completely replace the trusted MEV-Relay role and achieve permissionless. SUAVE attempts to address the centralization risk brought by MEV. As a dedicated chain, it provides transaction ordering and block construction services to all existing chains.

• New variables in the MEV market: Chainlink, as the largest oracle platform in the market, attempts to mitigate the MEV problem through transaction ordering at the oracle network level. The emergence of UniswapX effectively solves the problem of “sandwich attacks” but also brings new issues such as MEV inspection.

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, rearranging transactions).

In a general public chain, all transactions need to be submitted to the Mempool first and wait to be included in the block. Miners/validators, as the roles responsible for generating blocks in the blockchain ecosystem, have a high level of power to decide which transactions are included in the block. Initially, miners simply sorted transactions in the order of transaction fees from high to low to determine the order in which transactions are included in the block. Later, it was discovered that miners could add, delete, or change the order of transactions in the Mempool to obtain profits in addition to block rewards, resulting in the emergence of MEV.

In practical applications, there are specialized searchers who use complex algorithms to find profitable opportunities. Since searchers compete with each other in the public Mempool, when a searcher finds an MEV opportunity, they will increase the transaction fees to ensure that their submitted transactions are included, and miners and searchers share the MEV revenue.

CGVFOF According to the general consensus in the industry, 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 PoW consensus algorithms), Fee Sniping attacks may also occur.

• DEX arbitrage. Prices may differ between different DEXs. By taking advantage of the atomic transaction feature of the blockchain, one can buy at a low price on one DEX and sell at a high price on another DEX, achieving risk-free arbitrage.

• Liquidation. When the collateralization ratio in a lending protocol falls below a predetermined level, the protocol usually allows anyone to liquidate the collateral and repay the lender immediately. During liquidation, the borrower usually needs to pay a large amount of liquidation fees, part of which goes to the liquidator, creating MEV opportunities.

• Front-running. This can be understood as a race. When a profitable transaction is detected, one can submit the same transaction with a higher transaction fee, allowing their transaction to be included in the block before the original transaction, thus gaining profits. Of course, front-running does not only refer to resubmitting the same transaction, but broadly refers to inserting a transaction before a certain transaction to gain profits.

• Back-running. For DEXs that use AMM automated market-making mechanisms, large-scale transactions can cause significant slippage. After a large-scale transaction occurs, the market is in an imbalanced state. Back-running refers to adding a transaction after a large-scale transaction to buy assets at a price lower than the market equilibrium price.

• Sandwich attacks. Sandwich attacks combine front-running and back-running. A sandwich attack refers to buying at a low price before a large-scale transaction, and selling at a high price after the price has been driven up by the large-scale transaction to gain high profits.

• Fee Sniping attacks. The recent bullish trend of BRC-20 has caused congestion in the Bitcoin network and a continuous increase in transaction fees, which has made people start to pay attention to the possible occurrence of Fee Sniping attacks. On PoW consensus blockchains, if the potential profits are large enough, miners can roll back or reorganize the recent few blocks to gain more profits by reordering or including certain specific transactions. Note: Before The Merge, Ethereum also adopted PoW consensus, but it was called Time Bandit.

Impact of MEV

MEV can harm users and even the entire blockchain network, but at the same time, it also makes the market more balanced and efficient.

1. Positive aspects

DEX arbitrage and liquidation can help the Defi market reach equilibrium faster and maintain market stability. Like traditional finance, MEV searchers are actually a prerequisite for the existence of efficient financial markets. For this type of MEV, the profits obtained by MEV searchers come from the market.

2. Negative aspects

Front-running and sandwich attacks can result in a poor user experience and more severe losses. Competing MEV searchers will cause network congestion and increase gas fees through gas auctions.

For a PoW chain with probabilistic finality, a more serious concern is the potential for Fee Sniping attacks. Time-Bandit attacks violate the principle of “immutability” of the blockchain and can severely undermine the security and stability of the blockchain network. Therefore, the BTC community has recently expressed concerns about the current situation brought about by the Oridinal protocol.

For PoS chains, especially for the current ETH2.0, MEV can lead to centralization of validators. Larger staking pools will gain higher MEV profits, which will enable them to allocate more resources to improve their MEV extraction capabilities, resulting in a Matthew effect and ultimately leading to centralization of validators and reduced security.

Development of MEV

Early Stages (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 earlier. It pointed out that users can replace an existing transaction by submitting a transaction with at least one identical input but with a higher transaction fee.

Based on RBF, the Bitcoin community gradually evolved its research on Fee Sniping. Fee Sniping refers to the deliberate re-mining of one or more previous blocks by miners to claim the fees originally collected by the miners who created those blocks.

Although the likelihood of successfully re-mining previous blocks is small compared to extending the chain with new blocks, this method may be more profitable if the previous blocks are more valuable in terms of transaction fees than the transactions currently in the miner’s memory pool. Fee Sniping was later extended to the EVM model and described as “Time Bandit” attacks in the paper “Flash Boys 2.0”.

Formal Emergence (2018-2019):

MEV only occurs when there is a dispute over the shared state and when state transitions are submitted but not confirmed. Bitcoin has almost no shared state and strictly defines state transitions, so MEV on Bitcoin is limited to attempts at Fee Sniping and double-spending attacks. On Ethereum, which has Turing completeness and smart contracts, the opportunities for MEV are significantly increased.

In 2016, EtherDelta, the first decentralized exchange (DEX) on Ethereum, was launched. It adopted a sub-matching order book design, which actually provided a wide range of MEV opportunities to the market, but no one fully utilized them at that time.

In 2017, DAI, the first algorithmic stablecoin on Ethereum, appeared, providing the function of liquidation for DeFi. This created large-scale but infrequent MEV opportunities (Spike MEV) in the market. In 2018, Hayden Adams founded Uniswap, the first DEX on Ethereum to use an automated market maker (AMM) mechanism. The AMM mechanism relies on MEV extractors to maintain market efficiency, significantly increasing the opportunities for MEV in the market.

The Emergence of Flashbots (2019-2021):

In April 2019, “Flash Boys 2.0” was published, bringing the study of MEV into the mainstream. At the end of 2019, a group of like-minded digital nomads formed Pirate Ship, later renamed Flashbots, with a robot emoji as their logo.

In January 2021, Flashbots Auction (mev-geth and flashbots relay) was officially launched, and the extracted MEV increased significantly amid the heat of Defi Summer.

Current Situation: Diverse MEV Market with Flashbots Dominating

As the MEV market continues to grow, many projects have joined the open field. Flashbots currently only supports the Ethereum mainnet, so mainstream Alt Layer1 and Layer2 are studying Flashbots and trying to implement MEV auction functionality.

There are also some projects that have chosen a different path and are attempting to completely solve the MEV problem by encrypting the transaction pool. Flashbots itself is also constantly innovating. After the Flashbots Alpha in early 2021, it has successively implemented Flashbots Protect, MEV-Boost, MEV-Share, and the next phase SUAVE is under development.

How big is the MEV market?

In theory, the potential MEV revenue from user-submitted transactions is infinite. However, it is not possible to determine the magnitude of MEV revenue through limited calculations. The MEV revenue that people have discovered constitutes the lower bound of potential MEV. Typically, people estimate the possible MEV market situation through Realized MEV (REV) implementations.

MEV market statistics after Ethereum’s merge Source: https://explore.flashbots.net/

According to data provided by Flashbots, as of early July 2023, a total of 206,450 ETH in REV has been realized after Ethereum’s merge. However, this is only the MEV revenue received by Block Proposers, and Searchers’ revenue has not been included in the calculation.

Wouldn’t it be better without market competition?

Based on the accumulated historical experience of human society, the “invisible hand” is generally 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 can lead to serious consequences.

The problem of increased gas price caused by front running is rooted in Ethereum’s pricing mechanism. Can we keep the gas price at a fixed level to avoid Searcher’s Priority Gas Auction?

However, an obvious result of doing so would be collusion off-chain, where Searchers with MEV opportunities would bribe miners to include their transactions in blocks earlier. This would actually give rise to off-chain small-scale markets that contradict the open and permissionless ideals of Ethereum.

Of course, we can certify miners/validators in the network to ensure that they do not act maliciously, but this introduces a strong trust assumption and turns it into a permissioned chain.

In short, CGV believes that it is difficult to completely eradicate the MEV problem while maintaining the existing features of Ethereum.

How to mitigate the adverse effects of MEV

Protocol-level PBS – The Ethereum Community’s Solution

In PoS, validators take turns to propose blocks as proposers, and consensus among validators is reached to decide whether the block should be written to the chain. In PoW, the work of block proposal and consensus is done by miners, essentially the same.

PBS is mainly designed to solve the problem of centralization of validators caused by current MEV. In the default MEV process, block producers have two tasks: (1) building the best block from all available transactions, and (2) proposing the block with proof of work or stake to the network.

When MEV was not fully exploited, step (1) actually involved sorting transactions in descending order of transaction fees and simply including them in the block. With the increasing profitability of MEV, larger mining pools/validator pools actually obtained a larger share of the MEV profits, resulting in the Matthew effect and further centralization of the consensus network.

In addition, the actual entity that produces the block in a 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, further increasing the degree of centralization in the consensus network.

The roles that may be involved in MEV can be divided into the following:

1. Producer: Block producer (Miners, Validators)

2. Proposer: Block proposer (selects the block constructed by the builder with the highest MEV)

3. Builder: Block builder (responsible for determining the content of the block)

4. Searcher: Searches for MEV in transactions

5. User: Submits transactions that may contain MEV

Of course, at this stage, many roles are actually performed by the same entity. For example, in the normal Ethereum consensus process, the Producer, Proposer, and Builder are the same role.

Vitalik’s early proposals

Vitalik proposed two solutions as early as the beginning of 2021, each with a different focus. It is worth noting that the solutions discussed in this section are at the Ethereum protocol level, where PBS is enforced by the protocol, rather than the private negotiations of solutions like Flashbots.

PBS aims to achieve the following five goals:

1. No need to trust proposer friendliness: Builders do not need to trust proposers.

2. No need to trust builder friendliness: Proposers do not need to trust builders.

3. Weak proposer friendliness: Proposers do not require high computational resources and high technical difficulty.

4. Non-stealability of bundles: Proposers cannot privately steal the profits from the blocks submitted by builders.

5. Simplicity and security of consensus: Consensus remains secure, preferably without modifying the current block proposing mechanism.

Solution 1

• Builders create bundles and send bundle headers to proposers, including the hash of the bundle body, payment to the proposer, and the builder’s signature.

• Proposers select the bundle header with the highest profit, sign and publish a proposal containing that bundle header.

• After seeing the signed proposal, the builder publishes the complete bundle.

Analysis based on the five goals:

• Proposers can collect fees paid by builders but prevent builders from receiving MEV profits. For example, by publishing proposals at the end of a slot, giving builders no time to publish complete bundles, this does not meet goal 1.

• Submitting a bundle header ensures receiving payment from the builder. Proposers do not need to trust builders, meeting goal 2.

• It only involves simple network communication and basic signature operations, meeting goal 3.

• Proposers cannot exclusively access bundle content, only the header, meeting goal 4.

• Since a new role, the builder, is introduced, the forking rules need to be modified, and the potential situations are increased from 2 to 3, increasing the complexity of forking selection and possibly introducing new uncertainties, not meeting goal 5.

Solution 2

• Builders create bundles and send bundle headers to proposers, which include the hash of the bundle body, payment to the proposer, and the builder’s signature

• Proposers select a list of bundle headers from the ones they see and sign a declaration for the list

• Builders publish the corresponding bundle bodies after seeing the declaration

• Proposers select a bundle header from the list they signed and publish a proposal containing it

Analysis based on five objectives:

• Only when the bundle is fully included in the proposal will the builder complete the payment to the proposer, satisfying Objective 1

• Builders can publish multiple high-cost bundle headers without publishing actual bundle bodies, preventing proposers from publishing valid bundles, not meeting Objective 2

• If the number of receivable bundles is not limited, it may cause proposers to receive too many bundle bodies, resulting in high network bandwidth, not meeting Objective 3

• Proposers pre-sign declarations, limiting them to proposing a limited number of bundles in the list, unable to steal profits, satisfying Objective 4

• Builders do not directly participate in the consensus process, and the behavior of proposers remains the same as before without an increase in fork cases, satisfying Objective 5

Two Evolving Paths – Two Slot PBS vs Single Slot PBS

The two paths represent improvements and refinements to Vitalik’s early proposals, with Two Slot PBS and Single Slot PBS corresponding to Solution 1 and Solution 2, respectively.

In Two Slot PBS, a new block type called “Intermediate Block” will be added to store the content of the winning builder’s block. In Slot n, the proposer will propose a regular Beacon Block, which includes a commitment to the content of the winning builder’s block.

Then, in Slot n+1, the winning builder will propose an Intermediate Block, which contains the content of the winning block. These two can be seen as two parts of a large block, divided into two stages (slots) to complete. The first stage is equivalent to the block header, and the second stage is the actual block body. If there is no Beacon Block, it means that no builder has won the bidding, and there will be no subsequent Intermediate Block.

Both of these blocks need to go through Committee’s attestation voting. A Beacon Block is voted on by only one committee, while the Intermediate Block is voted on by all remaining committees in the slot. The voting for each block (whether it’s a Beacon Block or an Intermediate Block) will appear in the next Slot’s Block.

If a builder never sees a Beacon Block, it may mean that the Beacon Block was not published in a timely manner, so the builder will not publish the Intermediate Block. In addition, to avoid loss to the builder due to the delayed appearance of a Beacon Block, the solution defines a well-defined Fork Choice Rule to reject that Beacon Block.

Two Slot PBS solution design source: https://ethresear.ch/t/two-slot-proposer-builder-seLianGuairation/10980

In the Single Slot PBS, decentralized committees act as intermediaries to store the content of blocks. Builders send bundle headers to the Auction subnet and the encrypted bundle bodies to the committee. After the committee’s votes exceed the threshold, the proposer sends the proposal, and the committee decrypts and broadcasts the bundle bodies. This allows PBS to be completed in a single slot.

Single Slot PBS Design Solution source:https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877

Ethereum needs a protocol-level PBS, not just because of MEV

Implementing PBS at the Ethereum protocol level may shake the foundation of consensus and create various new problems. Why must the protocol layer be modified instead of solving it through other solutions above the protocol? It can be considered that the Ethereum community is not focused on the wine, and PBS is of great significance to alleviate the MEV problem and for the long-term development of Ethereum.

In PBS, the proposer does not need to deal with transaction ordering, which achieves statelessness. There is no need to store the complete state of Ethereum, only to verify the validity of transactions in blocks packaged by the Builder based on Merkel Proof. With Danksharding gradually coming into focus, the burden of future storage will become heavier. The statelessness feature is very critical, which reduces the storage requirements for proposers, allows more people to become proposers, and improves decentralization.

The PBS solution proposed by the Ethereum community is actually similar to EIP-1559 back in the day. Miners/validators, as the role of determining the content of transactions in blocks, have extremely high privileges. Once miners/validators profit too much, it will lead to further centralization and excessive power that affects the security of the entire consensus network. What PBS wants to do is to weaken the position of miners/validators, reduce their income, and distribute power to the people.

In addition, in the PBS solution implemented by Flashbots MEV-Boost, there will be transaction censorship issues due to the trust assumption of the Relay, which seriously undermines the vision of Ethereum as resistant to censorship and permissionless.

Transaction censorship can account for up to 80% source: https://www.mevwatch.info/

Ethereum’s protocol-level PBS does not require a trusted Relay. It can force the Builder to include or directly include censored transactions through the constraints of the Proposer, thereby enhancing Ethereum’s resistance to censorship.

Summary: Ethereum’s protocol-level PBS achieves the distribution of interests between builders and proposers, reduces the threshold for proposers, improves Ethereum’s decentralization level, and enhances its resistance to censorship, but it does not improve the user experience.

Flashbots – The Absolute Dominance in the MEV Field

Flashbots attempts to alleviate the MEV problem through market auctions and bring benefits to MEV participants.

In Flashbots’ official documentation, it is classified according to 1) Flashbots Auction 2) Flashbots Data 3) Flashbots Protect 4) Flashbots MEV-Boost 5) Flashbots MEV-Share. However, MEV-Boost is a phase within Flashbots Auction. I will describe the development of Flashbots based on chronological order.

The Flashbots Auction actually consists of two phases: MEV-Geth for ETH1.0 (Before The Merge) and MEV-Boost for 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, consisting of just over a hundred lines of code. MEV-Relay is a bundle relay responsible for forwarding transactions between Searchers and Miners.

MEV-Geth and MEV-Relay provide a private transaction pool and a sealed bid block space auction, transforming MEV from the dark forest into a market economy. Bundles, as a new type of transaction, are used to represent preferences for transaction ordering.

The Flashbots Auction introduces a new RPC called “eth_sendBundle” for standardizing bundle communication. A bundle includes a series of signed transactions and the conditions under which these transactions are included.

Additionally, Flashbots also provide the Flashbots Protect RPC node, which allows users to avoid Front Running attacks on their transactions in public transaction pools by simply modifying the RPC node in their wallets. Furthermore, since Flashbots Protect submits user transactions through a separate block production process, reverts do not occur, and users do not have to pay for failed transactions. (However, this introduces an exclusive order flow EOF.)

MEV-Geth quickly gained over 90% adoption among Ethereum miners and significantly increased miners’ profits. However, the simple auction design has some significant shortcomings, including 1) the need to trust miners, 2) compatibility only with Geth, lacking diversity, and 3) the auction service running on centralized servers, which poses a single point of failure risk. Additionally, due to the general competitive relationship among searchers, the majority of the profits go to the miners, which introduces centralization risks to Ethereum.

source: https://twitter.com/lvanseters/status/1481988717367767042/photo/4 MEV-Boost

After The Merge, when Ethereum transitions to PoS consensus, the centralization issues brought by MEV become more apparent. Flashbots designed MEV-Boost to address this problem.

MEV-Boost can be seen as a variation of Single Slot PBS. Unlike the Ethereum protocol-level PBS, this solution is offered as optional middleware rather than enforced behavior through the protocol, and it does not modify the consensus process.

Relay no longer serves as an intermediary between User/Searcher and Miner, but as an intermediate node between Builder and Validator. Based on the transaction flow submitted by User/Searcher, each role, including Builder, Relay, and Validator, selects the blocks to submit downstream based on maximum profit.

source: https://docs.flashbots.net/flashbots-auction/overview#

MEV-Boost adopts the commit-reveal scheme proposed in Single Slot PBS. Only when a Validator commits to a block header, will the Builder reveal the full content of that block. The specific process is shown in the following diagram:

Before the Proposal, Validators need to register with MEV-Boost and relays to ensure that block builders can construct blocks for a specified validator.

1. Users/searchers submit transactions to block builders via public/private mempool.

2. Block builders construct execution payloads based on the received transactions. In terms of profit distribution, the builder sets their own address as the LianGuaiyload’s coinbase address, and the last block transfers funds to the proposer’s address. The block is sent to the relay.

3. The relay verifies the validity of the block and sends the ExecutionLianGuaiyloadHeader to MEV-Boost. MEV-Boost selects the highest-profit ExecutionLianGuaiyloadHeader from different relays and forwards it to the validator.

4. The validator signs the header and submits it back to MEV-Boost through submitBlindedBlock, which is then forwarded to the relay. After verifying the signature, the relay sends the complete LianGuaiyload body to MEV-Boost and forwards it to the consensus, allowing the validator to use it when proposing SignedBeaconBlock to the network.

source: https://twitter.com/keccak254/status/1656984680003153924

Compared to MEV-Geth, MEV-Boost has greater versatility and can be used as a plugin for Consensus Clients, supporting multiple clients while eliminating the centralization problem of miners.

However, after PBS, the builder gains more power. The dominant builder in the market can obtain the ability to review and monopolize the transaction order flow. Currently, the centralization risk can only be prevented by encouraging competition among builders. The level of trust in the relay is further weakened, but risks can still be posed to the builder and proposer through the submission of virtual bids. Currently, the problem is mitigated by allowing validators and builders to freely choose a relay by monitoring the honesty of the relay.

MEV-Share

MEV-Geth allows miners and searchers to share MEV profits. MEV-Boost distributes MEV among proposers, builders, and searchers, while protecting users’ transactions from front-running.

However, neither considered the users’ profits. In the concept of Web3, the value generated by users’ data creation should be returned to the users themselves. MEV-Share is the practitioner of this concept. MEV-Share aims to enable users, wallets, and Dapps to capture the MEV generated by their transactions.

MEV-Share introduces the role of a matchmaker as an intermediary between users, searchers, and builders, maintaining user privacy by limiting the user transaction information exposed to searchers.

At the same time, searchers are limited to inserting their own transactions only after user transactions, i.e., back-running, to avoid user loss. Back-running does not cause user losses, and the profits obtained through back-running are actually generated by market imbalances.

Users can simply connect their wallets to the Flashbots Protect RPC to send transactions to the matchmaker or send private transactions through the Matchmaker API. Users can specify the builders they want to submit the transactions to in the transactions.

For searchers, they need to listen to the selective transaction information sent by the matchmaker through SSE Event Stream. SSE is a technology that allows the server to push information to the client without the client initiating a request, allowing the client to obtain real-time updates of the blockchain state. Searchers will select transactions from it and insert a self-signed tx afterwards to create a bundle.

Searchers can share partial information of the transactions in the bundle with other searchers to obtain MEV rewards and increase the chance of their bundle being included in a block. Searchers can also specify builders in the privacy field of the bundle. Finally, the bundle will be sent to builders that are mutually recognized by users and searchers.

SGX Encryption – Trusted Hardware Eliminates Trust Assumptions

The exploration and discussion of using SGX to mitigate MEV issues in the market was initially initiated by Flashbots.

The MEV-SGX solution was outlined on the Ethereum forum in June 2021, mainly targeting the trust issues of MEV-Relay in the initial version of Flashbots Alpha (Flashbots MEV-Auction). The goal was to build a completely private and permissionless MEV auction through MEV-SGX.

The article discusses various solutions, including 1. sending only block headers, hiding transaction tries, 2. collateral block headers, 3. time-lock encryption, 4. secure isolation zone, etc. Ultimately, the decision was made to use the secure isolation zone (most widely used is Intel’s SGX) to provide complete privacy and permissionlessness.

In the MEV-SGX solution, SGX serves as a trusted execution environment (TEE), replacing the single trusted intermediary in MEV-Relay. Both the searcher and the miner use separate SGXs, and the tamper-resistant feature of SGX ensures 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 blocks and the profitability of the miners (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 privately steal the profits submitted by builders in the blocks).

It should be noted that when this solution was proposed, Ethereum was still in the PoW consensus, so the term “miner” was used instead of “validator,” but in fact, both have the same function in the consensus, which is to package transactions and propose blocks.

When Ethereum transitions to the 2.0 phase through The Merge and adopts the PoS consensus, the volume of the entire MEV-SGX solution gradually decreases, and MEV-Boost and MEV-Share take its place. However, SGX has not been completely abandoned, but the implementation difficulty of MEV-SGX is high, so the community has chosen the more realistic MEV-Boost and MEV-Share, and SGX will be used to patch the flaws in the current solution in the future.

On December 20, 2022, the Flashbots community announced that it successfully ran Geth (Go implementation of the Ethereum client) in SGX, verifying the technical feasibility of applying SGX to MEV. On March 3, 2023, the Flashbots community announced the implementation of the block builder running in SGX, taking another step towards transaction privacy and decentralized builders.

By executing the block construction algorithm in the secure isolation zone, the content of user transactions cannot be seen by participants other than the user, maintaining privacy. At the same time, by running verifiable block execution algorithms, the economic efficiency of the blocks can be proven without compromising privacy. In the long run, running builders in SGX can provide proposers with verifiably valid blocks and real bidding, potentially completely replacing the trusted role of MEV-Relay and achieving permissionlessness.

SUAVE – The Future of MEV

MEV-Share solves the issue of benefit distribution brought by MEV, but it still cannot eliminate the centralization risk brought by block construction power. In the current stage of Flashbots, due to 1) exclusive order flow 2) cross-chain MEV, the Builder market has a positive flywheel effect, which easily leads to centralization risk.

SUAVE (Single Unified Auction for Value Expression) attempts to solve the centralization risk brought by MEV. SUAVE is another attempt at modular blockchain, aiming to provide a plug-and-play memory pool and decentralized Block Builder for all blockchains as a dedicated blockchain, providing transaction ordering and block construction services to all existing chains.

source: https://writings.flashbots.net/the-future-of-mev-is-suave/

The feature of supporting multiple chains effectively improves the efficiency of extracting cross-chain MEV; as a blockchain, its decentralized nature will solve the centralization risk of Block Builders in previous solutions.

SUAVE consists of the following three main components:

1. Universal Preference Environment: Preference can be understood as an improved type of transaction on the bundle, reflecting the user/searcher’s demand for transaction execution (e.g., transaction parameters, time, order), maintaining the privacy and irreversibility of the bundle before confirmation. Universal reflects the multi-chain feature of SUAVE, consolidating the transactions submitted by users/searchers on all chains to SUAVE, providing a universal ordering layer, which can aggregate user preferences to improve MEV extraction efficiency, and allows collaboration between Block Builders from different domains to improve efficiency.

2. Optimal Execution Market: Executors participate in bidding based on user-submitted preferences, providing users with optimal execution, and can achieve cross-chain preference expression, returning as much MEV revenue as possible to users.

3. Decentralized Block Building: In a decentralized blockchain network, Block Builders construct blocks for various domains based on user preferences and the optimal execution path, maintaining decentralization while maximizing MEV for validators of each chain. The premise of this component is the sharing of order flow and bundle among Block Builders without leaking content.

source: https://writings.flashbots.net/the-future-of-mev-is-suave/

Of course, it must be pointed out that SUAVE is still an early-stage solution, and the technical roadmap is still unclear, and the solution design is also ambiguous, with details still being worked on. This may be a difficult task, and Flashbots refers to MEV as the Millennium Prize Problem of the crypto world, calling for everyone to collaborate and create a decentralized future.

New Variables in the MEV Market

Chainlink: Fair Sequencing Service (FSS) – Arbitrum’s MEV mitigation solution

Chainlink, as the largest oracle platform in the market, attempts to mitigate MEV issues through transaction sequencing at the level of the oracle network. In my opinion, its inspiration should be to prevent front-running of oracle reports. Since oracle reports have a significant impact on prices, manipulating the sequencing of oracle reports in blocks would result in high MEV.

The Fair Sequencing Services (FSS) can be described as follows: Decentralized Oracle Network (DON) provides tools to distribute transaction sequencing and implement strategies specified by the dependent contract creator, ideally a fair strategy (usually FCFS based on arrival time), which does not give advantage to participants who wish to manipulate transaction sequencing. These tools together constitute the FSS.

FSS consists of three components. The first is transaction monitoring.

1. Transaction Monitoring: In FSS, oracle nodes monitor the memory pool of the MAINCHAIN and allow off-chain transaction submissions through dedicated channels.

2. Transaction Sequencing: Nodes in O sort transactions for dependent contracts SCON according to the strategy defined for the contract.

3. Transaction Publishing: After the transactions are sorted, nodes in O collectively send the transactions to the main chain.

4. FSS Diagram source: Chainlinkv2 WhiteLianGuaiper

The potential benefits of FSS include:

• Fair Sequencing: FSS includes tools that help developers ensure that transactions inputted into specific contracts are sorted in a fair manner, where users with abundant resources or technical advantages cannot gain an advantage. The typical fair sequencing strategy is FCFS.

Transaction sequencing for specific contracts source: https://blog.chain.link/chainlink-fair-sequencing-services-enabling-a-provably-fair-defi-ecosystem/

• Reduced or Eliminated Information Leakage: By ensuring that network participants cannot exploit knowledge about upcoming transactions, FSS can mitigate or eliminate front-running attacks based on pre-transaction information available in the network before transaction submission. Preventing attacks that exploit such leakage can ensure that adversarial transactions dependent on the original pending transactions cannot enter the ledger before the original transactions are submitted.

• Reduced Transaction Costs: By eliminating the need for participants to pursue speed when submitting transactions to smart contracts, FSS can greatly reduce the cost of transaction processing.

• Priority Sequencing: FSS can automatically provide special priority sequencing for critical transactions. For example, to prevent front-running attacks on oracle reports, FSS can retroactively insert oracle reports into a series of transactions.

Compared to MEV mitigation solutions in smart contracts, FSS implemented using DON can achieve lower latency due to the execution of its MEV defense mechanism off-chain. The latency will be in the millisecond range rather than multiples of the 12-second block delay.

UniswapX: Solving MEV sandwich attacks but creating MEV scrutiny

On July 17, leading decentralized exchange (DEX) Uniswap tweeted that it will launch a new open-source protocol called UniswapX, which will aggregate liquidity from decentralized trading pools and introduce new features to prevent MEV attacks.

In the process of off-chain order matching, UniswapX introduces some new features. These features include not strictly following price order for sequencing, executing limit orders, and using local ledgers to handle price differences.

Due to these changes, transactions stored in the Mempool have become increasingly difficult to predict, further compressing the arbitrage space of MEV. The existence of MEV is mainly attributed to the mechanical mechanism in which miners prioritize packaging based on the amount of gas. However, through adjustments to the off-chain ledger, we can indeed greatly improve MEV.

Uniswap traders generate a large amount of harmful MEV every day due to “sandwich attacks,” with potential losses of up to $3 million. The design goal of UniswapX is to solve this problem by converting original transactions into intents submitted to the Uniswap central server. This effectively solves the problem of “sandwich attacks” but also introduces new issues related to MEV censorship.

In the process of quoting and trading, the fair price may lean towards the quoters. In such cases, the only quoter is often willing to submit the quote by putting the transaction on the chain during the exclusive window period. However, this also provides an opportunity for validators, who may collude to review the transaction. Although this type of attack does not seem common at this stage, if some validators become powerful enough or consistently win multiple blocks, or if infrastructure for validator collusion is widely applied, we may witness the malignant growth of MEV censorship issues.

CGV FoF believes that although the Ethereum Foundation has a practical or slightly negative attitude towards MEV, it is difficult to solve the problem in one go through measures such as transaction encryption, given the current centralized dominance of mining/validator giants. Otherwise, it will cause severe market fluctuations and be detrimental to the sustainable development of the blockchain ecosystem.

Therefore, the progressive improvement plan proposed by teams like Flashbots introduces multiple parties to participate in MEV, balancing each other, gradually weakening the dominant position of centralization, minimizing the impact of MEV on users, and ultimately migrating to privacy transaction schemes with less friction (as emphasized by Vitalik in “The Three Transitions”).

From this perspective, MEV has gradually transitioned from the original dark forest zero-sum game to a stage of checks and balances with three powers, perhaps slowly moving towards comprehensive privacy. However, regardless, MEV remains a large market with the potential for sustainable development, and it will attract more participants and more interesting new things.

Note: This article is a research report by CGV FoF and does not constitute any investment advice, for reference only.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!