Maximal Extractable Value (MEV)

Published

December 9, 2024

Introduction

Maximal Extractable Value (MEV) represents one of the most fascinating and complex phenomena in blockchain systems. Originally called “Miner Extractable Value,” the term has evolved to “Maximal” as extraction techniques have expanded beyond just miners. At its core, MEV emerges from the ability to reorder, insert, or censor transactions within a block for profit.

Think of a blockchain as a series of auctions where the auctioneer (block producer) can not only decide which bids to accept but also their order. This power creates opportunities for profit that don’t exist in traditional markets.

We’ll explore MEV attack vectors from a first principles approach at the route of transactions. So MEV risks in order of priority are:

  • Transaction submission
  • Transaction Propagation
  • Transaction Ordering
  • Block Submission

Transaction submission

This is the biggest weakness. More than 90% of transactions are submitted through Wallets. Those wallets use their own RPC providers and while some wallets allow you to specify your own RPC node, that is the exception. This means that any wallet can collude with an RPC provider and they’ll have exclusive MEV flow. https://writings.flashbots.net/state-of-wallets-2024

It makes sense to run a honeypot on all major wallets and then see which ones are the worst offenders here. Name and Shame. Wallets have no incentive for RPC rotation and I don’t see it being adopted unless they’re forced to.

Transaction Propagation

How the P2P protocol propagates is a major weakness. Let’s look at EThereum, it uses a Probabilistic Relay it looks at the following

  • Previous communication reliability
  • Network latency
  • Geographic distribution
  • Historical performance

This means if I’m rich, I can just set up Validators in Geographically important areas and juice my servers and then always get messages before everyone else

Transaction Ordering

This is super interesting as sequential blockchains vs DAG based networks will have significantly different MEV characteristics. So there’s actually the following types of networks:

  • Sequential
  • DAG
  • Sharded
  • Layered
  • Heterogeneous
  • Fractal Networks

We’ll explore MEV on the following Network Topologies:

  • Bitcoin
  • Ethereum, BNB, Avalanche, TRON
  • XRP, Stellar
  • Solana
  • Sui
  • Cardano
  • TON
  • DOT

So for each network we need to understand the following:

  • The transaction lifecycle
  • Transaction Propagation. These are all available via the Networking Chapter.
  • Validator/Miner Selection
  • How Blocks are built by Validators/Miners

EVM Networks

There will be nuances between them that we’ll include as we progress with this Chapter.

Transaction Lifecycle

sequenceDiagram
    participant User as User Wallet
    participant RPC as RPC Node
    participant Validator as Block Validator
    participant Blockchain as Ethereum Blockchain

    User->>RPC: Broadcast Signed Transaction
    activate RPC
    
    RPC-->>RPC: Validate Transaction
    RPC-->>RPC: Check Sender Balance
    RPC-->>RPC: Verify Signature
    
    RPC->>RPC: Prioritize by Gas Price
    RPC->>Validator: Propagate Valid Transactions
    
    activate Validator
    Validator-->>Validator: Select Transactions
    Validator-->>Validator: Create Block Candidate
    
    Validator->>Blockchain: Propose Block
    activate Blockchain
    
    Blockchain-->>Blockchain: Validate Block
    Blockchain-->>Blockchain: Execute Transactions
    Blockchain->>Validator: Block Confirmation
    
    Validator->>User: Transaction Confirmed
    
    deactivate Blockchain
    deactivate Validator
    deactivate RPC

Validator Selection

sequenceDiagram
    participant Beacon as Beacon Chain
    participant Epoch as Epoch Management
    participant Registry as Validator Registry
    participant Selection as Random Selection Mechanism
    participant Slot as Slot Manager
    participant Validator as Selected Validator

    Note over Beacon: Proof of Stake Consensus Mechanism
    
    Beacon->>Epoch: Initiate New Epoch
    activate Epoch
    
    Epoch->>Registry: Request Active Validator Set
    activate Registry
    
    Registry-->>Registry: Filter Active Validators
    Note right of Registry: Criteria Include:
    Note right of Registry: - Minimum 32 ETH Staked
    Note right of Registry: - No Slashing History
    Note right of Registry: - Online and Responsive
    
    Registry->>Selection: Provide Validator Pool
    activate Selection
    
    Selection-->>Selection: Apply Randomness Beacon
    Note right of Selection: Uses Verifiable Delay Function (VDF)
    Note right of Selection: Ensures Unpredictable, Unmanipulatable Selection
    
    Selection->>Slot: Propose Block Proposer
    activate Slot
    
    Slot-->>Slot: Assign Slot Number
    Slot->>Validator: Block Proposal Responsibility
    activate Validator
    
    Note over Validator: Validator Prepares Block
    Validator-->>Validator: Collect Transactions
    Validator-->>Validator: Execute State Transitions
    Validator->>Beacon: Propose Block
    
    deactivate Validator
    deactivate Slot
    deactivate Selection
    deactivate Registry
    deactivate Epoch

Understanding MEV

The Mechanics of MEV

When users submit transactions to a blockchain network, they enter a temporary holding area called the mempool. Block producers can then:

  • Choose which transactions to include
  • Determine the order of transactions
  • Insert their own transactions
  • Create custom transactions in response to user activity

This control creates several profit opportunities:

  1. Arbitrage

    • Spotting price differences across DEXs
    • Exploiting temporary market inefficiencies
    • Capturing price movements from large trades

  2. Liquidations

    • Competing to liquidate undercollateralized positions
    • Racing to claim liquidation rewards
    • Front-running other liquidators

  3. Sandwich Attacks

    • Placing trades before and after a large swap
    • Exploiting price impacts for profit
    • Extracting value from user slippage tolerance

sequenceDiagram
    participant U as User
    participant N as Node
    participant M as Mempool
    participant V as Validator
    participant B as Blockchain
    
    U->>N: Submit Transaction
    N->>M: Add to Mempool
    M->>V: Transaction Available
    V->>V: Create Block
    V->>B: Append Block
    B->>N: Confirm Transaction
    N->>U: Transaction Complete

MEV Extract Methods

Searchers and Builders

The MEV ecosystem has evolved into specialized roles:

Searchers:

  • Develop algorithms to identify MEV opportunities
  • Create optimal transaction bundles
  • Bid for block space through builders

Builders:

  • Aggregate transaction bundles from searchers
  • Construct optimal blocks
  • Compete to have their blocks chosen by validators

MEV-Boost

MEV-Boost represents a crucial development in MEV extraction, separating block building from block validation:

User Transactions → Searchers → Builders → Relays → Validators

This separation aims to:

  • Increase competition among builders
  • Improve block construction efficiency
  • Distribute MEV more evenly

Proposer Builder Separation (PBS)

PBS represents the next evolution in MEV management, aiming to institutionalize the separation of block building and proposal.

Core Concepts

PBS divides block production into three distinct roles:

  1. Proposers (Validators)

    • Select the most valuable block
    • Earn fees from block proposals
    • Don’t need powerful hardware

  2. Builders

    • Construct optimal blocks
    • Compete through bid prices
    • Require specialized infrastructure

  3. Relays

    • Connect builders and proposers
    • Verify block validity
    • Ensure fair competition

Technical Implementation

PBS requires several key components:

  1. Builder API
interface IBuilder {
    function submitBundle(
        bytes[] calldata transactions,
        uint256 bid
    ) external returns (bytes32 bundleHash);
}
  1. Relay Protocol
interface IRelay {
    function submitBlock(
        bytes[] calldata transactions,
        bytes32 parentHash,
        uint256 bid
    ) external returns (bool success);
}

Multiple Concurrent Leaders (MCL)

MCL represents a novel approach to MEV that allows multiple validators to propose blocks simultaneously.

Design Goals

MCL aims to:

  • Reduce MEV extraction opportunities
  • Increase network throughput
  • Improve censorship resistance

Technical Challenges

Implementing MCL requires solving several complex problems:

  1. Leader Selection
    • Determining concurrent proposers
    • Managing overlapping proposals
    • Resolving conflicts
  2. Block Merging
    • Combining parallel proposals
    • Handling transaction conflicts
    • Ensuring deterministic outcomes

MEV Protection Strategies

For Users

Users can protect themselves from MEV through several strategies:

  1. Commitment Schemes
// Example of a commit-reveal scheme
contract CommitReveal {
    mapping(bytes32 => bool) public commits;
    
    function commit(bytes32 commitHash) external {
        commits[commitHash] = true;
    }
    
    function reveal(bytes32 secret, uint256 value) external {
        require(commits[keccak256(abi.encodePacked(secret, value))]);
        // Execute trade with committed value
    }
}
  1. Intent-Based Trading
    • Expressing desired outcomes rather than specific paths
    • Using specialized intent protocols
    • Allowing builders to optimize execution

For Protocols

Protocols can implement MEV-resistant designs:

  1. Batch Auctions
    • Aggregating trades into discrete batches
    • Using uniform clearing prices
    • Preventing front-running
  2. Time-Weighted Average Prices (TWAP)
    • Spreading execution over time
    • Reducing manipulation opportunities
    • Improving price stability

Future of MEV

Emerging Solutions

Several promising approaches are being developed:

  1. Zero-Knowledge MEV
    • Privacy-preserving order flow
    • Encrypted mempool designs
    • Confidential transaction ordering
  2. Fair Ordering Services
    • Decentralized sequencing
    • Verifiable delay functions
    • Random beacon systems

Regulatory Considerations

The MEV landscape faces increasing scrutiny:

  1. Market Manipulation
    • Sandwich attack legality
    • Front-running regulations
    • Fair market requirements
  2. User Protection
    • Disclosure requirements
    • Best execution standards
    • Consumer protection rules

Conclusion

MEV represents a fundamental challenge in blockchain design, sitting at the intersection of mechanism design, game theory, and market structure. While it cannot be eliminated entirely, continued innovation in areas like PBS and MCL promises to make MEV extraction more efficient and equitable. Understanding MEV is crucial for anyone building or participating in blockchain systems, as it affects everything from protocol design to trading strategies.