Execution Consensus Separation
MEV is fundamentally about control. The proposer has control of which transactions make it into blocks and which order they appear in. In other words MEV is all about censorship and reordering. All of the goals on the Ethereum roadmap related to MEV are therefore impossible without fixing these things. The good news is that fixing these things is possible, the bad news is that the solution requires us to work together to study and prove the security of some meaningful upgrades to both consensus and execution.
Current work on the “Scourge” section of the Ethereum roadmap has been siloed. People work on individual problems and sometimes lose the broader scope of what we are ultimately trying to achieve. ePBS, Inclusion Lists, MEV Burn, Distributed Block Building, and Application-layer MEV minimization, are examples of ideas that require censorship resistance and control over ordering, but we haven’t yet addressed the pre-requisites. Solving these allows us to kill 5 birds with 1 stone. But to do this we need to think from first principles and work on the underlying root causes rather than tinkering with a thin veneer on top of the protocol.
Solving MEV at the protocol level requires buy in from all three levels of the chain:
- Consensus Layer: Multiple concurrent proposers.
- Execution Layer: Delayed execution and deterministic scheduling rules.
- Application Layer: Order-agnostic applications.
Consensus layer
We cannot get anywhere without vastly improved censorship resistance at the consensus layer. This is what allows us to hold auctions and prevent censorship of competing bids. The root cause of Ethereum’s weak censorship resistance is the fact that only a single entity can include transactions during each 12 second slot. Multiple concurrent proposers (MCP) fixes this problem. Instead of coming to consensus on an ordered block of transactions from a single block proposer, each of the K proposers propose a set of transactions at the same time. The protocol then aggregates these proposals using a common subset primitive (or a similar algorithm, this is an active area of research), yielding an unordered set of transactions which are to be included in the block.
MCP solves the problem of censorship-resistant inclusion, achieving the goals of Inclusion Lists in a more natural way. The output is an unordered set of transactions, so it does not solve the problem of reordering. That will be the responsibility of the execution layer.
MCP is an area of active study and we encourage people to get involved. See SMG SPEC-01 for a theoretical description of MCP. Work is currently underway at SMG to formally specify MCP and create a proposed implementation of a gadget for use in the Ethereum protocol. Contact us if you are interested in working on this.
Execution layer
Ethereum’s execution layer must be upgraded to solve the problem of transaction reordering. To do this, we must delay the calculation of the state root to the next block so that the execution layer has time to implement a deterministic ordering rule.
Once it has the transactions, the execution layer has a new important job: figuring out how to order them. To do this, we need to select a deterministic scheduling rule. This is an area of active study where we encourage people to get involved. There are many promising candidates: priority fee ordering, as-needed execution, and distributed block building. We will elaborate on the last two in an upcoming article.
With delayed execution and a deterministic scheduling rule, Ethereum’s execution layer will determine the order of transactions in a block, allowing it to achieve the same goals as distributed block building and ePBS in a more natural way. In addition, since the ordering is enforced by the logic of the protocol, not by the goodwill of any particular validator, the protocol can burn all the fees at this stage, achieving the goals of MEV Burn.
Application layer
Assuming we succeed in the above upgrades, Ethereum’s application layer will be free to upgrade their applications to be natively MEV-resistant while remaining totally onchain. We call the class of things they will do order-agnostic applications or order-agnostic mechanisms.
For example take the problem of liquidation MEV. For the sake of argument, suppose we have 1000 ETH that needs to be liquidated for DAI. We don’t know what the appropriate price is for the ETH, so we have two options: we can guess the right price and have a posted price available to the first person who claims it, which is how Compound and Aave work, and leads to tremendous value leaked to liquidation races, reducing UX. Or, we can hold a Dutch auction, which leads to slightly less value leakage, but doesn’t allow us to clear the distressed debt right away. But now, with MCP and deterministic scheduling, these protocols can simply hold an onchain auction for the right to liquidate 1000 ETH and elicit the price that way.
Order agnostic application design has a number of benefits, and there are many more examples of places where MEV leaks that can be solved. Future posts will elaborate on this.
Conclusion
The successful implementation of these upgrades will result in a much friendlier Ethereum for both developers and users. The first step of this research program is fleshing out and proving the security of a multi proposer design with simultaneous release. Other blockchains have multiple proposers, but are not designed in the same way or for the same purpose. If you are a consensus researcher interested in working on this topic, please reach out, we have funding available for this.