Recently, several ZK-Rollup projects have announced plans of their own mainnet or testnet which will support ZK-EVM. Meanwhile, in early August 2022, Ethereum founder Vitalik published a blog comparing different types of ZK-EVM. The holy grail of ZK-Rollup, which might be a powerful tool for Ethereum scaling, has returned to the market spotlight.

Ethereum scaling, a frequently discussed topic, is expected by plenty of crypto users. There is a widespread misconception that the Ethereum Merge scheduled in late September will not only shift the network from PoW to PoS but also improve its performance. In fact, the Merge will not change the block size, and the average block time will only go from 13 seconds to 12 seconds. Therefore, the performance improvement will be very limited. As such, in the short term, Ethereum will have to rely on Rollups for scaling. Of two primary types of Rollups, i.e. Optimistic Rollups and ZK-Rollups, many users prefer the latter as ZK-Rollups can also reduce transaction fees by packaging multiple off-chain transactions, but more importantly, they can calculate a validity proof through zero-knowledge proof and submit it to Ethereum to inherit the network’s security properties, without having to set up a challenge period like Optimistic Rollups.

The payment-only ZK-Rollups

That being said, in the early days, ZK-Rollups were mostly criticized for their incompatibility with EVM and smart contract functions. For instance, zkSync 1.0, the primary payment method for making Gitcoin donations, only supports basic functions such as transfer. Right now, existing ZK applications like dYdX are customized applications that do not support general-purpose usage, which makes them hard to develop and modify. In the meantime, since different ZK applications come with specific circuits, they fail to interact with each other, resulting in poor composability. As a result, there is an urgent need for ZK-Rollups that support Ethereum-based smart contracts. Moreover, compatibility with virtual machines that support zero-knowledge proof is the key. Fortunately, several ZK-Rollup projects have recently announced plans to support ZK-EVM’s mainnet or testnet. Today, we will dive into EVM, ZK-EVM, the major ZK-EVM projects and their differences.

What is EVM?

Functioning as the execution engine, EVM (Ethereum Virtual Machine) is the runtime environment for smart contracts on Ethereum. Developers write business logic (code) through high-level languages such as Solidity, and then the compiler compiles the code into a low-level bytecode. Next, the EVM parses the bytecode into machine-readable instructions (opcodes) and executes the corresponding command to modify the state of the system. EVM is a stack machine; it is a virtual machine based on a stack structure, so it needs to interact with stack, memory, and storage when executing opcodes.

For Ethereum, scaling protocols, and its public chain rivals, EVM has almost become synonymous with the Ethereum ecosystem. EVM represents the developers, applications, and tools of the Ethereum ecosystem. If a public chain does not support EVM, then it would have to train developers in its own ecosystem from scratch, and such developers would need to develop new applications and tools. Someone once compared Optimism and Arbitrum, the two giants of Optimistic Rollup, and pointed out that one is 99% EVM-compatible while the other is 100%. That said, in the white-hot Ethereum ecosystem, even a 1% difference results in clear advantages and disadvantages. This also shows that a project’s compatibility with EVM directly determines how compatible it is with the Ethereum ecosystem, and only EVM-compatible projects can enable seamless migration of existing Ethereum contracts, as well as smooth access to the many tools available in the Ethereum ecosystem.

The upcoming ZK-EVM

Despite the key role played by EVM in the Ethereum ecosystem, the development of ZK-EVM involves a very complex process. ZK-EVM projects are compatible with EVM and allow developers to generate ZK proofs. With such projects, developers can directly deploy and run Ethereum smart contracts without having to make any modifications. At the same time, the validity of calculation concerning the operation of programs can be proven through zero-knowledge. The developers of EVM did not account for ZK at the very beginning because when EVM was built, the ZK hadn’t made any breakthroughs and thus was not recognized by the mainstream. In 2016, Zcash adopted zk-SNARK, which marks the first adoption of a zero-knowledge proof algorithm. Some EVM operations are not ZK friendly. In other words, generating ZK proofs with EVM is hard or inefficient, or the ZK proofs generated are too large.

ZK development, well-known for its high threshold, requires expertise in cryptography, mathematics, as well as hardware, and ZK-EVM development is even more challenging as ZK-EVMs must be EVM-compatible and ZK-friendly at the same time. Fortunately, the field of ZK has witnessed increasing major breakthroughs over the past few years, and projects that include Starkware, zkSync 2.0, Polygon, and Scroll are all stepping up with the R&D of ZK-EVMs. In particular, the latter three projects have recently announced plans for testnet launch.

On July 19, Scroll released the pre-alpha testnet, where users can try out demo programs such as Uniswap (fork version) and Metamask. On July 20, Matter Labs announced that the EVM-compatible zkSync 2.0 will go live on the mainnet around November and released the roadmap. On the same day, Polygon announced that its ZK-EVM testnet will also be launched soon.

A comparison between different ZK-EVMs

Since there are no unified design specifications or criteria for ZK-EVM, each project team builds its solution by making tradeoffs between EVM compatibility and support for ZK from different angles. At the moment, most ZK-EVM projects adopt one of the following two approaches:

1．Language-level support: design customized EVM opcodes; build new virtual machines with different architectures by extracting ZK-friendly operations; transpile Solidity to new virtual machine opcodes through the compiler.
2．Bytecode-level support: support native EVM opcodes.

Projects that adopt the first approach include Starkware’s StarkNet and zkSync 2.0. StarkNet, which is Starkware’s general-purpose ZK-Rollup solution, can run any Ethereum dApp. Developers can use a compiler to compile Solidity to Cairo (StarkNet’s smart contract language) and then have the dApp deployed on its ZK-friendly VM. Similar to Starkware, zkSync 2.0 achieves ZK-EVM functions by developing two compiler front-ends: Yul and Zinc. Yul is an intermediate Solidity representation that can be compiled to bytecode for different backends, while Zinc is a Rust-based language for smart contracts and general-purpose zero-knowledge proof circuits. As they both are based on the open-source LLVM framework, they generate the most efficient zkEVM bytecode.

These projects are compatible with Solidity at the language level, and developers can deploy and run smart contracts written in Solidity by migration. However, their underlying VM architecture is not EVM. Strictly speaking, such projects use a type of zkVM. Furthermore, as they come with different underlying virtual machine commands, some existing development tools cannot be used directly. That said, these projects are ZK-friendly and can generate zero-knowledge proofs more efficiently.

Projects that adopt the second approach include Polygon ZK-EVM and Scroll. Polygon ZK-EVM is called uVM, which is a zkCircuit-optimized VM with tailor-made opcodes to optimize the EVM interpretation. The EVM bytecode is first compiled into “Micro opcode” and then executed in uVM. Planning to support all EVM opcodes, Polygon ZK-EVM is a ZK scaling solution that’s fully compatible with Ethereum: it works seamlessly with all existing smart contracts, developer tools, and wallets. Like Polygon, Scroll will design a circuit for each bytecode, which involves verifying each step performed by EVM, including loading bytecode, executing opcode, updating storage, etc.

In his blog post, Vitalik divides ZK-EVM into several types. In particular, Type 1 ZK-EVMs are developed directly on Ethereum, which involves an excessively complicated and inefficient development process, and the Ethereum Foundation is now looking into the matter. Type 2, Type 2.5 and Type 3 ZK-EVMs are equivalents of EVM. Scroll and Polygon Hermez are growing toward Type 2 or even Type 2.5 ZK-EVMs, but at the moment both projects should be considered Type 3. Type 4 ZK-EVMs, such as Starkware and zkSync, are compatible with high-level languages. The types are not unambiguously “better” or “worse” than other types, and there are no unified criteria for assessing ZK-EVMs. As Vitalik put it: “Theoretically, there is no need for Ethereum to standardize on a single ZK-EVM implementation for L1 use; different clients could use different proofs, so we continue to benefit from code redundancy.”

Conclusion

Since the codes are not yet open-source, the ZK-EVM designs are not categorically better or worse than other designs because we cannot compare their efficiency at this stage. Ethereum, the largest smart contract platform, boasts a strong ecosystem and great network influence. It should be noted that ZK-EVM is the holy grail of ZK-Rollups, and ZK-Rollups can only make good use of Ethereum’s ecosystem and clout through ZK-EVM, which allows them to inherit the security of Ethereum and gain easier access to a vibrant developer ecosystem, as well as time-tested codebases and tools. In early 2021, Vitalik said in a blog post that “in the short term, Optimistic Rollups are likely to win out for general-purpose EVM computation and ZK rollups are likely to win out for simple payments, exchange and other application-specific use cases, but in the medium to long term ZK rollups will win out in all use cases as ZK-SNARK technology improves.” As the testnet/mainnet of various ZK-EVM projects go live, the Layer 2 scaling of Ethereum is going to be fascinating in the near future.

Reference:
ZK-EVM overview-p1，https://drive.google.com/file/d/1dhZ5GtSK4sHCNcklGzNHfR-lSzplpD8J/view
https://vitalik.ca/general/2022/08/04/zkevm.html
https://starkware.co/starknet/
https://blog.matter-labs.io/zksync-2-0-hello-ethereum-ca48588de179
https://polygon.technology/solutions/polygon-ZK-EVM/
https://blog.hermez.io/introducing-hermez-ZK-EVM/