What is zkEVM?

Well, let’s just take it from the beginning. The “zk” refers to zero knowledge and “EVM” refers to the Ethereum Virtual Machine. Breaking those down further:

Zero-knowledge (ZK) Cryptography

In cryptography (and cryptocurrencies), zero-knowledge is a cryptographic method of transaction verification in which a prover develops a proof for specific information, and a verifier validates the proof. A zero-knowledge proof (ZKP) allows someone to publicly verify that they possess specific information without revealing the specifics or details of that information. As a result, zero-knowledge cryptographic proofs provide phenomenal privacy features as well as reduce the computing and storage resources for validating a block by reducing the amount of data held in a transaction (since zero knowledge of the entire data is needed).

The "witness" is the knowledge shared (the data) between a prover and a verifier. The prover must prove that they know the witness accurately, and the verifier must be able to assess whether the proponent has knowledge of the witness.

Source

Shafi Goldwasser, Silvio Micali, and Charles Rackoff invented ZKPs in 1985. Since then, ZKPs have been one of the most actively researched topics in cryptography, thanks to the privacy benefits they offer. Moreover, they have recently had a substantial impact on real-world applications, particularly concerning blockchain technology and cryptocurrencies. ZCash, a pioneering privacy-focused blockchain project, uses ZKPs to create financial transaction anonymity. Specifically, ZCash uses an optimized form of ZKPs known as zkSNARKs, along with shielded transactions that obfuscate transaction details across its public blockchain network, providing anonymity and fungibility.

There are different types/implementations of ZKPs, with some of the most popular being zkSNARK, zk STARK, and PLONK. They each have differences “under the hood” involving the math and polynomial commitment schemes used.

Looking specifically at zkSNARKs, we can breakdown the name/acronym further to get a better understanding of what is actually happening.

Zk: “zero knowledge,” used for protecting user’s privacy
S: “succinct” proofs, referring to data compression, which can be verified in only a few milliseconds. This means that, rather than the Ethereum mainnet validating nodes needing to verify every transaction individually, validators will just verify a small proof to ensure the validity of the transactions. Typically, proofs have a set number of group elements (consider transactions), although the actual proof size is significantly smaller.
N: Non-Interactive signifies that the prover just needs to send a single message to the verifier instead of exchanging messages back and forth. Non-interactivity is necessary because the prover may generate a single proof that can be verified by anyone, anywhere, without ever requiring information sharing with the prover
ARK: generate off-chain trusted proofs

ZKPs can be used for various purposes: a) anonymous payment service, b) allowing access to services without revealing personal data, c) proving statements on personal data, and d) enabling trustless computing services.

While ZKPs are used in zero-knowledge rollups like zkSync, Starknet, Loopring, and others, these rollups are predominantly using the technology for the succinct proofs (the S in SNARK) and the scalability gains that come with it. So, despite being called zero-knowledge rollups, these projects aren’t actually even utilizing the zk portion of the tech. Therefore, oftentimes, they are referred to as “validity” rollups. While not technically accurate, we use the term interchangeably in this piece.

The EVM

In the context of Ethereum, a virtual machine is a software-based computing environment (consisting of Ethereum clients) that replicates the capabilities of a single computer but can be globally accessed. Any entity participating in the Ethereum network must run the EVM to compute state transitions. If all nodes run the same EVM (same rules), all nodes are aware of global state changes.

The EVM keeps state using a data structure known as a "Merkle Patricia tree." Merkle Trees are generated through multiple rounds of hashing. The initial data begins at the bottom (of the image) and is combined with the other data and hashed together to create the parent hash on the rung above. These hashes are pooled (of the same size) and hashed again until a single (root) node remains. A Merkle tree's aim is to enable Merkle proofs, which prove a piece of data exists in the underlying dataset without requiring the broadcasting of the complete dataset.

Source

Merkle trees can store all key-value pairs for all Ethereum addresses. The keys relate to both public and smart contract addresses, and their respective values describe their current state.

EVM Dominance

The EVM is now ~8 years old and has become the predominant runtime environment for the implementation of smart contracts. Currently, the majority of successful decentralized applications (DApps) utilize the EVM, while the ecosystem’s largest bridges all services EVM chains. Additionally, five of the top eight smart contract protocols by market cap utilize the EVM (Ethereum, BNB Chain, Polygon, Avalanche, and Tron).

The preeminence of the EVM as the default runtime environment for smart contracts can be attributed to several factors. Primarily, Ethereum was the first blockchain network to introduce support for on-chain smart contract execution. To facilitate this capability, the Ethereum development team created Solidity, a new programming language specifically designed to compile directly into EVM bytecode. In the early days of blockchain technology, if one wished to implement a smart contract, they were required to learn Solidity as it was the only viable means of targeting the EVM runtime environment utilized by the Ethereum network.

Solidity is designed to compile down to Ethereum Virtual Machine (EVM) bytecode, and it is currently the primary choice when coding smart contracts. Solidity has its problems, though, and other languages like Vyper and Scilla for coding more secure and auditable smart contracts are on the rise. Despite this, Solidity’s syntactic similarity to JavaScript – one of the most popular programming languages in the world – affords it the unique advantage of having a less prohibitive learning curve compared to other languages.

Source

Having Solidity become the de facto "standard" language for writing smart contracts (image below) enables more composability for dApps on Ethereum. Because smart contracts are deployed as open-source code in Solidity on Ethereum, anyone can build on top of these smart contracts by forking the code, incorporating their Solidity code, and creating an entirely new dApp.

Solidity contracts hold 90%+ of DeFi TVL. Source

In addition to Solidity becoming ubiquitous across the industry, there are several other key specifications that originated on Ethereum and have become widely accepted as global standards. These include:

ERC20/ERC721, Ethereum token standards
Ethereum's JSON-RPC Client API, a specification for communicating with Ethereum nodes
Ethers.js, a web library for working with Ethereum
Ethereum cryptography, such as the Keccak256 hash function and ECDSA signatures over Secp256k1
Tools such as Truffle, Ganache, Infura, OpenZeppelin, and Hardhat

This is why the EVM has solidified its position as the de-facto runtime environment for smart contracts and why it is unlikely to change in the near future. Furthermore, new blockchain platforms that seek to attract users, talent, and innovation to their ecosystems often incorporate support for the EVM in some form.

Putting Them Back Together

A zkEVM is a virtual machine that runs on Ethereum that seamlessly integrates zero-knowledge proofs and the EVM, enabling the creation of zero-knowledge proof-based smart contracts that can be executed on the EVM. This allows for the development of ZK-Rollups that are not limited to specific applications and can be utilized to build decentralized applications with greater scalability.

zkEVMs combine the concept of ZK-rollups and the EVM. The fundamental goal of these zkEVMs is to utilize zero-knowledge succinct non-interactive arguments of knowledge (zkSNARK) technology to create cryptographic proofs of execution of Ethereum-like transactions, with the aim of either facilitating the verification of the Ethereum blockchain or constructing ZK-rollups that are equivalent to Ethereum, but with improved scalability.

However, it's important to note that there are subtle distinctions between these projects and the trade-offs they make between the developer experience, scalability, centralization, and compatibility/composability with the EVM and EVM dApps.

Type 1: Fully Ethereum-equivalent

Type 2: Fully EVM-equivalent

Type 2.5: EVM-equivalent, except gas costs

Type 3: Almost EVM-equivalent

Type 4: High level-language equivalent

Why zkEVM?

The goal of creating a zkEVM is to onboard developers and users as quickly and as easily as possible while maintaining compatibility with existing Ethereum tooling, standards, contracts and dApps. zkEVMs are a significant advancement in the field of blockchain because they allow for ZK rollups to support a much broader range of applications than they currently can. The initial implementation of ZK rollups enabled basic operations on highly scalable and cost-efficient Layer 2s, such as sending ETH and transferring tokens. However, with the introduction of zkEVMs, developers can now write arbitrarily complex smart contract code and deploy it to ZK-powered Layer 2s.

Zk roll-ups are also cost-effective by efficiently combining transaction data on Ethereum by omitting transactions and publishing only the final states, reducing the data requirements and costs for posting data on-chain, making it a cost-efficient solution for decentralized applications such as decentralized exchanges and NFT marketplaces.

zkEVMs also offer fast finality and capital efficiency, providing instant finality in transactions after being written on Ethereum, making it an effective solution for NFT traders and DeFi investors who constantly move assets between Ethereum Layers 1 and 2.

However, creating a zkEVM requires converting EVM programs into a specific format called an "algebraic circuit" so that the computations can be proven with zero-knowledge (ZK) proofs.

Source

There are three ways to achieve this:

proving the EVM execution trace directly
creating a custom virtual machine (VM) and mapping EVM opcodes into the custom VM's opcodes
creating a custom VM and transpiling Solidity into the custom VM's bytecode.

Each approach has trade-offs between high compatibility (easy to redeploy from Layer 1) and high performance (quick to generate ZK proofs). Generally speaking, the higher the compatibility with Layer 1, the lower the performance, and vice versa. For example, with the first option, mirroring the EVM directly (high compatibility) introduces massive overhead, resulting in very slow ZKP generation (less performant).

It's important to note that zkEVM has its own advantages and disadvantages. Its advantage includes faster prover time. However, its disadvantage is more incompatibility with EVM compared to already-live Optimist rollup solutions like Arbitrum and Optimism.

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.

Hardware

Hardware Used to Accelerate ZKP There are 3 known hardware technologies used to accelerate ZKP. These include GPUs, FPGAs, and ASICs.

FPGA (Field Programmable Gate Array): These are chips or semiconductor devices programmed to do almost any digital function. It can be configured by a customer to perform any purpose favorable to the customer.

GPU (Graphics Processing Unit): These are chips that can process many pieces of data simultaneously in a machine. It was initially designed for graphics, but its parallel structure makes it able to handle super computation and also mining.

ASIC (Application Specific Integrated Circuit): Just as its full meaning implies, it’s a chip used for specific purposes, mostly used to mine cryptocurrency; and it’s not crypto-specific.

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 its 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.

Source

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. No project is aiming for this level of 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

2. Fully EVM-equivalent

3. EVM-equivalent except for gas costs

4. Solidity equivalent

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.

Polygon’s zkEVM is similar to that of Scroll as both are considered to be EVM-equivalent as of Q1 2023. This means that 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 a Type-3 zkEVM as it makes some sacrifices in terms of compatibility 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. 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.

Source

In many respects, Type-3 zkEVMs are considered to be more transitional than permanent, with the expectation being that the zkEVM will eventually build out to be Type-4 or fully compatible with Ethereum.

Loading...