Overview on ZK Rollups and zkEVM
https://medium.com/neworderdao/an-overview-on-zk-rollups-and-zkevm-33ee5ffb2f6a
Last updated
https://medium.com/neworderdao/an-overview-on-zk-rollups-and-zkevm-33ee5ffb2f6a
Last updated
Zero knowledge (ZK) tech has positioned itself as the frontrunner for scaling blockchains over the past couple of years. As scaling solutions mature, we’ve seen many ZK adaptations reveal themselves, but how these solutions work can be confusing to many. In this post we hope to demystify ZK tech so that readers can better understand the future of our industry.
A rollup is an L2 scaling solution that operates off-chain from the main L1 (in most cases Ethereum, but soon also on Celestia). This solution performs transactions off-chain, which means it doesn’t have to compete for precious blockspace on the L1. After executing the transactions, it will send a batch of transaction data (Optimistic) or proof of execution (ZK) to the L1 where it will be settled. Because of this, the layer 2 scaling solutions are secured by the same layer 1 security measures, since the data availability (DA) layer or settlement layer acts as the source of truth for the rollup.
ZK Rollups in particular are a solution that uses validity proofs to scale computation: each batch of transactions comes with a cryptographic proof (SNARKs, Kimchi, STARKs, etc) that is verified by an Ethereum smart contract — often referred to as an L2 bridge contract. This way, every single transaction is fully verified by all Ethereum full nodes before a block is finalized.
zkEVM is a virtual machine that executes EVM smart contracts in a way that is compatible with ZKproof computation. There are various types of zk(E)VMs, so we must distinguish between these types of solutions to a “zkEVM”:
EVM-compatibility = Solidity/Vyper-level compatibility
EVM-equivalence = EVM bytecode-level compatibility + Ethereum execution client (Geth etc)
Full-scale zkEVM = EVM specification-level compatibility
What they all have in common is that they add in-circuit support of EVM in their own way with various tradeoffs.
The way the these solutions work is relatively simple:
Note: Smart contract code written in high-level languages (such as Solidity/Vyper) needs to be compiled into EVM bytecode to get deployed to the Ethereum blockchain.
For EVM-compatibility, you transpile Solidity/Vyper code into the VM’s bytecode and then prove the validity of the execution trace in-circuit.
For EVM-equivalence, you transpile or interpret the EVM bytecode into your VM’s bytecode and then prove the validity of the execution trace in-circuit.
For a full-scale zkEVM, you prove the validity of the EVM execution trace in-circuit.
With most existing zkEVMs, such as Hermez and ZKSync, they run different bytecode through an interpreter/compiler that mirrors all the functions of EVM bytecode but is not complete EVM equivalent bytecode. Thus, EVM-compatible ZK rollups compile Solidity/Vyper into a bytecode targeting a custom VM rather than EVM.
So why does this matter? It matters because of EVM tooling compatibility and on a security trade-off level since adding extra layers of complexity adds new vulnerabilities.
With this in mind, let’s utilize Vitalik’s diagram that plots in the various types of zkEVMs and plugs in the existing solutions:
The core part of Scroll is their zkEVM, which is used to prove the correctness of EVM execution on their ZK rollup. They have been building it in tandem with the Privacy and Scaling Explorations (PSE) group at the Ethereum Foundation (who are also working on a ZK-EVM that strives to be fully Ethereum-equivalent).
It has two main focuses:
Design a circuit to link the bytecode with the real execution trace.
Design circuits for each opcode (prove and write that computations in each opcode are correct).
For Scroll this is the most important part — to prove each opcode in the execution trace is correct and consistent. This means that Scroll’s focus is on building an EVM opcode for opcode zkEVM. This route has the benefit of making it extremely compatible with Ethereum and thus extremely secure, but also adds a damper on its performance — especially in regards to the proving time of their ZK proofs.
Scroll’s zkEVM will be able to prove the correctness of an execution trace extracted from Geth (Ethereum execution client in Go — widely used). Their approach is thus closely aligned with Ethereum. Because of this Ethereum alignment, it enables them to minimize additional attack surfaces (by reusing the code and sticking as closely as possible to the specification of Ethereum) while maximizing compatibility with existing tooling.
Polygon’s design is unique since they use an interpreter that translates EVM opcodes into their own assembly language called zkASM, which is then ZK verified. This means that it is EVM-compatible, however it uses internal logic to verify EVM code.
Hermez’s approach introduces a few extra steps when executing EVM bytecode, which does add quite a surface where there could be vulnerabilities and results in it being less compatible with existing tooling than other solutions. Though, this approach is a lot more prover friendly and speeds up the proving of ZK proofs significantly.
This means that they minimize prover overhead while being somewhat compatible with Ethereum by making a few sacrifices. Thus, Hermez will be compatible with most EVM applications and only require some re-writing for a few outliers that use things such as pre-compiles which Hermez doesn’t inhabit.
ZKSync’s and Polygon Hermez’s approach to building their zkVM is quite similar. They both aim for EVM-Compatibility, which is Solidity/Vyper compatibility.
Instead of Scroll’s approach where you take your Solidity smart contracts and compile them into EVM Bytecode, you instead take your Solidity code and compile it into zkSync Bytecode. The bytecode of this virtual machine is a different bytecode. For a developer this doesn’t make much of a difference, however, it does add some hurdles and possible vulnerabilities in the system, same as with Hermez. Regardless, you still just take your code, compile it, and get some bytecode which is then deployable. This bytecode is optimized to be run in ZK systems. This means that ZKSync supports solidity at the source code level.
This has the advantage of causing very fast ZKP proving times as the specific language/VM in question is very ZK friendly and therefore you can minimize overhead and increase performance.
ZKSync is also working on a validium solution for their DA, which is called ZKPorter: that holds calldata and provides data availability — essential transaction data needed to reconstruct state off-chain rather than on Ethereum. Instead, the data remains available using PoS that signs off on signatures, where stakers are zkSync token holders.
They are the closest to mainnet launch, which will happen in the next few months.
Nethermind’s Warp project is building a compiler from Solidity to Starkware’s Cairo, which will turn StarkNet into an “EVM-compatible” system through compiling. However, it’s worth mentioning that for now Starkware uses a specialized zkVM with its own domain-specific language (Cairo) that is friendly to building applications on zkVMs.
It’s clear that regardless of which zkEVM you find most interesting, they all make various trade-offs for gains whether that’s in regards to compatibility or performance. Some of them value having more EVM compatibility than performance, while others prefer performance over compatibility.
At the end of the day, it’s up to the developers of applications to decide on what is right for their specific application. As such, there’s a place for several different types of solutions to the same problem, which is making zkEVMs that are fit for a specific product type. This means that in all likelihood you’ll see several ZK Rollups succeed in their specific market fit, just like how we’ve seen specific L1s find their own market fit.
