摘要： EVM equivalence turns the Ethereum Layer 2 Rollup ecosystem into an adaptive, responsive layer that grows into the frontier!
Understanding ✨EVM Equivalence✨
EVM Equivalence: complete alignment with the Ethereum Virtual Machine specification
The EVM equivalence design philosophy is to produce an optimistic rollup with ‘minimal dif’ to Ethereum.
EVM equivalence extends the properties of Ethereum into its L2s. It blurs the line between when the Ethereum L1 stops, and the L2 rollups begin.
This is the difference between scaling on Ethereum, and scaling Ethereum itself.
Optimistic Rollups that are perfect clones of Ethereum’s EVM don’t just share in Ethereum’s security; they share every aspect of its network effects.
Other L2 design constructions do not have the same privilege of accessing all of Ethereum’s network effects, and will always be more specialized than their EVM equivalent counterparts.
EVM compatibility is dead. Either optimize for generalizability by adhering to the Ethereum standard (and therefore pick the same standard as everyone else), or build something completely different that’s highly optimized for your use case (see ZK-rollups).
In order to fully extend the full might of Ethereum to the L2s, we’ll need more than mere EVM compatibility.
We need EVM equivalence.
Compatibility vs Equivalence
When the Optimism team introduced EVM equivalence last year, they covered the technical differences between equivalence and compatibility.
Rollups were hailed as our scaling savior: “finally, an L2 which can run Uniswap!”
The earliest rollups accomplished this by completely recreating Uniswap, with custom code on top of a custom-built rollup.
This just wasn’t enough.
The network effects of the EVM extend far further than just Solidity. A massive supporting cast of tools give Ethereum devs their superpowers. Because these tools also run on the EVM standard, they broke for the custom-built rollup. Not to mention the massive effort required by protocol devs to create something Solidity-compatible!
With EVM equivalence, the EVM itself is copy+pasted into L2. Everything under the hood is the same.
The EVM is a city
David Mihal (who helped me understand this) gave me this metaphor: “Open-source code is like a city. It’s emergently created, bottom up, from the contributions of many developers who see problems and build solutions. Over time, the city becomes optimized, robust, and efficient……EVM-ish chains are like the Las Vegas version of Paris; they’re trying to artificially replicate something that came organically”
Open-source software is a public good, maintained and upgraded by respective communities.
Developers that use open-source software run into all sorts of problems while using it; some trivial, some critical, and everything in between. Some developers spend time fixing these problems, and then lobby the community to accept their inputs. If the community sees value, then the contribution is merged. A new standard is created, and the piece of software grows in utility and robustness.
Like an emergent city, builders come and produce things that the surrounding community needs and values. Shared resources and utilities are produced, and since it’s code, it never decays. It’s a one-way street of increasing value; so long as everyone is working on the same foundation.
Every developer builds in their own direction and discovers their specific contributions to add to the collective. Over time, a highly robust public good is produced by the shared contributions of thousands of developers.