CGV Research: In-depth Analysis of How the MEV Market Transitions from ‘Zero-Sum Game’ to ‘Separation of Powers’

TL;DR

• MEV, short for Miner Extractable Value (or Maximal Extractable Value), refers to the additional profits miners can obtain by manipulating transactions (adding, removing, reordering). Ways to acquire MEV include DEX arbitrage, liquidation, front-running, back-running, and sandwich attacks.
• The Impact of MEV: Front-running and sandwich trades lead to poor user experience and more significant losses, but DEX arbitrage and lending liquidation can help the DeFi market reach equilibrium faster and maintain market stability.
• Continued Growth of the MEV Market: After Ethereum’s The Merge, only Ethereum, using Flashbots’ block proposer, received over 206,450 ETH in MEV profits (as of early July 2023).
• Flashbots, as a major force in the MEV space, introduced MEV-Geth, enabling miners and searchers to share MEV profits. MEV-Boost distributes MEV among proposers, builders, and searchers while safeguarding transactions from front running. MEV-share aims to allow users, wallets, and DApps to capture generated MEV. MEV-SGX employs SGX-trusted hardware to replace the trusted MEV-Relay role, achieving permissionlessness. SUAVE attempts to address centralization risks posed by MEV, providing transaction sequencing and block construction services to all existing chains as a dedicated chain.
• New Variables in the MEV Market: Chainlink, the largest Oracle platform, aims to mitigate MEV issues through transaction sequencing at the Oracle network level. The emergence of UniswapX effectively resolves the “sandwich attack” problem but introduces new concerns like MEV scrutiny.

MEV Explanation

MEV, short for Miner Extractable Value (or Maximal Extractable Value), refers to the additional profits miners can obtain by manipulating transactions (adding, removing, reordering). In a typical public blockchain, all transactions are initially submitted to the mempool, waiting to be included in a block. Miners/validators, as the entities responsible for block creation in the blockchain ecosystem, have significant power to decide which transactions are included in a block. Initially, miners sort transactions by transaction fees from highest to lowest to determine the order of inclusion. However, it was later discovered that by monitoring transactions in the mempool, miners could add, remove, or reorder transactions in a block to gain extra profits beyond block rewards, giving rise to MEV.

In practical terms, specialized searchers often use complex algorithms to identify profit opportunities. Since these searchers compete openly within the mempool, when they identify MEV opportunities, they increase transaction fees to ensure their transactions are included. Miners and searchers then share the MEV profits.

According to the widely held view within CGV, MEV acquisition strategies vary and include DEX arbitrage, liquidation, front-running, back-running, and sandwich attacks. Fee-sniping attacks can also occur on blockchains using probabilistic finality consensus algorithms (such as Bitcoin and Ethereum 1.0, which use PoW consensus algorithms).

• DEX arbitrage involves exploiting price differences between different DEXes. By utilizing the atomic transaction feature of blockchains, one can buy on a low-price DEX and sell on a high-price DEX, achieving risk-free arbitrage.
  
• Liquidation in lending protocols occurs when the collateralization ratio falls below a predetermined threshold. The protocol allows anyone to liquidate the collateral, immediately repaying the lender. During liquidation, borrowers often pay substantial liquidation fees, part of which becomes MEV opportunity.
  
• Front running involves monitoring profitable transactions and submitting the same transaction with a higher fee to ensure the submission precedes the original transaction, thus gaining profit. Broadly, front running involves inserting a transaction before another to profit.
  
• Back running pertains to AMM-based DEXes with significant slippage in large trades. After a large trade, the market is imbalanced. Backrunning involves adding a transaction after the large trade to buy assets at a price lower than the market equilibrium.
  
• Sandwich trading combines front running and back running. It involves buying at a low price before a large trade and then selling at a high price after the trade raises prices, yielding substantial profit.
  
• Fee Sniping Attack: The recent surge in the BRC-20 market led to Bitcoin network congestion and rising transaction fees, prompting concerns about Fee Sniping attacks. On PoW consensus blockchains, if potential profits are significant, miners can roll back or reorganize recent blocks, reordering or including specific transactions to gain more profit. Note: Ethereum, prior to The Merge, also used PoW consensus but referred to it as “Time Bandit”.

Impact of MEV

MEV has negative and positive effects, damaging users and even the entire blockchain network while fostering greater market equilibrium and efficiency.

1. Positive Aspects
DEX arbitrage and lending liquidation can assist the DeFi market in reaching equilibrium faster and maintaining market stability. Like traditional finance, MEV searchers are prerequisites for an efficient financial market. For this category of MEV, the gains of MEV searchers come from the market itself.

2. Negative Aspects
Front-running and sandwich trades lead to poor user experiences and more significant losses. Competitive MEV searchers bidding on gas can congest the network and elevate gas fees.

A more severe concern for probabilistic finality PoW chains is the potential for fee-sniping attacks. Time-bandit attacks violate the blockchain’s principle of “immutability,” seriously compromising network security and stability. This has raised concerns within the BTC community about the current state resulting from the Ordinals protocol.

For PoS chains, particularly concerning the current ETH2.0, MEV could lead to centralization of validators. Larger staking pools gain higher MEV profits, resulting in more resources to enhance MEV extraction capability, leading to the Matthew effect and eventual validator centralization, thereby decreasing security.

Development History of MEV

Early Beginnings (2010-2017):

In 2015, Bitcoin core developer Peter Todd introduced the “Replace By Fee (RBF)” concept on Twitter, which was the precursor to the front running mentioned earlier. RBF suggested that users could replace an existing transaction by submitting a new transaction with higher transaction fees and at least one identical input.

Building upon RBF, the Bitcoin community gradually explored the concept of fee sniping. Fee sniping involves miners intentionally re-mining one or more previous blocks to gain the fees originally earned by the miner who initially created those blocks. While the likelihood of successfully re-mining previous blocks is small compared to extending the chain with new blocks, this method could be profitable if the fees of earlier blocks are more valuable than the transactions in the miner’s current mempool. Fee sniping was later extended to the EVM model and described as the “Time Bandit” attack in the “Flash Boys 2.0” paper.

Formal Emergence (2018-2019):

MEV arises only when there’s contention in the state or when submitted state transitions are unconfirmed. Bitcoin lacks a shared state and has strictly defined state transitions, limiting MEV on Bitcoin to fee sniping and double-spending attack attempts. In contrast, Ethereum, with Turing-complete smart contracts, offers significantly more MEV opportunities.

In 2016, EtherDelta, Ethereum’s first DEX, introduced a sub-matching order book design, providing wide-ranging MEV opportunities, although they weren’t fully exploited then.

In 2017, the first algorithmic stablecoin on Ethereum, DAI, emerged, introducing the concept of liquidations to DeFi and creating occasional but significant MEV opportunities (Spike MEV). In 2018, Hayden Adams founded Uniswap, Ethereum’s first AMM-based DEX. The AMM mechanism relies on MEV extractors to maintain market efficiency, substantially increasing MEV opportunities.

The Rise of Flashbots (2019-2021):

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

In January 2021, Flashbots Auction (mev-geth and flashbots relay) was officially released. Riding the wave of the DeFi Summer, extracted MEV saw significant growth.

Current State: Diverse MEV Landscape, Flashbots Leading

As the MEV market expands, numerous projects have joined the fray. Flashbots currently supports the Ethereum mainnet, prompting popular Layer1 and Layer2 solutions to study Flashbots and experiment with implementing MEV auctions. Some projects are taking alternative approaches, such as encrypting transaction pools to address the MEV problem comprehensively. Flashbots continues to innovate, following the early 2021 release of Flashbots Alpha, introducing Flashbots Protect, MEV-Boost, MEV-Share, and the upcoming SUAVE phase.

The Size of the MEV Market

In theory, the potential MEV profits from user-submitted transactions could be unlimited. However, determining the exact magnitude of MEV profits is not possible through finite calculations, as the MEV profits that people discover form the lower bound of potential MEV. The realized MEV (REV) is typically used to estimate the potential MEV market situation. This represents the MEV that has been successfully extracted and realized through various strategies.

Statistics of the MEV Market After Ethereum’s “The Merge”, Source: https://explore.flashbots.net/

According to data provided by Flashbots, as of early July 2023, after Ethereum’s “The Merge,” a total of 206,450 ETH in realized MEV (REV) extraction has been achieved. However, this figure only accounts for the MEV profits received by block proposers, and the earnings of searchers have not been factored in.

Wouldn’t it be better without market competition?

Based on the historical experience accumulated throughout human society, the concept of the “invisible hand” is often a better choice in most cases. However, few would deny that market economies aren’t universally applicable and can lead to serious consequences when misused in certain specific domains.

The elevated gas prices caused by front running are rooted in Ethereum’s pricing mechanism. Can gas prices be kept at a fixed level to avoid the searcher’s priority gas auction?

Nevertheless, a clear consequence of doing so would be collusion off-chain, where searchers with MEV opportunities could bribe miners to include their transactions earlier, leading to the emergence of small-scale off-chain markets. This contradicts Ethereum’s open, permissionless ideology.

Of course, we could ensure miners/validators in the network are certified with some form of authority to guarantee they won’t act maliciously, but this introduces a strong assumption of trust and would transform the system into a permissioned chain.

In summary, CGV believes that, while maintaining Ethereum’s existing characteristics, it might be difficult to completely eliminate the MEV problem.

How to Mitigate the Adverse Effects of MEV

Protocol-Level Priority-Based Scheduling (PBS) – Ethereum Community Solution

In PoS, validators take turns proposing blocks, and consensus among validators determines whether the block is written to the chain. In PoW, miners perform the block proposal and consensus tasks, though the essence is the same.

PBS aims to address the centralization of validators caused by the current MEV. In the default MEV process, block generators have two tasks: 1) building the optimal block from available transactions (block building) and 2) proposing the block with proof of work or stake to the network (block proposing). In cases where MEV has not been thoroughly exploited, step 1) often involves sorting transactions by fee size, simply incorporating them into the block. As MEV profits grow, larger pools of miners/validators capture more MEV profits, leading to a Matthew effect and increased centralization. Additionally, the actual block-producing entity in decentralized pools gains the MEV opportunity, excluding other members from profit sharing. This inequality undermines the adoption of decentralized mining pools, further increasing centralization within the consensus network.

Roles involved in MEV may include:

1. Producer: Block generators (Miners, validators)

2. Proposer: Block proposer (Selects blocks constructed by builders with the highest MEV)

3. Builder: Block builder (Determines block content)

4. Searcher: Searches for MEV in transactions

5. User: Submits transactions potentially containing MEV

Currently, many roles are held by the same entity, such as in the standard Ethereum consensus process, where the producer, proposer, and builder are in the same role.

Vitalik’s Early Solutions

In 2021, Vitalik proposed two solutions, each with a distinct focus. It’s important to note that the solutions discussed in this section are Ethereum protocol-level solutions enforced by the protocol rather than private negotiations like in Flashbots’ solutions.

PBS seeks to achieve these five goals:

1. Proposer non-trustworthiness: Builders don’t need to trust Proposers.

2. Builder non-trustworthiness: Proposers don’t need to trust Builders.

3. Weak proposer non-trustworthiness: Proposers don’t require high computational resources or technical difficulty.

4. Unstealability of bundles: Proposers can’t steal profits from the submitted block contents.

5. Simple and secure consensus: Consensus remains secure, ideally without modifying the current block proposal mechanism.

Solution 1

• Builders create bundles and send bundle headers to proposers, including the bundle body hash, payment to proposers, and builder’s signature.
• Proposers select the highest-paying bundle header, sign, and publish a proposal containing that bundle header.
• Upon seeing the signed proposal, builders publish the complete bundle.

Analyzing the five goals:

• Proposers can receive payments from builders but prevent builders from obtaining MEV profits, for instance, by delaying proposal release until late slots, giving builders insufficient time to publish complete bundles, and failing to meet goal 1.
• Submitting bundle headers ensures proposers receive payments from builders, satisfying goal 2.
• Involving basic network communication and signatures, goal 3 is met.
• Proposers can’t exclusively access bundle contents, only headers, meeting goal 4.
• Introducing the new role of builder necessitates modifying forking rules, potentially increasing the complexity of forking selection from 2 to 3, introducing further uncertainty, and failing to meet goal 5.

Solution 2

• Builders create bundles and send bundle headers to proposers, including the bundle body hash, payment to proposers, and builder’s signature.
• Proposers select bundle headers from those seen and create a signed declaration for the selected headers.
• Builders, upon seeing the declaration, publish the corresponding bundle bodies.
• Proposers choose a bundle header from their signed list and publish a proposal containing it.

Analyzing the five goals:

• Only including full bundles in proposals ensures the completion of builder payments to proposers, satisfying goal 1.
• Builders could publish multiple high-paying bundle headers without submitting actual bundle bodies, rendering proposers unable to publish valid bundles, not meeting goal 2.
• Without limiting the number of bundles accepted, excessive bundle bodies received by proposers could lead to high network bandwidth usage, not meeting goal 3.
• Proposers pre-sign declarations, limiting them to proposing a finite list of bundles for the slot, preventing profit theft, and satisfying goal 4.
• Builders don’t directly engage in consensus, and proposers’ behavior remains similar to before, without an increase in forking situations, satisfying goal 5.

Evolving Paths — Two-Slot PBS vs. Single-Slot PBS

The two paths correspond to improvements and refinements of Vitalik’s early proposals, namely Two Slot PBS and Single Slot PBS, which correspond to Solutions 1 and 2.

In the Two Slot PBS approach, a new type of block called the “Intermediate Block” is introduced to store the contents of the winning builder’s block. In Slot n, the proposer will propose a regular Beacon Block containing a commitment to the winning builder’s block contents. Then, in Slot n+1, the winning builder will propose the Intermediate Block, which includes the content of the awarded block. These two blocks are parts of a larger block, splitting into two stages (slots) for completion. The first stage resembles the block header, while the second stage constitutes the actual block body. If no Beacon Block exists, no builder wins the bid, and there will be no subsequent Intermediate Block.

Both of these blocks require attestation voting from the Committee. A single committee votes on the Beacon Block, whereas all remaining committees within the slot vote on the Intermediate Block. Votes for each block (whether Beacon or Intermediate) will appear in the next slot’s block.

If a builder doesn’t see the Beacon Block, it could indicate a delayed release, and the builder won’t publish the Intermediate Block. Furthermore, to prevent potential losses caused by delayed Beacon Block appearances, the proposal employs well-defined Fork Choice Rules to reject such Beacon Blocks that arise after a certain period of time.

Two Slot PBS Scheme Design, Source: https://ethresear.ch/t/two-slot-proposer-builder-separation/10980

Single Slot PBS utilizes a decentralized committee as an intermediary to store the content of blocks. The builder sends the bundle header to the Auction subnet and simultaneously sends the chunk-encrypted bundle body to the committee. The proposer sends a proposal once the committee’s voting surpasses the threshold. Upon receiving the proposal, the committee decrypts and broadcasts the bundled body, enabling the completion of Proof of Block State (PBS) within a single slot.

Single-slot PBS design, Source:https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877

Ethereum’s need for protocol-level Proof of Block State (PBS) goes beyond addressing MEV concerns.

Implementing PBS at the protocol level in Ethereum could shake the foundation of consensus and introduce various new issues. Why is there an insistence on modifying the protocol layer rather than seeking solutions above the protocol? It can be perceived that the Ethereum community’s intentions are not solely focused on immediate gains, as PBS holds significance for Ethereum’s long-term development beyond just alleviating MEV issues.

In the context of PBS, proposers are relieved of transaction ordering, enabling a stateless approach that doesn’t require storing Ethereum’s complete state. They only need to validate the transactions within the blocks packaged by the builder through Merkel proofs. With the emergence of initiatives like Danksharding, the future burden of storage is expected to grow. The statelessness attribute is pivotal, reducing storage demands for proposers and enabling greater decentralization by allowing more individuals to participate.

Ethereum’s proposal of PBS aligns with the spirit of EIP-1559 from earlier years. Miners/validators, acting as arbiters of transaction content within blocks, wield significant privilege. If miners/validators accumulate excessive profits, centralization could intensify, leading to an imbalance of power that affects the security of the entire consensus network. PBS’s objective is to diminish the position of miners/validators, curbing their income and dispersing power among the people.

Furthermore, in the PBS solution facilitated by Flashbots’ MEV-Boost, trust assumptions related to the Relay could result in transaction censorship issues. This severely undermines Ethereum’s vision of censorship resistance and permission-lessness.

Transaction review can account for up to 80%, Source: https://www.mevwatch.info/

Protocol-level Proof of Block State (PBS) in Ethereum eliminates needing a trusted relay and can enforce builder compliance through proposer constraints. This compels the builder to include censored transactions through Proposers’ enforcement or direct inclusion, thereby enhancing Ethereum’s resistance to censorship.

In summary, protocol-level PBS in Ethereum achieves the allocation of interests between builders and proposers, lowering the barrier for proposers to participate. This can potentially elevate Ethereum’s decentralization level while enhancing its resistance to censorship. However, it does not necessarily improve the overall user experience.

Flashbots—Dominant in the MEV Field

Flashbots aims to alleviate MEV issues through a market auction, providing profits to MEV participants.

In Flashbots’ official documentation, it is categorized into 1) Flashbots Auction, 2) Flashbots Data, 3) Flashbots Protect, 4) Flashbots MEV-Boost, and 5) Flashbots MEV-Share. However, in reality, MEV-Boost is a phase within the Flashbots Auction.

We will describe the development of Flashbots chronologically.

The Flashbots Auction comprises 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 introduced MEV-Geth and MEV-Relay. MEV-Geth is a patch on the Go-Ethereum client, comprising just over a hundred lines of code. MEV-Relay is a bundle forwarder responsible for relaying transaction bundles between searchers and miners. Together, MEV-Geth and MEV-Relay established a private transaction pool and a sealed-bid block space auction, transforming MEV from the dark forest into a market-driven economy. Bundles, as a novel transaction type, represent preferences for transaction orders. The Flashbots Auction introduced a new RPC called “eth_sendBundle” to standardize bundle communication. Bundles encompass a series of signed transactions and the conditions under which these transactions are included.

Furthermore, Flashbots provided the Flashbots Protect RPC node, allowing users to avoid Front Running attacks on their transactions in the public transaction pool by simply modifying their wallet’s RPC node. Additionally, since Flashbots Protect submits user transactions through an alternate block inclusion process, reverts do not occur, relieving users of paying for failed transactions (though it introduced an Exclusive Order Flow).

MEV-Geth rapidly gained adoption among over 90% of Ethereum miners and significantly boosted miners’ earnings. However, the simple auction design had several notable shortcomings, including:

• the need to trust miners,
• compatibility only with Geth, lacking diversity, and
• The auction service’s centralized server operation poses a risk of a single point of failure.

Additionally, due to the prevalent competitive relationships among searchers, the vast majority of earnings flowed into the pockets of miners, introducing centralization risks for Ethereum.

Source: https://twitter.com/lvanseters/status/1481988717367767042/photo/4

• MEV-Boost

Following The Merge, Ethereum transitioned to a PoS consensus mechanism, making the centralization issues brought about by MEV more pronounced. To address this, Flashbots devised MEV-Boost. MEV-Boost can be seen as a variant of Single Slot PBS. Unlike protocol-level PBS in Ethereum, this approach serves as an optional middleware service rather than enforcing behavior through the protocol, and it doesn’t modify the consensus process. The relay no longer acts as an intermediary between users/searchers and miners; instead, it functions as an intermediary node between builders and validators. Based on the transaction flow submitted by users/searchers, each role—builder, relay, and validator—selects blocks to be passed downstream according to maximum gains.

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

MEV-Boost employs the commit-reveal mechanism proposed in Single Slot PBS. Only when a validator commits to a block header does the builder reveal the full content of that block. The specific process is illustrated in the diagram below:

Before the proposal, validators must register with MEV-Boost and relays, ensuring that block builders can construct blocks for a designated validator’s proposal.

1. Users/searchers submit transactions to block builders through public/private mempools.
2. Block builders construct an execution payload based on received transactions. Regarding incentive distribution, the builder sets their address as the payload’s coinbase address and the last transaction transfers to the proposer’s address. The block is then sent to the relay.
3. The relay verifies the block’s validity and sends the ExecutionPayloadHeader to MEV-Boost. MEV-Boost selects the highest-profit forwarding from ExecutionPayloadHeaders submitted by different relays and sends it to the Validator.
4. The validator signs the header, calls submitBlindedBlock to send it back to MEV-Boost, and then forwards it to the relay. After verifying the signature, the relay sends the complete payload body to MEV-Boost and delivers it to the consensus. This allows the Validator to use it when proposing a SignedBeaconBlock to the network.

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

Compared to MEV-Geth, MEV-Boost offers greater versatility. It serves as a plugin for Consensus Client, supporting multiple client types while addressing the centralization issues inherent in miners. However, post-PBS, builders gain higher authority. Dominant builders in the market can attain the ability to censor and monopolize transaction order flows. Currently, centralization risks are mitigated mainly through encouraging competition among builders. The trust level in relays is further diminished, though there’s still a potential risk posed by virtual bidding submitted by builders and proposers. Monitoring relays’ honesty allows validators and builders to choose relays to alleviate this concern.

• MEV-Share

MEV-Geth enabled miners and searchers to share MEV earnings, while MEV-Boost distributed MEV among proposers, builders, and searchers, safeguarding user transactions from front running. However, neither of them accounted for user profits. Within the ethos of Web3, where users generate value from their data, it’s important to give back to users themselves. MEV-Share embodies this principle in practice. MEV-Share is dedicated to allowing users, wallets, and DApps to capture the MEV generated from their transactions.

MEV-Share introduces the role of Matchmaker, acting as an intermediary between users, searchers, and builders. It maintains user privacy by restricting the user transaction information exposed to searchers. Simultaneously, it limits searchers to only insert their transactions after user transactions, known as back running, to prevent user losses. Backrunning doesn’t result in user loss; the profits gained through back-running are essentially derived from market imbalances.

Users can connect their wallets to the Flashbots Protect RPC to send transactions to the Matchmaker. Alternatively, they can use the Matchmaker API to send private transactions, specifying the builders they want to submit to.

For searchers, they need to listen to the selective portion of transaction information sent by the Matchmaker through an SSE (Server-Sent Events) Event Stream. SSE is a technology that enables servers to push information to clients without requiring the clients to initiate requests, allowing clients to receive real-time updates on the blockchain state. Searchers select transactions from this stream and insert their own signed transaction afterward to create a bundle.

Searchers can share partial transaction information from the bundle with other Searchers to receive MEV rewards and improve the chances of their bundle being included in a block. Searchers can also specify builders in the “privacy” field of the bundle. Ultimately, the bundle will be sent to builders accepted by users and searchers.

• MEV-SGX: Eliminating Trust Assumptions with SGX Encryption

The exploration and discussion in the market regarding using SGX to mitigate MEV issues were initially initiated by Flashbots. The MEV-SGX scheme was introduced in June 2021 on the Ethereum forum. It aimed to address the trust issue within the MEV-Relay component of the Flashbots Alpha (the initial version of Flashbots MEV-Auction) proposal from early 2021. The goal was to build a fully private and permissionless MEV auction using MEV-SGX. Various solutions were discussed, such as sending only block headers to hide the transaction trie, introducing collateralized block headers, employing time-lock encryption, and creating secure enclaves. The decision was eventually made to use secure enclaves, with Intel’s SGX being the most widely used, to provide complete privacy and permission-lessness.

In the MEV-SGX scheme, SGX serves as a Trusted Execution Environment (TEE), replacing the single-trusted intermediary in MEV-Relay. Both searchers and miners use separate SGXs. The tamper-resistant features of SGX ensure that each party runs specific code within an environment that cannot be tampered with or breached. Searchers’ SGX provides block validity and profitability for miners (Proposers don’t need to trust builders), while Miners’ SGX handles block decryption and broadcasting (Builders don’t need to trust proposers, and proposers cannot illegitimately capture profits from submitted blocks).

It’s worth noting that the term “miner” is used in the context of this proposal since Ethereum was still in its PoW consensus at the time. However, “miners” and “validators” serve the same function in the consensus: package transactions and propose blocks.

With Ethereum’s transition to the PoS consensus through The Merge, MEV-SGX’s role gradually diminished in favor of MEV-Boost and MEV-Share. However, SGX hasn’t been entirely abandoned. Due to the complexity of implementing MEV-SGX, the community opted for the more practical MEV-Boost and MEV-Share, with plans to use SGX to patch and improve the existing solutions.

On December 20, 2022, the Flashbots community announced the successful execution of Geth (Ethereum client’s Go implementation) within SGX, validating the technical feasibility of applying SGX to MEV. On March 3, 2023, the Flashbots community announced the implementation of block builder execution within SGX, taking another step towards transaction privacy and decentralized builders.

Executing block-building algorithms within secure enclaves ensures that participants, apart from the users, cannot access the content of user transactions, thus preserving privacy. Additionally, running verifiable block execution algorithms allows for proving the economic efficiency of blocks without compromising privacy. In the long run, running builders within SGX could offer proposers verifiably valid blocks and genuine bidding, potentially replacing the trusted MEV-Relay role entirely, achieving permission-lessness.

• SUAVE – The Future of MEV

While MEV-Share addresses the distribution of MEV-related benefits, it still fails to eliminate the centralization risk posed by block-building authority. In Flashbots’ current stage, due to 1) Exclusive order flow and 2) Cross-chain MEV, the builder market experiences a positive feedback loop, making it susceptible to centralization risk.

SUAVE (Single Unified Auction for Value Expression) aims to tackle the centralization risk posed by MEV. SUAVE is another attempt at modular blockchains, striving to provide an off-the-shelf memory pool and decentralized block builders for all blockchains. Operating as a dedicated blockchain, SUAVE aims to offer transaction sorting and block-building services to all existing chains.

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

Supporting multiple chains effectively enhances the efficiency of cross-chain MEV extraction. As a blockchain itself, its decentralized nature will address the centralization risk associated with block builders in previous solutions.

SUAVE consists of the following three main components:

1. Universal Preference Environment: “Preferences” can be understood as an improved type of transaction on the bundle, reflecting the user/searcher’s requirements for transaction execution (e.g., transaction parameters, timing, order). It maintains pre-confirmation privacy and irreversibility of the bundle. The “universal” aspect embodies SUAVE’s multi-chain nature, aggregating transactions submitted by users/searchers on all chains onto SUAVE. It provides a universal sorting layer to gather user preferences and enhance MEV extraction efficiency. Moreover, it enables collaboration among block builders from different domains to boost efficiency.
2. Optimal Execution Market: Executors participate in bidding based on user-submitted preferences, offering users the most optimal execution. This market facilitates cross-domain preference expression, aiming to return as much MEV revenue as possible to users.
3. Decentralized Block Building: Within the decentralized blockchain network, block builders construct blocks for various domains based on user preferences and the optimal execution path. While maintaining decentralization, this component provides a validator from each chain with maximized MEV blocks. The premise for this component’s implementation is sharing order flows and bundles among block builders without revealing content.

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

Of course, it must be noted that SUAVE is still in its early stages, with an unclear technical roadmap and somewhat ambiguous solution design. The details are still being developed. This may be challenging, as Flashbots refers to MEV as the Millennium Prize Problem of the crypto world and calls for collaboration to create a decentralized future.

New Variables in the MEV Market

• Chainlink: Fair Sequencing Services (FSS) — Arbitrum’s Chosen MEV Mitigation Solution

As the largest Oracle platform in the market, Chainlink seeks to alleviate the MEV problem at the level of the Oracle network by introducing transaction sequencing. Personally, I believe its inspiration is to prevent the front running of Oracle reports, as manipulating the order of Oracle reports in a block can result in significant MEV due to the substantial impact of these reports on prices.

Fair Sequencing Services (FSS) can be described as follows: Decentralized Oracle Nodes (DONs) provide tools to distribute transaction sequencing and implement strategies specified by dependent contract creators. Ideally, these strategies should be fair (typically First-Come-First-Served based on arrival time) to prevent participants seeking to manipulate transaction sequencing from gaining an advantage. These tools collectively form FSS.

FSS comprises three main components. The first is transaction monitoring.

1. Transaction Monitoring: In FSS, oracle nodes in DONs monitor the memory pool of the MAINCHAIN and allow off-chain transaction submissions through dedicated channels.
2. Transaction Sequencing: Nodes in DONs sequence transactions for dependent contract SCON based on policies defined for the contract.
3. Transaction Publication: After sequencing, nodes in DONs collectively send transactions to the main chain.
4. FSS Diagram source: Chainlinkv2 White Paper
   

The potential benefits of FSS include:

• Fair Sequencing: FSS includes tools that help developers ensure transactions entering a specific contract are sequenced fairly, providing users with ample resources or technical advantages on who cannot gain the upper hand. The usual strategy for fair sequencing is FCFS (First-Come-First-Served).

Specific Contract’s Transaction Sequencing, Source:https://blog.chain.link/chainlink-fair-sequencing-services-enabling-a-provably-fair-defi-ecosystem/

• Reduced or Eliminated Information Leakage: By preventing network participants from exploiting knowledge about upcoming transactions, FSS can mitigate or eliminate front-running attacks based on available information in the network before transaction submission. Preventing attacks leveraging such leaks ensures adversarial transactions dependent on the original pending transactions cannot enter the ledger before the original transactions are submitted.
• Lower Transaction Costs: By removing the need for participants to prioritize speed when submitting transactions to smart contracts, FSS can significantly reduce transaction processing costs.
• Priority Sequencing: FSS can automatically provide special priority sequencing for critical transactions. For instance, to prevent front-running attacks on Oracle reports, FSS can retroactively insert Oracle reports into a sequence of transactions.

Compared to other solutions that mitigate MEV within smart contracts, FSS implemented using DONs achieves lower latency due to its off-chain MEV defense mechanism. The latency would be in the millisecond range instead of the multiple of 12s corresponding to block delay.

• UniswapX: Addressing Sandwich Attacks but Introducing MEV Scrutiny

On July 17, leading decentralized exchange (DEX) Uniswap announced the launch of an open-source protocol called UniswapX. This protocol aggregates liquidity from decentralized trading pools and introduces features to counter MEV attacks.

UniswapX introduces new features during its off-chain order matching process. These features include non-price-sequenced sorting, executing limit orders, and using a local ledger to handle price differences.

Due to these changes, transactions stored in the mempool become increasingly unpredictable, reducing the arbitrage space for MEV. MEV largely arises from miners prioritizing transactions based on gas, but with adjustments made by the off-chain ledger, we can significantly improve MEV.

Uniswap traders are adversely affected by sandwich attacks, resulting in harmful MEV and potential losses of up to $3 million daily. UniswapX aims to address this issue by converting original transactions into “intents” submitted to Uniswap’s central server. While this effectively resolves sandwich attacks, it introduces the new problem of MEV scrutiny.

During quoting and trading, fair prices may lean towards the quotes. In such cases, the sole quoter often prefers to submit transactions on-chain during an exclusive window. However, this presents an opportunity for validators who might collude to scrutinize transactions. Although this type of attack may not be common at this stage, if some validators become powerful enough, consistently win multiple blocks, or the infrastructure for validator collusion becomes widespread, we might witness a malignant growth of MEV scrutiny issues.

In conclusion, while the Ethereum Foundation might hold a generally negative view towards MEV, the current state of the blockchain ecosystem, dominated by centralized miners/validators, makes it difficult to tackle the problem with direct solutions like transaction encryption without causing intense market volatility. Thus, progressive improvement-oriented solutions like those offered by Flashbots and other teams aim to involve multiple parties in MEV extraction, gradually diminishing centralized control. This approach minimizes MEV’s impact on users and ultimately transitions to privacy-focused transaction solutions (as emphasized by Vitalik in “The Three Transitions”).

From this perspective, MEV has evolved from its initial state of a dark forest zero-sum game to a stage of checks and balances. It may gradually move towards comprehensive privacy. Nevertheless, MEV remains a market with sustainable development potential, attracting more participants and novel developments.

References and data materials:

• https://ethereum.org/en/developers/docs/mev/
• https://bitcoinops.org/en/topics/replace-by-fee/
• https://bitcoinops.org/en/topics/fee-sniping/
• https://medium.com/@Prestwich/mev-c417d9a5eb3d
• https://medium.com/@VitalikButerin/i-feel-like-this-post-is-addressing-an-argument-that-isnt-the-actual-argument-that-mev-auction-b3c5e8fc1021
• https://www.paradigm.xyz/2021/02/mev-and-me#mev-is-hard-to-fix
• https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725
• https://thedailyape.notion.site/MEV-8713cb4c2df24f8483a02135d657a221
• The Future of MEV is SUAVE | Flashbots
• https://collective.flashbots.net/t/frp-18-cryptographic-approaches-to-complete-mempool-privacy/1210
• https://explore.flashbots.net/

About Cryptogram Venture (CGV): Cryptogram Venture (CGV) is a compliant and qualified research and investment institution in the crypto industry, headquartered in Japan. With a business focus on “research-driven investment,” they have participated in early-stage investments in multiple well-known projects. CGV plays an important role in projects regulated by the Japanese government, such as the JPYW stablecoin, and collaborates with numerous funds, including Huobi Venture, Rocktree Capital, Cryptomeria Capital, and others.

Disclaimer: The information and materials presented in this article are sourced from public channels, and our company makes no guarantees regarding their accuracy and completeness. Descriptions or forecasts of future situations are forward-looking statements, and any suggestions and opinions provided are for reference only and do not constitute investment advice or implications for any individual. Our company’s strategies could be the same, opposite, or unrelated to the strategies inferred by readers based on this article.