You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
How do zkEVMs work?
zkEVMs are composed of three distinct parts: a running (execution) environment, a proving circuit, and a verifier contract. Each of these components plays a crucial role in the operation of the zkEVM, from execution and proof generation to verification.
The Execution Environment is where smart contracts run in the zkEVM. It functions similarly to the EVM and its output is a new state derived from the initial and current transaction.
The Proving Circuit is where transactions in the execution environment are verified using zero-knowledge proofs. The circuit uses pre-state, transaction, and post-state inputs to complete the proof generation process. Through this process, the prover asserts a concise validity proof of the state transition.
ZKPs are slower than OR’s approach because of the conversion process from a classical program to a Zk-friendly format is cumbersome. This process requires the prover to translate the code into a high-level language, such as Cairo in the case of Starknet, which then compiles it into a proof. This process is both time-consuming and complex, as most computations are not natively compatible with Zk. Once the proof is in the Zk format, it can be sent to a proof system like ZK-snark or ZK-stark, which are the two most widely used Zk algorithms. However, this slow speed of ZKPs is a challenge that must be addressed in order to make them more efficient and accessible for widespread use.
The Verifier Contract is responsible for providing validity proofs to smart contracts deployed on Ethereum. The pre-states, transactions, and post-states are further committed to the verifier contract. Then, the verifier contract analyzes the provided proof through computations, ensuring that the submitted outputs are correctly generated from inputs.
Issues with zks and the EVM
Ethereum, being a blockchain platform designed prior to the integration of zero-knowledge proofs, presents a number of obstacles in terms of their implementation within the ecosystem. These limitations extend to the implementation of zero-knowledge Ethereum Virtual Machines (zkEVMs), particularly in terms of the time required for prover computation. In the case of Type-1 zkEVMs, the absence of optimization for proof generation results in prohibitively high costs.
The creation of a zkEVM represents a significant technical challenge, given the design of the Ethereum Virtual Machine (EVM) and the specific requirements of zero-knowledge proof systems. One of the key difficulties lies in the stack-based architecture of the EVM, which complicates the proof generation process. The stack is a data structure that uses the last-in, first-out principle and has a word size of 256 bits, allowing for native hashing and elliptic curve operations, critical components in ensuring the security of funds. The EVM executes a program by pushing data onto the stack, performing operations, and then popping the data off when it is no longer needed.
The use of special opcodes by the EVM, particularly for error handling and program execution, adds to the complexity of the proof generation process. The utilization of these opcodes, while necessary for handling more complex tasks and errors, can increase the difficulty of verifying the correct functioning of the EVM.
EVM Compatibility
In 2021, many of the so-called "Ethereum Killers" relied on EVM compatibility and token incentives to lure users away from the Ethereum ecosystem. However, while this strategy was successful for Layer 1 adoption, it may not be as effective for zkEVMs due to a tradeoff between Ethereum compatibility and performance. More specifically, zkEVMs that prioritize Ethereum compatibility will be less efficient due to computational inefficiencies and longer wait times for L1 finality, but they will provide out-of-the-box functionality that requires little to no contract alterations. In contrast, zkEVMs that prioritize performance will require more backend changes and may struggle with user adoption. While token grants and ecosystem funds may incentivize development and user adoption, they are not always effective in driving sustained adoption. Nonetheless, the slow but steady growth of Arbitrum and Optimism during the last year provides hope that these challenges can be overcome.
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 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 a lower risk of introducing vulnerabilities into the VM.
Language vs. Bytecode Equivalence
Creating a zk-enabled EVM that is entirely compatible with Ethereum's EVM offers the best of both worlds: orders of magnitude more scalability with all of the network effects and users that come with Ethereum's EVM dapp ecosystem. However, there are degrees to which a zkVM can be compatible with the EVM. This equivalency is similar to EVM-compatible and EVM-equivalence in the Optimistic rollup space.
The math and proof system behind ZKRs are not easily compatible with Ethereum's EVM code/construction. ZKRs require arithmetic circuits to demonstrate the correctness of a ZK computation, and circuits are complex. ZKR developers are required to write low-level code to create them. Moreover, proof creation time is not scalable and can be costly.
zkEVM projects differ in their degree of compatibility with the EVM. The EVM compiles high-level programming languages like Solidity into bytecode, which can be executed by the EVM. There are two primary approaches to EVM compatibility for zkEVMs: language compatibility and bytecode compatibility.
zkEVM difficulty and development scale. Source
The choice between language compatibility and bytecode compatibility for zkEVMs involves a tradeoff. Language equivalence, which is achieved by compiling high-level languages into non-EVM bytecode that is optimized for the zkVM to run circuits, can result in better performance. On the other hand, bytecode equivalence, which involves executing and proving the same bytecode as the EVM, provides better compatibility with existing smart contracts on the EVM. Therefore, the choice between the two types of EVM compatibility depends on the specific needs and priorities of the project.
Bytecode-compatible zkEVMs execute and prove the same bytecode as the EVM, meaning that developers can continue to use the same programming languages, compilers, and tools as they usually would while also benefiting from the scalability and security features of zero-knowledge circuits. However, achieving bytecode compatibility can be challenging from an engineering perspective because it requires mapping opcodes onto custom ZK circuits. This mapping can lead to larger circuits and costlier proof generation, but it ultimately simplifies the development experience.
LANGUAGE-LEVEL
The first (bottom) level is "language-level" EVM compatibility. This is the current approach by projects like zkSync or Starkware that involves using an intermediate VM (for more circuit-friendly programming) but then having to compile it into different bytecode. The projects translate an EVM-friendly language like Solidity or Yul into a zk-friendly language like Zinc or Cairo. Once translated, the code runs on their own virtual machine, entirely distinct from Ethereum's EVM.
The downside of this approach is that it is the least compatible, and the zkVM does not have direct support for the Solidity programming language. This can be a disadvantage for developers as it requires a more comprehensive understanding of additional languages in addition to Solidity. Furthermore, smart contracts written in Solidity must be compiled into a language that the zkVM can interpret, which could add an extra step for developers and could be challenging for those who are not familiar with other languages. As a result, developing on the zkVM may require a higher level of expertise and additional resources for development, which could be a limitation for some projects.
EVM first level is the language level. Source
However, the primary benefit of this technique, and why Starkware and Matter Labs would argue it is all worth it in the end, is that developers can create a zk-friendly VM without being constrained by the EVM's inherent limitations. Rather than being compatible with a sub-optimal design, they are incompatible but with far superior optimizations.
Language-compatible zkEVMs can operate with high-level programming languages like Solidity or Vyper. However, this requires a specific compilation step for the zkEVM network, resulting in bytecode that differs from the EVM. Non-EVM bytecode can be designed to be more circuit-friendly, leading to more efficient proof generation.
The deployment flow to a zkEVM will depend on whether it is bytecode-compatible or language-compatible. In the former case, there are no changes to the development experience other than where the contract is deployed. In the latter case, there is an additional step required to compile the high-level language into non-EVM bytecode that is compatible with the zkEVM.
BYTECODE-LEVEL
The second level is "bytecode-level" equivalence. This level is where projects like Polygon Hermez 2.0, Scroll, and the Ethereum Foundation’s/Consensys zkEVM sit. It has full compatibility at the EVM opcode level and compatibility at the Solidity language level, making it a true "zkEVM." EVM opcodes are mapped to circuits, which simplifies the development process for Solidity contracts on zkEVMs that support bytecode compatibility. Developers do not need to make any changes to their Solidity contracts, and everything works out of the box. However, mapping EVM opcodes to circuits can be challenging for rollup teams, resulting in additional development efforts.
Scaling solutions compatibility comparison. Source: Scroll
Bonus Level: Consensus Level
The consensus level is the third and final level of zkEVM. In addition to the language- and bytecode levels, it achieves consensus-level compatibility.
Type 1, 2, 3, and 4
Another way of categorizing ZKR compatibility with Ethereum and the EVM was put forth by Vitalik Buterin. While there is considerable overlap, there are key differences as well as a different nomenclature introduced. In his blog, Vitalik explains there are four different types of zkEVMs depending on their implementations, compatibility, and performance metrics as there are tradeoffs with different design choices.
1. Fully Ethereum-equivalent: Taiko and The Ethereum Foundation’s Privacy and Scaling Explorations (PSE) team
2. Fully EVM-equivalent: Polygon zkEVM, Scroll, and Consensys
3. EVM-equivalent except gas costs
4. Solidity equivalent: zkSync and Starknet
The Different Levels of zkEVMs - Vitalik Buterin
Performance in zkEVMs is measured by the time it takes to generate zk-proofs. The faster the generation of zk-proofs, the more scalable the zkEVM is. zkSync is a type 4 zk-EVM, which offers higher performance but at the cost of lower compatibility. This type is more challenging to implement due to its lower compatibility with EVM.
Type 4 zkEVMs like zkSync sacrifice some compatibility with the EVM in order to achieve faster proof generation, resulting in higher scalability. However, developers must consider the trade-off between performance and compatibility when implementing these types of zkEVMs.
Type 2, 2.5, and 3 zkEVMs, which are designed to simplify the proof generation process of Ethereum, make some changes to the Ethereum stack, including changing gas costs for ZK-unfriendly operations. These changes can result in lower proof generation costs while maintaining bytecode level compatibility, but they could also have some unintended consequences.
Firstly, some security mechanisms could change. For example, if gas costs are changed, smart contracts that rely on a fixed gas limit for an ETH transfer might no longer be secure, allowing state changes to occur. Secondly, changing gas costs could have side effects, causing the contract to use more gas than intended or exceeding the block gas limit. Thirdly, changing the block hash could also have side effects, breaking compatibility for smart contracts that rely on the block hash.
Both Polygon zkEVM and Scroll are not fully compatible with all things Ethereum, but the EVM. Strides have been made to improve this compatibility, hence the “upgrade” from Hermez v1 to zkEVM on the part of Polygon. Polygon zkEVM is sometimes referred to as a type-2.5 zkEVM because of the changes to gas costs in order to optimize performance. Thus, Polygon zkEVM is far easier to build, has faster prover times, and quick finality, but less compatibility with Ethereum than some competitors like Scroll. Some applications wishing to move to Polygon zkEVM will require additional work in rewriting some code to make it compatible, though this is stated to be at least minimized in Polygon zkEVM compared to Hermez v1.
Typle 1 zkEVMs, like Taiko, are equivalent to Ethereum itself and is also a general-purpose ZK-Rollup. Taiko provides a way for developers and users of dApps that were built for the Ethereum Layer-1 chain (L1) to use Taiko's blockchain as if they were working on Ethereum L1.
