In-depth Analysis of MEV: From Zero-Sum Games to Separation of Powers

Author: Cynic, TechFlow

TL;DR

• What is MEV: MEV stands for Miner Extractable Value (also known as Maximal Extractable Value), which refers to the additional profits that miners can obtain by manipulating transactions (adding, deleting, reordering transactions). The ways to obtain MEV can be categorized into DEX arbitrage, liquidation, Front-Running, Back-Running, sandwich attacks, etc.

• Impact of MEV: Front-Running and sandwich trading can lead to poor user experiences and more severe 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's The Merge, the MEV profits received by the Block Proposer using Flashbots have exceeded 206,450 ETH.

• Flashbots: MEV-Geth allows miners and searchers to share MEV profits; MEV-Boost distributes MEV among proposers, builders, and searchers while protecting user 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, achieving permissionless operation; SUAVE attempts to address the centralization risks brought by MEV. As a dedicated chain, it provides transaction ordering and block building services to all existing chains.

• Chainlink: As the largest oracle platform in the market, it attempts to alleviate the MEV problem through transaction ordering 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 profits that miners can obtain by manipulating transactions (adding, deleting, reordering transactions). In a typical public blockchain, all transactions must first be submitted to the Mempool, waiting to be included in a block. Miners/validators, as the block-producing roles in the blockchain ecosystem, have the power to decide which transactions are included in the block.

Initially, miners sorted transactions based on transaction fees from high to low to determine the order in which transactions were included in blocks. Later, it was discovered that by monitoring transactions in the memory pool, miners could add, delete, or change the order of transactions in the block to obtain profits beyond block rewards, leading to the emergence of MEV.

In practice, there are often dedicated searchers who use complex algorithms to find profit opportunities. Due to the competition among searchers in the public Mempool, when a searcher discovers an MEV opportunity, they will increase the transaction fee to ensure their submitted transaction is included, thus sharing the MEV profits with miners. Depending on the strategy, the ways to obtain MEV can be categorized into DEX arbitrage, liquidation, Front-Running, Back-Running, sandwich attacks, etc. For blockchains using probabilistic finality consensus algorithms (such as Bitcoin and Ethereum 1.0, which use PoW consensus), Fee Sniping attacks may also occur.

1. DEX Arbitrage: Prices may differ between different DEXs, and utilizing the atomic transaction feature of blockchain, one can buy on a low-priced DEX and sell on a high-priced DEX to achieve risk-free arbitrage.

2. Lending Liquidation: When the collateralization ratio of a lending protocol falls below a predetermined level, the protocol usually allows anyone to liquidate the collateral and immediately repay the lender. During liquidation, borrowers typically have to pay hefty liquidation fees, a portion of which goes to the liquidator, creating MEV opportunities.

3. Front Running: This can be understood as "jumping the queue." When a profitable transaction is detected, a searcher submits the same transaction with a higher transaction fee, allowing their transaction to be included in the block before the original transaction, thus obtaining profits. Of course, Front Running does not only refer to resubmitting the same transaction; broadly speaking, it involves inserting a transaction before another transaction to gain profits.

4. Back Running: For DEXs using the AMM automated market-making mechanism, large-scale transactions can create significant slippage. After a large transaction occurs, the market is in an unbalanced state. Back Running refers to adding a transaction after a large transaction to buy assets below the market equilibrium price.

5. Sandwich Trading: Sandwich trading is a combination of Front Running and Back Running. It involves buying at a low price before a large transaction and then selling at a high price after the large transaction raises the price to obtain high profits.

Fee Sniping Attacks: The recent surge in BRC-20 trading has led to congestion in the Bitcoin network, with transaction fees continuously rising, prompting renewed concern over potential Fee Sniping attacks. In PoW consensus blockchain networks, if the potential profits are large enough, miners can roll back or reorganize recent blocks to obtain more profits by reordering or including specific transactions. Note: Before The Merge, Ethereum also used PoW consensus, but it referred to it as Time Bandit.

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 efficient financial markets. For this type of MEV, the profits obtained by MEV searchers come from the market.

2. Drawbacks

Front-Running and sandwich trading can lead to poor user experiences and more severe losses. Competing MEV searchers will cause network congestion through gas bidding, raising gas fees. For probabilistic finality PoW chains, the more severe issue is the potential for Fee Sniping attacks. Time-Bandit attacks violate the principle of "immutability" in blockchain, severely undermining the security and stability of the blockchain network. Therefore, the recent BTC community has expressed concerns about the current situation brought by the Ordinal protocol. For PoS chains, especially for the current ETH2.0, MEV may lead to centralization of validators. Larger staking pools will obtain higher MEV profits, which in turn provides more resources to enhance MEV extraction capabilities, leading to the Matthew effect, ultimately resulting in the centralization of validators and reduced security.

MEV harms users and even the entire blockchain network, but it also makes the market more efficient.

Development History of MEV

MEV follows complexity.

Early Emergence (2010-2017)

In 2015, Bitcoin core developer Peter Todd proposed the concept of "Replace By Fee (RBF)" on Twitter, which is a precursor to the Front Running concept mentioned earlier. He pointed out that users could 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 into 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 those blocks. Although the likelihood of successfully re-mining previous blocks is low compared to extending the chain with new blocks, if the previous blocks are more valuable in terms of transaction fees than the transactions currently in the miner's memory pool, this method may be more profitable. Fee Sniping was later extended to the EVM model and described as "Time Bandit" attacks in the paper "Flash Boys 2.0."

Formal Birth (2018-2019)

MEV only occurs in states where there is contention and unconfirmed state transitions, while Bitcoin has almost no shared state, and state transitions are strictly regulated, so MEV on Bitcoin is limited to attempts at Fee Sniping and double-spending attacks. However, on Ethereum, which has Turing-complete smart contracts, the opportunities for MEV significantly increase.

In 2016, Ethereum's first DEX, EtherDelta, went live, adopting a sub-matching order book design, which provided extensive MEV opportunities for the market, but at that time, no one fully utilized it. In 2017, Ethereum's first algorithmic stablecoin, DAI, emerged, providing liquidation functionality for DeFi, leading to large-scale but infrequent MEV opportunities (Spike MEV). In 2018, Hayden Adams founded Uniswap, the first DEX on Ethereum to use the AMM automated market-making mechanism. The AMM mechanism relies on MEV extractors to maintain market efficiency, significantly increasing MEV opportunities in the market. Flashbots emerged in April 2019 with the publication of "Flash Boys 2.0," bringing MEV research into the mainstream. By the end of 2019, a group of like-minded digital nomads formed Pirate Ship, which later changed its name to Flashbots, using a robot emoji as their logo.

Early Flashbots logo ideas
In January 2021, Flashbots Auction (mev-geth and flashbots relay) was officially launched, and with the heat of DeFi Summer, the extracted MEV significantly increased.

Current Situation: MEV Flourishing, Flashbots Dominating

As the MEV market grows, many projects have also joined the open ranks. Flashbots currently only supports the Ethereum mainnet, so mainstream Alt Layer1 and Layer2 are learning from Flashbots and attempting to implement MEV auction functions. Some projects have chosen different paths, attempting to completely solve the MEV problem through encryption of transaction pools. Flashbots itself is also continuously innovating. After the Flashbots Alpha in early 2021, it successively implemented Flashbots Protect, MEV-Boost, MEV-Share, and the next stage, SUAVE, is also under development. How big is the MEV market? Theoretically, the MEV profits contained in user-submitted transactions can be infinite. However, it is impossible to determine the size of MEV profits through limited calculations. The MEV profits discovered by people constitute a possible lower bound for MEV. Typically, people estimate the potential MEV market situation through realized MEV (Realized MEV, REV).

According to data provided by Flashbots, after Ethereum's The Merge, 206,450 ETH of REV has been extracted. However, this is only the MEV profits received by Block Proposers, and the profits of Searchers have not yet been calculated.

Would it be better without market competition?

From the historical experience accumulated by human society, the "invisible hand" is often the better choice in most cases. However, almost no one denies that market economics is not applicable in certain specific areas, and the abuse of the market can lead to serious consequences. The issue of increased gas prices caused by Front Running is rooted in Ethereum's pricing mechanism. Can gas prices be maintained at a fixed level to avoid the Priority Gas Auction by searchers? However, one obvious result of doing so would be collusion off-chain, where searchers with MEV opportunities would bribe miners to have their transactions included in blocks earlier, which would instead breed small-scale off-chain markets, contrary to Ethereum's open and permissionless philosophy. Of course, we could have miners/validators in the network certified by some authority to ensure they do not act maliciously, but this would introduce a strong trust assumption, completely turning it into a permissioned chain. In short, under the premise of maintaining Ethereum's existing characteristics, it is likely very difficult to completely eradicate the MEV problem.

How to mitigate the adverse effects of MEV

Protocol-Level PBS - A Solution from the Ethereum Community

In PoS, validators take turns serving as block proposers, and consensus is reached among validators 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 designed to address the current centralization problem of validators caused by MEV. In the default MEV process, block producers have two tasks: (1) to build the best block from all available transactions (block building), and (2) to propose that block to the network along with proof of work or stake (block proposing). When MEV has not been fully exploited, step (1) is essentially sorting transactions from high to low based on transaction fees, simply including transactions in the block in order. In the current situation where MEV profits are gradually increasing, larger mining pools/validator pools actually obtain a larger share of MEV profits, leading to the Matthew effect, and the consensus network becomes increasingly centralized. Moreover, the actual block-producing entities of decentralized mining pools will gain MEV opportunities, while other members cannot share the profits. The unfairness of the mechanism will reduce the adoption rate of decentralized mining pools, further increasing the centralization of the consensus network. The roles that may be involved in MEV can be divided into the following:

1. Producer: Block producers (Miners, Validators)

2. Proposer: Block selectors (selecting blocks constructed by the highest MEV Builder)

3. Builder: Block constructors (responsible for determining the contents of the block)

4. Searcher: Searching for MEV contained in transactions

5. User: Submitting transactions that may contain MEV. Of course, at this stage, many roles are actually held by the same entity. For example, in the typical 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 focusing on different aspects. It is worth noting that the proposals discussed in this section are at the Ethereum protocol layer, enforced by the protocol, rather than privately negotiated solutions like Flashbots. PBS aims to achieve the following five goals:

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

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

3. Weak proposer friendliness: Proposers do not need high computational resources or high technical difficulty.

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

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

Proposal 1

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

2. Proposers select the highest-yielding bundle header, sign it, and publish a proposal containing that bundle header.

3. Upon seeing the signed proposal, builders publish the complete bundle.

Analysis based on the five goals:

1. Proposers can collect fees paid by builders but prevent builders from receiving MEV profits, for example, by publishing the proposal at the end of the slot, leaving builders no time to publish the complete bundle, failing to meet goal 1.

2. Submitting the bundle header ensures that the proposer receives payment from the builder, and the proposer does not need to trust the builder, meeting goal 2.

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

4. Proposers cannot exclusively access the bundle content; they can only see the header, meeting goal 4.

5. The introduction of a new role, builder, requires modifications to the fork rules, and the number of possible situations increases from 2 to 3, raising the complexity of fork selection and potentially introducing new uncertainties, failing to meet goal 5.

Proposal 2

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

2. Proposers select from the bundle headers they see to form a list and sign a declaration for that list.

3. Builders publish the corresponding bundle body upon seeing the declaration.

4. Proposers select a bundle header from their signed list and publish a proposal containing it.

Analysis based on the five goals:

1. Only when the bundle is fully included in the proposal will the builder's payment to the proposer be completed, meeting goal 1.

2. Builders can publish multiple high-fee bundle headers but not publish the actual bundle body, preventing the proposer from publishing a valid bundle, failing to meet goal 2.

3. If there are no restrictions on the number of bundles that can be received, it may lead to the proposer receiving too many bundle bodies, resulting in high network bandwidth, failing to meet goal 3.

4. The proposer's prior signing of the declaration means they can only propose a limited number of bundles in that slot, preventing profit theft, meeting goal 4.

5. Builders do not directly participate in the consensus process, and the proposer's behavior remains the same, with no increase in the likelihood of forks, meeting goal 5.

Two Evolving Routes - Two Slot PBS vs Single Slot PBS

The two routes correspond to improvements and refinements of Vitalik's early proposals, with Two Slot PBS and Single Slot PBS corresponding to Proposal 1 and Proposal 2, respectively.

In Two Slot PBS, a new block type called "Intermediate Block" will be added to store the block content of the winning builder. In Slot n, the proposer will propose a regular Beacon Block, which includes a commitment to the winning builder's block content. Then, in Slot n+1, the winning builder will propose the Intermediate Block, which contains the winning block content. These two can be seen as two parts of a large block, completed in two stages (slots). The first stage is equivalent to the block header, while the second stage is the actual block body. If there is no Beacon Block, it means no builder has won the bid, and therefore there will be no subsequent Intermediate Block.

Both blocks need to be attested by the Committee. The Beacon Block has only one committee responsible for voting, while the Intermediate Block will be voted on by all remaining committees in the slot. Voting on each block (whether Beacon Block or Intermediate Block) will appear in the next Slot's Block.

If a builder does not see the Beacon Block for a while, it may mean that the Beacon Block was not published in time, so the builder will not publish the Intermediate Block. Additionally, to avoid losses for builders caused by the Beacon Block appearing after a period, the proposal defines a well-defined Fork Choice Rule to reject that Beacon Block.

Design of the Two Slot PBS proposal
Single Slot PBS uses a decentralized committee as an intermediary to safeguard the content of the block. Builders send bundle headers to the Auction subnet while sending the encrypted bundle body to the committee. Once the committee votes exceed a threshold, the proposer sends the proposal, and upon receiving it, the committee decrypts the bundle body and broadcasts it, completing PBS block production in a single slot.

Design of the Single Slot PBS proposal

Ethereum Needs 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 argued that the Ethereum community's intention is not solely focused on MEV; PBS, in addition to alleviating the MEV problem, has significant implications for the long-term development of Ethereum.

In PBS, proposers do not need to handle transaction ordering, thus achieving statelessness. They do not need to maintain the complete state of Ethereum, only needing to verify the validity of transactions in the blocks packaged by builders based on Merkel Proof. As Danksharding gradually comes to the agenda, the storage burden will increase. The stateless feature is crucial, as it reduces the storage requirements for proposers, allowing more people to become proposers and enhancing decentralization.

The PBS proposal from the Ethereum community is actually reminiscent of EIP-1559 from years ago. Miners/validators, as the roles that determine the contents of transactions in blocks, hold significant privileges. If miners/validators profit excessively, it will lead to increased centralization, with too much power potentially affecting the security of the entire consensus network. What PBS aims to do is to weaken the position of miners/validators, reduce their income, and distribute power among the people.

Moreover, in the PBS scheme realized by Flashbots MEV-Boost, due to the trust assumptions of the relay, transaction censorship issues arise, which severely undermine Ethereum's vision of being censorship-resistant and permissionless.

Transaction censorship can account for up to 80%
Ethereum's protocol-level PBS does not require a trusted relay and can force builders to include or directly include censored transactions through the constraints of proposers, enhancing Ethereum's censorship resistance.

In summary: Ethereum's protocol-level PBS realizes the distribution of interests between builders and proposers, lowers the threshold for proposers, enhances Ethereum's decentralization level, and improves censorship resistance, but does not enhance the user experience.

Flashbots - The Absolute Dominance in the MEV Field

Flashbots attempts to alleviate the MEV problem through market auctions, bringing 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 5) Flashbots MEV-Share. However, in reality, MEV-Boost is a stage of the Flashbots Auction, and I will narrate the development of Flashbots in chronological order.

Flashbots Auction actually consists of two stages: MEV-Geth before ETH1.0 (Before The Merge) and MEV-Boost after 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 only a few hundred lines of code; MEV-Relay is a bundle forwarder responsible for relaying transaction bundles between searchers and miners. MEV-Geth and MEV-Relay provide a private transaction pool and sealed bidding block space auction, transforming MEV from a dark forest into a market economy. Bundles, as a new type of transaction, represent preferences for transaction ordering. Flashbots Auction introduced a new RPC called "eth_sendBundle" to standardize bundle communication. A 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, allowing users to avoid their transactions from being subjected to Front Running attacks in the public transaction pool by simply modifying the RPC node in their wallets. Additionally, since Flashbots Protect submits user transactions through a different block production process, there are no reverts, and users do not have to pay for failed transactions (but it brings exclusive order flow EOF).

MEV-Geth quickly gained adoption by over 90% of 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 3) auction services running on centralized servers, posing a single point of failure risk. Moreover, due to the competitive relationship among searchers, the vast majority of profits went to miners, which poses a centralization risk for Ethereum.

MEV-Boost

After The Merge, Ethereum transitioned to PoS consensus, and the centralization issues brought by MEV became more apparent. Flashbots designed MEV-Boost to address this issue. MEV-Boost can be seen as a variant of Single Slot PBS. Unlike the protocol-level PBS, this scheme serves as optional middleware rather than enforcing behavior through the protocol, and it does not modify the consensus process. The relay no longer acts as an intermediary between users/searchers and miners but serves as an intermediary between builders and validators. Based on the transaction flow submitted by users/searchers, each role (builder, relay, validator) will choose to submit blocks downstream based on maximum profit.

MEV-Boost adopts the commit-reveal scheme proposed in Single Slot PBS, where the builder only reveals the full content of the block after the validator commits to a block header. The specific process is as follows: Before the proposal, the validator must register with MEV-Boost and relays to ensure that block builders can construct blocks for a specified validator's proposal.

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

2. Block builders construct execution payloads based on the received transactions. In terms of profit distribution, builders set their addresses as the payload's coinbase address, with the last one set to transfer to the proposer's address. The block is sent to the relay.

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

4. The validator signs the header, calls submitBlindedBlock, and sends it back to MEV-Boost, which forwards it to the relay. The relay verifies the signature and sends the complete payload body to MEV-Boost and forwards it to consensus for the validator to use when proposing the SignedBeaconBlock to the network.

Compared to MEV-Geth, MEV-Boost has greater versatility, serving as a plugin for Consensus Clients and supporting multiple clients while eliminating the centralization issues of miners. However, after PBS, builders have gained more power, and dominant builders in the market can obtain the ability to censor and monopolize transaction ordering flows. Currently, the only way to mitigate centralization risks is to encourage competition among builders. The trust level of the relay has also further weakened, but it may still pose risks to builders and proposers through virtual bidding submissions. Currently, monitoring the honesty of relays allows validators and builders to freely choose relays to alleviate this issue.

MEV-Share

MEV-Geth allowed miners and searchers to share MEV profits; MEV-Boost distributed MEV among proposers, builders, and searchers while protecting user transactions from Front Running. However, neither considered the profits of users. In the Web3 philosophy, the value created by users generating data should be returned to the users themselves, and MEV-Share is the practitioner of this philosophy. MEV-Share aims to enable users, wallets, and Dapps to capture the MEV generated by their transactions.

MEV-Share introduces the role of Matchmaker, serving as an intermediary between users, searchers, and builders, maintaining user privacy by limiting the exposure of user transaction information to searchers. At the same time, it restricts searchers to only inserting their transactions after user transactions, i.e., Back Running, to avoid harming user interests. Back Running does not cause user losses; the profits obtained through Back Running are actually generated from market imbalances.

Users can simply connect their wallets to Flashbots Protect RPC to send transactions to the Matchmaker or send private transactions through the Matchmaker API, specifying the builders they wish to submit transactions to.

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 actively push information to the client without the client initiating a request, enabling the client to receive real-time updates on blockchain status. Searchers will select transactions from this and insert a self-signed tx afterward to create a bundle.

Searchers can share partial information about transactions in the bundle with other searchers to obtain MEV rewards and increase the chances of their bundles being included in blocks. Searchers can also specify builders in the privacy field of the bundle, and the final bundle will be sent to builders mutually recognized by users and searchers.

SGX Encryption - Trusted Hardware Eliminating Trust Assumptions

There has been exploration and discussion in the market regarding the use of SGX to mitigate the MEV problem, initially initiated by Flashbots.

The MEV-SGX proposal was systematically articulated in June 2021 in the Ethereum forum, mainly addressing the trust issues of MEV-Relay in the Flashbots Alpha (the initial version of Flashbots MEV-Auction) released in early 2021. It aimed to construct a completely private and permissionless MEV auction method through MEV-SGX. The discussion included 1. Sending only block headers, hiding transaction tries 2. Guaranteeing block headers 3. Time-lock encryption 4. Secure enclaves, etc. Ultimately, it was decided to use secure enclaves (most commonly Intel's SGX) to provide complete privacy and permissionlessness.

In the MEV-SGX proposal, SGX serves as a Trusted Execution Environment (TEE), replacing the single trusted intermediary in MEV-Relay. Both searchers and miners use an SGX, and the tamper-proof characteristics of SGX ensure that both parties run specific code in an environment that cannot be tampered with or intruded upon. The searcher's SGX is responsible for ensuring the validity of the block and the profitability for 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 profits from the blocks submitted by builders).

It is important to note that when this proposal was made, Ethereum was still in PoW consensus, so the term "miner" was used instead of "validator." However, in reality, both serve the same function in consensus, which is to package transactions and propose blocks.

As Ethereum transitioned to PoS consensus after The Merge, the prominence of MEV-SGX as a complete solution gradually diminished, replaced by MEV-Boost and MEV-Share. However, SGX has not been completely abandoned; rather, the implementation difficulty of MEV-SGX is high, so the community chose the more practical MEV-Boost and MEV-Share, with plans to use SGX in a patching manner to improve the current solution's shortcomings.

On December 20, 2022, the Flashbots community announced that it had successfully run Geth (the Go implementation of the Ethereum client) in SGX for the first time, validating the technical feasibility of applying SGX to MEV. On March 3, 2023, the Flashbots community announced the implementation of block builder operation in SGX, taking a step toward transaction privacy and builder decentralization.

Executing block building algorithms in secure enclaves ensures that participants other than users cannot see the content of user transactions, maintaining privacy. At the same time, by running verifiable block execution algorithms, it can prove the economic efficiency of blocks without compromising privacy. In the long run, running builders in SGX can provide proposers with verifiably valid blocks and real bids, potentially completely replacing the trusted MEV-Relay role and achieving permissionlessness.

SUAVE - The Future of MEV

MEV-Share addresses the distribution of benefits brought by MEV but still cannot eliminate the centralization risks associated with block building power. In the current stage of Flashbots, due to 1) exclusive order flow 2) cross-domain MEV, the builder market has a positive flywheel effect, making it prone to centralization risks.

SUAVE (Single Unified Auction for Value Expression) attempts to address the centralization risks 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, serving as a dedicated blockchain that offers transaction ordering and block building services to all existing chains.

The multi-chain feature effectively enhances the extraction efficiency of cross-domain MEV; as a blockchain, its decentralized nature will resolve the centralization risks of Block Builders in previous solutions.

SUAVE consists of the following three main components:

1. Universal Preference Environment: Preferences can be understood as a type of transaction that improves bundles, reflecting the execution needs of users/searchers (e.g., transaction parameters, timing, order), maintaining the pre-confirmation privacy and non-revocation properties of bundles. "Universal" reflects SUAVE's multi-chain characteristics, aggregating transactions submitted by users/searchers across all chains to SUAVE, providing a universal ordering layer that can gather user preferences to enhance MEV extraction efficiency and allow collaboration between Block Builders across different domains to improve efficiency.

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

3. Decentralized Block Building: In a decentralized blockchain network, Block Builders construct blocks for each domain based on user preferences and optimal execution paths, maximizing MEV for validators of each chain while maintaining decentralization. The implementation of this component relies on Block Builders sharing order flow and bundles without revealing content.

Of course, it must be pointed out that SUAVE is still an early-stage proposal, with an unclear technical route and ambiguous design, and details are still being advanced. This may be a challenging task, as Flashbots refers to MEV as the Millennium Prize Problem in the crypto world, calling for collective cooperation to create a decentralized future.

Chainlink Fair Sequencing Service (FSS) - The MEV Mitigation Solution Chosen by Arbitrum

As the largest oracle platform in the market, Chainlink attempts to alleviate the MEV problem through transaction ordering at the oracle network level. Personally, I believe its inspiration should be to prevent Front Running of oracle reports, as oracle reports significantly impact prices, so manipulating the order of oracle reports in blocks can yield 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 based on strategies specified by the dependent contract creators, ideally a fair strategy (usually FCFS sorted by arrival time), which does not give an advantage to participants hoping to manipulate transaction ordering. These tools collectively form FSS. FSS includes 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 Ordering: Nodes in O sort transactions for the dependent contract SCON based on the strategy defined for that contract.

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

FSS Diagram
The potential benefits of FSS include:

• Fair Ordering: FSS includes tools to help developers ensure that transactions input to specific contracts are ordered fairly, preventing users with abundant resources or technology from gaining an advantage. The typical fair ordering strategy is FCFS.

Transaction Ordering for Specific Contracts

• Reducing or Eliminating Information Leakage: By ensuring that network participants cannot exploit knowledge about upcoming transactions, FSS can mitigate or eliminate attacks such as front-running based on information available in the network before transaction submission. Preventing attacks based on such leakage ensures that adversarial transactions relying on the original pending transaction cannot enter the ledger before the original transaction is submitted.
• Lowering Transaction Costs: By eliminating the need for participants to pursue speed when submitting transactions to smart contracts, FSS can significantly reduce the costs of transaction processing.
• Priority Ordering: FSS can automatically provide special priority ordering 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 solutions that mitigate MEV in smart contracts, FSS implemented using DON can achieve lower latency, with delays being in the millisecond range rather than multiples of 12 seconds for block delays.

In my personal view, the Ethereum Foundation holds a negative attitude towards MEV. However, under the current centralized power of mining/validator giants in the blockchain ecosystem, it is challenging to solve the problem through transaction encryption and other means in one fell swoop, as it could trigger severe market fluctuations, which would be detrimental to the sustainable development of the blockchain ecosystem. Therefore, gradual improvement solutions like those from Flashbots, which introduce multiple parties into MEV to create checks and balances, gradually weaken the centralization of power, minimizing the impact of MEV on users, and ultimately transitioning to privacy transaction solutions with minimal friction (as emphasized by Vitalik in The Three Transitions regarding privacy issues). MEV has gradually transitioned from an initial dark forest zero-sum game to a stage of checks and balances, perhaps moving towards comprehensive privacy.