ETH 2.0 - The New Age of MEV

New Consensus Protocol

The Ethereum’s transition from Proof-of-Work (PoW) to Proof-of-Stake (PoS) was the culmination of years of research and development that finally came into fruition in the most serene way possible. While PoS brings many advantages, it also means Ethereum swerved away from Satoshi Nakamoto’s longest-chain protocol, one of the most elegant and simplest consensus protocols that has been severely battle-tested for decentralised blockchains since the birth of Bitcoin.

As it stands, the new PoS consensus protocol is way more complex given the introduction of a friendly finality gadget called Casper FFG - an improvement of the old Practical Byzantine Fault Tolerance (PBFT) consensus algorithm - that finalises blocks after 6 minutes and 24 second-long epochs and a fork-choice rule that governs the blockchain within each epoch called Latest Message Driven Greedy Heaviest Observed Sub-Tree (LMD GHOST).

‍

‍

We will not go into much detail on both of these topics due to their depth and intricacies but what Casper FFG guarantees is that once a block is finalised, it is not possible to be reverted whilst LMD GHOST assures short term consensus on each 12 second-long slots - the time window where blocks can (not mandatory) be added to the Beacon Chain/Consensus layer (the PoS implementation of Ethereum).

While blockchain’s key function is simple, the infrastructure to provide it in a distributed, scalable, and secure way has grown increasingly complex and is constantly changing as the ecosystem evolves and new technology is developed. Many blockchains have distributed the process amongst various base layer participants with specialised roles, including builders pool operators, relays, searchers, sequencers, and validators. Each base layer participant performs a specific role in the ordering and attestation of new blocks. Under the new Ethereum’s consensus mechanism, PoS node operators must run three pieces of software that are apart of two distinct base layers:

• 🤝 Consensus Layer (CL)
  • Consensus (Beacon) Client
    • Consensus clients run Ethereum's Proof-of-Stake consensus algorithm allowing the network to reach agreement about the head of the Beacon Chain whilst not participating in validating/broadcasting transactions or executing state transitions.
  • Validator Client
    • Validator clients act on behalf of the validator by holding and using its private key to make attestations about the state of the chain. A single validator client can hold many key pairs, controlling many validators. The consensus is achieved by staking ETH tokens by validators that acts as collateral that can be seized & slashed if the validator behaves dishonestly.
• 🏗 Execution Layer (EL)
  • Execution Client
    • Execution clients are tasked with processing and broadcasting transactions and managing Ethereum's state. They run the computations for each transaction using the Ethereum Virtual Machine (EVM) to ensure that the rules of the protocol are followed.

The attentive readers might have noticed that by simply running an Execution Client in conjunction to a Consensus Client you effectively become an Ethereum “listening” node, the software that connects you to the Ethereum network without any pain of block validity nor slashing risk. But why is all this important?

Proposer/Block-Builder Separation (PBS)

Currently, the economics of Maximal/Miner Extractable Value(MEV) pose the biggest risks of the ongoing decentralisation of consensus networks given the existent sophisticated trickery to extract profit from following block’s contents. On any smart contract based blockchain, MEV is the maximal value that can be permissionlessly extracted from transaction ordering in a block. This includes both basic value such as transactions fees and block rewards, as well as advanced value such as any kind of arbitrary inclusion, exclusion and re-ordering of transactions.

The current best-known solution to this problem is the Proposer/Block-Builder Separation (PBS), the ability to detach block building from block append. Rather than having the block proposer produce a revenue-maximising block by themselves, they rely on an auction-based market where outside actors denominated as block-builders produce bundles consisting of complete block contents with an added fee for the proposer. To no surprise, the proposer’s choice is basically reduced to picking the highest-fee bundle.

MEV-Boost is one of the most used PBS implementations by block-builders and was built by the centralised company Flashbots, a research and development organisation formed to mitigate the negative externalities posed by MEV on Ethereum, focusing on lluminating the dark-forest!

So how does it work? MEV-boost can be thought of as a sidecar for the Consensus Client, which queries and outsources block-building to a network of builders. Block builders prepare full blocks, optimising for MEV extraction and fair distribution of rewards. The key reason for this full-block building is to prevent front-running and/or block producers from stealing profits from searchers. This limitation stems from the fact that, with the current architecture, block proposers can only attest to the block headers. They then submit their blocks to relays for block aggregation and selection to determine the highest valued block for later inclusion and attestation through validator’s proposals to the network.

This essentially narrows down to the right-separation of Builders, Relayers and Validators as follows:

• ⛑ Block Builder - Knows the transaction content but cannot predict if their block will be selected.
• 📣 Relay (Flashbots) - Knows the transaction content & ordering result but has no right to execute blocks.
• 👨🏻‍⚖️ Validator (CL w/ MEV-Boost) - Can order and execute transactions but has no idea of the transaction content until the result is confirmed.

Decentralisation Challenges & Multi-block MEV

Having MEV-Boost provision for only full-block building ultimately leads to a restriction on the set of features it can guarantee - the blocks’ contents are completely determined by block builders and by relays who are likely to be centralised organisations (like Flashbots) whose incentives differ from decentralised collectives of block proposers. One way for the block proposers to exercise freewill in block construction involves not participating in MEV-Boost and instead constructing blocks locally. Unfortunately, this pits the economic incentives of block producers against their agency to participate in decentralised block production.

Additionally, a relay service like Flashbots that intends to be OFAC compliant can and will exclude certain user’s transactions to remain cooperative. This raises existential questions for the Ethereum network - why is the network basically handing over block production to a centralised entity that may or may not be excluding transactions due to political uncertainty? A study done by Toni Wahrstätter, an independent Ethereum researcher, shows that Flashbots is censoring Tornado Cash transactions resulting in over 23% of all Ethereum blocks complying with U.S. Treasury sanctions.

Besides Flashbots, Manifold Finance has introduced OpenMEV, a platform that facilitates aggregation and direct communication between block producers and validators. This allows protocols like Sushiswap and OlympusDAO to leverage MEV to their advantage but has not gone live on the new PoS network yet. Despite new competition joining in, Flashbots dominates more than 80% of all relay blocks!

Furthermore, in the new PoS algorithm (RANDAO), not only is the block time fixed to 12 seconds, rather than roughly following a Poisson distribution as it previously did in PoW, but also lets block proposers be known ahead of time. This combination of fixed block times and pre-known block proposers will allow searchers to submit their bundles just before a block is going to be proposed. This introduces new MEV extraction like multi-block MEV where a given entity controlling a certain $p$ share of the network will propose $n$ consecutive blocks with a given probability. This was not possible in PoW due to its inherent algorithm (Ethash) that selected who proposed the subsequent blocks.

With more than 420,069 validators that comprise the Ethereum’s CL, it could be argued that no individual party could ever control multiple consecutive blocks, but keep in mind that not all validators are uncorrelated entities. Operators like Lido and Coinbase control several thousands of validators and could in theory collude maliciously and/or unknowingly with the help of PBS implementations to maximally extract value from proposed blocks and prejudice Ethereum users.

As per the statistical analysis done by @alrevuelta where he estimates the probability of subsequent block assignment that depend on the share of validators owned by a single entity, he found that a party controlling 10% of the validators has close a \frac{1}{4} chance of validating 2 blocks in a row per epoch!

This new situation in block validation opens up new and unthought MEV opportunities, as validators knowingly might validate one or multiple blocks in a row. For example, this could allow an attacker validating two blocks in a row to start an oracle manipulation or arbitrage at block N, and close it only at block N+1. As detailed in a paper from @euler_mab, these multiple-blocks attacks to manipulate the Time Weighted Average Price (TWAP) of a certain Uniswap pool would imply very different requirements for the attacker with no guarantee of success, but are still a possibility.

We could imagine a new version of MEV-boost sending not only one block to the validator, but two in a row, organising transactions between these two blocks. But how realistic is it in practice? We will soon find out. MEV ain’t going anywhere!