Introducing EVM Equivalence
Or, Ethereum All the Way Down: How We Learned to Stop Re-implementing and Love the Ethereum Stack
Last month, we announced the most significant upgrade in Optimistic Ethereum’s history. Recently, we migrated Optimistic Kovan to true one-click deploy and increased stability, with mainnet to follow in less than three weeks.
But this post isn’t about one-click or incremental improvements.
This is a post about our belief that EVM Equivalence — complete alignment with the Ethereum Virtual Machine specification— will become the next universal standard across the L2 space.
A Brief History of Optimistic Dispute Protocols
First, let’s recap the path we’ve taken to current-generation rollups.
Dawn of Rollups
Optimistic L2s are all about disputes. If you think of Ethereum as an almighty, decentralized court, then the core insight of L2 scalability is: “don’t go to court to cash a check — just go if the check bounces.”
Effectively, the past 6 years of scalability research boil down to one thing: what kind of “bounced checks” could be enforced. At first, only a pre-agreed set of parties could transact among each other (state channels!). Then, anybody could transact, but could also be censored (plasma!). Eventually, we solved censorship too (rollups!).
Before rollups, we’d known how to run smart contracts on all of these models — it just didn’t make much sense. Who wants to run Uniswap just between a few friends, or in a way that can be censored for a week? Rollups promised a true, Ethereum-style L2 experience.
The Compatibility Age
Of course, just ‘promising’ a true Ethereum-style layer 2 experience doesn’t actually create the implementation. For Unipig, the first ever L2 AMM, we had to recreate Uniswap using custom code that was compatible with the rollup dispute contract — not the EVM itself.
This was feasible due to Uniswap’s relatively simple design, but it doesn’t bode well when something as basic as a Solidity variable can no longer be used. For the non-devs; Uniswap is one of the simplest DeFi smart-contracts out there, it doesn’t bode well will even Uniswap needs an overhaul to be “rollup compatible” out of the box!
By now, Ethereum had long-surpassed escape velocity. An exponentially growing ecosystem simply couldn’t rearchitect around a non-EVM interface. Therefore, it became L2’s responsibility to ensure that the L1 court system was minimally differentiated from the EVM, in addition to providing “raw” scale. This forced rollups to pioneer on two fronts at once:
- Building a scalable, production-ready rollup infrastructure.
- Solving the long-infamous EVM-in-EVM problem.
Ethereum’s Turing-completeness meant that we knew it could be done, but in the process of our research we learned that something would need to be sacrificed in order to bring Ethereum to L2 in a reasonable timeframe.
This sacrifice would become known as EVM “Compatibility”.
The argument was simple: so long as Ethereum apps could be reasonably ported to run on the rollup — regardless of how this was accomplished behind the scenes — we could catch Ethereum’s escape velocity.
The Great Flood
Initially, this compromise paid off. In 2020, we raced to ship the OVM as users fled Ethereum to other layer-1 competitors that abandoned security and values under the guise of “cheap fees”. We launched our mainnet in January, and, over the last 10 months, we’ve saved users hundreds of millions of dollars over several million transactions.
But the escape velocity generated by Ethereum’s network effects takes many forms, and our soaring usage highlighted another component of L1-Ethereum that other L1 and L2s lacked: infrastructure. Over the past 6 years, Ethereum’s global community has taken it from a barebones prototype, to so much more:
- Thousands of development tools have been deeply integrated into the EVM.
- Billion-dollar companies have arisen solely to serve and improve node software.
- Ethereum itself has gotten faster and faster.
The wave of Ethereum’s network effects is only growing larger and larger. Since everything is open source, one might expect that these massive wins would also apply to Ethereum L2s too.
But not so much.
EVM compatibility is not the same as EVM equivalence, and settling for mere compatibility means that you are forced to modify, or even completely reimplement, lower-level code that Ethereum’s supporting infrastructure also relies on. If L2s want to surf Ethereum’s wave of infrastructural network effects, they must become EVM equivalent.
As Optimistic Ethereum grew, we discovered that more and more Ethereum tooling was continuously finding itself out of reach, due to our old design philosophy of EVM compatibility.
We knew that we could do better. To truly support the masses, we needed something that wasn’t just compatible with EVM contracts, but was instead fundamentally equivalent to the EVM itself.
EVM equivalence is how we bridge the gap between Ethereum L1’s infrastructural network effects, and Ethereum L2’s execution environment.
EVM Equivalence: Riding Ethereum’s Wave of Adoption
…What is EVM equivalence?
In short: EVM equivalence is complete compliance with the Ethereum yellow paper, the formal definition of the protocol. By definition, L1 Ethereum software must comply with this specification.
This means that — down to the very deepest depths — the existing Ethereum stack will now integrate with the L2 system, too. Every debugger. Every toolchain. Every node implementation. We believe that any L2 offering any EVM experience will have to meet this bar — anything less is unacceptable.
…Why is EVM equivalence good?
From day 0, we’ve built our software on Geth, Ethereum’s most robust and popular implementation — this was the only viable path to a production-ready Ethereum L2. The OVM v1 introduced a containerization system which sat on top of Geth’s EVM and helped avoid tediously re-implementing the entire EVM on L1.
This combo earned some early wins, but since the EVM doesn’t natively support containerization, it wasn’t free. Even for our Geth-focused team, the changes started to add up. As Optimistic Ethereum grew, the incredible power of equivalence could not be ignored:
- Projects like Solidity, Vyper, and Hardhat selflessly worked on OVM versions of their devtools, but we risked fragmenting these already-resource-constrained teams. This taught us that teams would always need to be dedicating labor to maintaining non-equivalent codebases.
- With each line of code changed, it became harder to adopt experimental implementations like Erigon down the line. This taught us that we would always need to be dedicating labor to integrating future client implementations.
- Re-implementing parts of the EVM introduced gas overhead in comparison to existing, hyper-optimized versions. This taught us that mimimizing gas costs required an EVM equivalent design philosophy.
It was time to pursue a better approach, even if it required some tedium.
…How do we achieve EVM Equivalence?
Thankfully, we found a better way than tediously re-implementing the EVM in the EVM. Here’s what you do.
Separating Block Generation and Execution
Okay — in practice, we do have to make some changes to L2-ify Ethereum: particularly, how blocks are generated. On L1, nodes use a proof-of-work consensus mechanism to determine blocks; on L2, batches of transactions are applied via batches sent to a “parent chain” (L1 Ethereum). If an L2 used its own proof-of-work, then it would be an L1! So “equivalence” is fundamentally nonsensical at this level.
A core pattern of blockchain modularization is separating consensus from execution — that is, having different processes for determining and executing the next block. We can borrow this pattern for use in L2. Basically, we just define a function which accepts L1 blocks, processes them for rollup transactions, and outputs L2 blocks — in exactly the same format as L1 blocks. From there on out, the L2 execution can be defined as equivalent to L1.
ETH2 Merge API
So, what is the status of consensus/execution modularization among existing L1 client implementations? Well: it is about to be standardized across ALL Ethereum implementations.
As it turns out, the ETH2 merge requires exactly the same abstraction that EVM equivalent rollups do: the beacon chain serves the exact same “parent chain” role that L1 does for rollups. This will make it dead simple to drop in L1 clients for use in L2.
Enforcing the Standard
Okay, so we’ve covered why equivalence opens the door to a powerful, modular abstraction, and a dead-simple client implementation. But how do we actually enforce this on-chain? Well, first of all, the power of this modularization is to be flexible — so long as a solution is EVM-equivalent, we can use it. This means that improvements to the fraud proof, and even EVM-equivalent zero-knowledge proofs when they become feasible, can be trivially slotted into the existing off-chain stack.
In the short term, though, we need something feasible today — and we have found just that. One solution would be to implement a perfect EVM-equivalent implementation in Solidity, but the EVM is a complex beast with many VM instructions, making this a significant undertaking. Furthermore, future updates to the EVM would have to be re-implemented in Solidity too.
Our solution: instead of implementing the EVM in Solidity, implement a VM with a much smaller, simpler instruction set, and run the EVM within this VM during fraud proofs. To do this, we must simply compile an existing EVM interpreter, such as geth’s, to run within the simpler VM.
TL;DR: we allow Geth itself to run inside a dispute-friendly environment. Since Geth is EVM-equivalent, so is that environment. This allows us to bypass re-implementing the EVM on-chain, and future-proofs the system against future upgrades to the EVM.
We are working with George Hotz, our favorite compiler expert, to build out the first EVM-equivalent proof system. Progress is nothing short of exciting — already, the system can run all L1 blocks since the London hard fork. Running L1 blocks through a fraud proof is a funny, counterintuitive thought — but this is exactly what it takes to be equivalent!
Whew — there are so many more exciting things to say about this approach, but we’ll have to leave the rest for future posts!
Future of Ethereums
If Ethereum is to achieve its rollup-centric future, then rollups must become Ethereum-centric.
This is what equivalence offers.
Fraud proofs are dead. Long live fraud proofs
This modular, Geth-centric design isn’t just about an elegant implementation for us to use — it’s a huge step towards commoditization of fraud proof infrastructure. Today, safely designing and launching a rollup requires an intimate knowledge of L2 dispute games, and how they work together with node software. This severely limits innovation — imagine a world in which every web developer also had to be an expert in IP networking, system administration, and microchip manufacturing.
Rollups of the future will be so simple that it doesn’t take an L2 expert to deploy one. This means that L2s will no longer compete on how or whether they provide security, but on what they provide security over. This includes competing on:
- Performance, stability, and uptime
- Network effects, ecosystem specialization, and community
- MEV prevention and sequencing tools
In sum, this means that EVM equivalent rollups are competing on decentralization.This is a huge win for democratization across the entire ecosystem, and an important step in making our entire industry more anti-fragile and censorship resistant.
It also means our team can finally focus on our core competency — the most important part — building the fastest, most reliable, and most secure L2 Geth that the world has ever seen.
The shackles of Ethereum compatibility are off.
#ETHTheStandard
The power of EVM equivalence comes down to standardization.
In a multi-chain world, “write once, deploy everywhere” becomes critical.
Having many “compatible” chains, each of which are slightly different, leads to fragmentation: you go from needing a single team of EVM experts working on a single codebase, to teams of EVM experts for each codebase for each chain.
Vitalik compared the EVM to Javascript even when he first unveiled it, and the analogy is reflected especially well this context. In the early days of the internet, incompatibilites between web-browsers (looking at you, IE) plagued web development and caused developer and ecosystem fragmentation.
Web3 is all about coordination and open source standards, and equivalence offers a path for what is clearly emerging as the standard — the EVM — to avoid repeating mistakes of the past.
And even as this standard evolves, our approach to fraud proofs means that L2 can effortlessly evolve in unison. L1 and L2 move forward together, hand-in-hand. Lock-step.
This benefit goes both ways — when almost all Ethereum EIPs can be adopted on L2, and rollups become an exciting new live testbed environment for innovation. Imagine a rollup that sits somewhere between an incentivized testnet and mainnet, proving out new transaction types, precompiles, and EOFs in the wild, testing for unforeseen consequences before they graduate to L1.
One of the biggest hurdles of DeFi is that, test all you want, there is no replacing the live environment of DeFi. You can’t ‘recreate’ DeFi on a testnet, so when you want to test changes, it’s always ‘testing in prod’.
EVM equivalence allows us to test EIPs in a live environment, and make safer, long-term improvements to the holistic Ethereum environment, without “fingers-crossed hardforks.”
Ethereum All The Way Down
We recently launched our first experiment in retroactive public goods funding. $1 million of protocol revenue will soon be awarded to public goods that benefit Ethereum! Some people have asked us why this money is going to Ethereum at large, and not just the Optimistic Ethereum ecosystem from which it came.
Hopefully, with a newfound understanding of EVM equivalence you can see why: we are the same ecosystem.
Layer 2 has long-promised a multichain Ethereum future, with vibrant cities reaching deep into the frontier of this new cyberspace. While we can expect these chains to be diverse and plentiful, EVM Equivalence introduces a newfound connection to Ethereum — not just as a settlement layer, but at the deepest levels of their composition.
It’s Ethereum all the way down, and it always will be. 🚀
We’d like to give a sincere thanks to the incredible community members who have helped make this happen, and helped us share it: to Ansgar Dietrichs, David Hoffman, George Hotz, Georgios Konstantopoulos, lightclients, the Magmo team, protolambda, ricmoo, and countless others: thank you!!!!
And as always — WE ARE HIRING! If you want to work on not just the future of Ethereum, but the future of Ethereums, we want to talk. And if you just want to follow along, join our discord!
