EVM compatibility is a metric used to measure the degree of similarity between the behavior of a given system and the Ethereum Virtual Machine (EVM). One framework for understanding this concept includes several levels of compatibility:
- Language-level compatibility: Programs written in one language, such as Solidity, can be compiled or transpiled into bytecode for the target rollup and executed correctly.
- Opcode-level compatibility: The rollup implements all EVM opcodes, but there may be some implementation differences.
- Full EVM-equivalence: Bytecode deployed on Ethereum Layer 1 can be copied and pasted to a given Layer 2, and it runs as if it were operating on Layer 1, with no differences in behavior between the two. This category can also be broken down into two subcategories:
- True full equivalence: the cost of running any opcode on Layer 1 is equal to the cost on Layer 2, multiplied by a constant.
- "Full" equivalence: The Layer 1/Layer 2 gas cost per-opcode relationship varies based on the difficulty of proof.
So-called "EVM-equivalent" zkEVMs, such as Scroll, are able to verify programs that run in an environment that is exactly like the normal Ethereum. These zkEVMs are compatible with the EVM at the byte-code level, which is important because it makes the developer experience virtually indistinguishable from developing on Ethereum itself. It also allows for the re-use of familiar and battle-tested Ethereum clients like geth, and it means that the zkEVM can draft on upgrades to Ethereum itself with minimal extra work needed from the project.
On the other hand, "EVM-compatible" zkEVMs are not as rigorous when it comes to harmonizing with the EVM. These zkEVMs take smart contract code written in, say, Solidity and compile it into a format that has been optimized for ZK proofs. This approach allows for code to run more efficiently, but it throws out a lot of Ethereum's existing infrastructure. The geth client, for example, is known to have certain limitations, which is why teams like zkSync have replaced it with other software written in Rust.
An Ethereum Virtual Machine (EVM) compatible Virtual Machine (VM) is a quick and easy way to onboard most decentralized applications (dApps) running on Ethereum to Layer 2s, but it is inherently un-generalizable and unsustainable in the long term. Achieving EVM equivalence is considered to be the best way forward in optimizing engineering resources and staying up-to-date with developments in the EVM.
The ultimate goal for Layer 2 roll-ups is to be able to deploy any dApps and tooling running on Ethereum directly with minimal changes to the existing codebase. One way to achieve this is to build a custom VM that acts as a proxy between the user of the Layer 2 and the EVM. This VM would execute transactions and also enforce the rules and scaling features of the roll-up.
While this solution is quick to go-to-market, it inherently introduces technical debt as teams would have to maintain the custom VM's codebase to keep up with the developments of the EVM. For instance, not all functionalities of the EVM are available for apps deployed on the Layer 2, as the Layer 2's VM would have to implement a 1-to-1 mapping of the opcodes for both the VM and the EVM. In addition, Layer 2 teams would have to spend precious engineering resources building out custom tooling to support their VM, since existing EVM tooling is not 100% compatible.
A more sustainable solution is to re-implement the entire VM following the specifications stated in the Ethereum Yellow Paper, while introducing Layer 2-scaling features into the VM. This allows the Layer 2 teams to capitalize on existing toolings built for the original EVM, thus optimizing their already-strained engineering resources. Additionally, fewer lines of custom code mean lower risk of introducing vulnerabilities into the VM.
