ZK rollups, also called validity rollups, are a revolutionary way to scale Ethereum by allowing transactions to be processed off-chain and consolidated onto the main chain in a single, compressed transaction. This process increases transaction throughput and reduces fees while preserving the security and decentralization of the main chain.
One of the standout features of zk rollups is their utilization of zero-knowledge proofs (ZKPs), a type of cryptographic proof that enables one party (the prover) to demonstrate to another party (the verifier) that a statement is true without divulging any additional information. In the context of zk rollups, ZKPs ensure the integrity of off-chain transactions by allowing the prover to demonstrate the validity of the transaction batch without revealing the specific details of the transactions and without requiring the verifier to check all transactions before accepting the new state.
Compared to optimistic rollups, zk-rollups offer a superior level of security because they don't introduce additional trust assumptions on top of Ethereum and rely on Ethereum and mathematics for security. Optimistic rollups rely on game theory and the 1 of n honest node assumption, meaning that for every batch of transactions, there will always be at least one honest node that can challenge malicious transactions. On the other hand, zk-rollups’ operators, also known as sequencers and provers, don’t have any opportunity to be evil users' funds since their role is ‘simply’ to collect transactions in batches and generate zk proof, while users' funds remain on Ethereum L1, and Ethereum is ultimately responsible for verifying the zk proof submitted by the L2 and finalizing the underlying transactions. Validity proof is generated through a complicated polynomial computation with the state data. If the state data is invalid, the validity proof cannot be produced. The verifier on L1 will input the state data to verify the validity proof, so if the state data is changed by the prover, the verifier won’t accept the proof. Zk rollups have two other advantages compared to optimistic rollups. First, they enable much faster finality since transactions are final on Ethereum as soon as the validity proof is provided, while optimistic rollups need to wait for one week to be sure no challenge is made and therefore consider the transactions legit and final. Secondly, zk rollups are more efficient regarding data availability, posting data of the transactions on Ethereum L1. While for zk rollups (e.g. zkSync Era), posting the state difference is enough since there is no need to reconstruct all transactions to verify them, optimistic rollups need to post complete data to enable anyone to reconstruct transactions and eventually challenge them. Consequently, zk rollups use a lot less data bandwidth on Ethereum (a scarce resource that all rollups need to share, regardless of which system they use to execute transactions, including zk circuits), enabling even cheaper fees (even 0 fees) for users.
Zk-rollups are considered the ultimate solution for scalability on Ethereum, but implementing them is difficult due to the Ethereum Virtual Machine (EVM) not being designed to support zk circuits. To address this issue, many organizations and researchers have tried to create a rollup-supporting virtual machine called zkEVM, which can run smart contracts in a way that is compatible with zero-knowledge-proof computation. The most comprehensive analysis of these various attempts can be found in a blog post by Vitalik, where he outlines four different types of zkEVMs based on their compatibility with Ethereum. It's important to note that the more closely a zkEVM matches the functionality of Ethereum, the slower and more expensive it becomes to generate zk proofs. On the other hand, the more a blockchain or rollup aligns with Ethereum's specifications and standards, the easier it is for developers to build on top of it and integrate with the Ethereum ecosystem. In summary, blockchains that are highly compatible with Ethereum may have a competitive advantage.
Type 1: fully Ethereum-equivalent zk rollups reproduce Ethereum precisely in all its parts, including hashes, state trees, transaction trees, precompiles, or any other in-consensus logic. So far, no zkEVM can achieve Ethereum equivalence.
Type 2: fully EVM-equivalent zk rollups strive to be precisely EVM-equivalent but not quite Ethereum-equivalent. They are fully compatible with existing applications but make some minor modifications to Ethereum to make development more accessible and to generate proofs faster. Scroll and zkEVM Polygon in theory; in practice, they currently belong to group 3.
Type 3: almost EVM-equivalent, sacrifice further elements and equivalence to make proof generation even faster. Polygon zkEVM and Scroll currently belong to this group. This category is usually a stepping stone to Type 2.
Type 4: high-level-language equivalent, meaning they both accept smart contracts written in Solidity, but then they transpile it to another custom, zk-friendly language. zkSync and StarkNet belong to this category, although zkSync may add compatibility for EVM bytecode over time and eventually move to a higher type.
While Vitalilk’s proposed categorization is currently the most popular and impartial one, others have been put forward. Immutable, the L2 built on StarkWare and specialized in NFTs offers the following helpful categorization in one of its blog posts:
These categories, compared to Vitalik’s grouping, are more clearly based on the specific level of the stack (high-level language, bytecode, or runtime environment) where the existing zkEVMs reach their compatibility or equivalence with Ethereum.
Solidity-compatible. Compatibility with Ethereum happens at the high-language level, Solidity, meaning that developers can keep writing smart contracts with the language they are accustomed to on Ethereum. However, these rollups immediately convert Solidity into their intermediate representation, which is then compiled in their bytecode and executed in their custom environments. Specifically, these L2s use a transpiler that transforms Solidity code into the custom VM’s readable code (Cairo for StarkWare, LLVM-IR for zkSync). Some Solidity features are not supported by these transpilers, meaning that devs might have to adjust their smart contracts. Examples: zkSync and StarkNet.
EVM-compatible. These rollups are EVM-compatible from the language perspective, but they have their own bytecode, which means that Solidity can be compiled directly into the EVM opcode/bytecode, which is then converted into custom bytecode before being executed in the custom VM runtime. In practice, these rollups are compatible with most Ethereum programs, but there will be some applications that would need to be rewritten. Also, some bytecode functionalities, such as precompiles, are not supported. Example: Polygon zkEVM.
EVM-equivalent: These rollups create a zk verifying circuit that can read EVM opcode and bytecode directly, although the VM itself is not the same as the EVM. These rollups are fully compatible with existing applications but can make some minor modifications to Ethereum to make development easier and proof generation faster. Example: Scroll.
Ethereum-equivalent. This means replicating Ethereum in all its components, similar to what Polygon has done. So far, no zk rollup fits this category.
Integrating this framework with the one proposed by Immutable and adding some other information, the following chart can be outlined, which highlights some design differences and similarities to consider when comparing different implementations of zkEVM before any performance data is available:
zkSync 2.0, rebranded zkSync Era just before its mainnet release, is a scaling solution for the Ethereum network fully compatible with the Solidity programming language. With zkSync, users can choose between two types of data availability: zkSync Rollup and zkSync Porter. The former posts data directly on Ethereum, making it as secure as Ethereum L1, while the latter stores data off-chain, resulting in faster and cheaper transactions but with a lower level of security.
zkSync is EVM-compatible as it can convert smart contract code written in Solidity into Yul and Yul into LLVM-IR, which is then recompiled into a custom, circuit-compatible bytecode set designed specifically for zkSync's EVM. While this requires intermediate steps, it also allows for additional non-EVM features, such as Account Abstraction. Moreover, Matter Labs, the company behind zkSync, plans to make it gradually more compatible with Ethereum toolkits and is preparing to release its first layer-3 prototype, zkSync Opportunity, on testnet as part of its ambition in the scalability and interoperability space.
At the time of writing, zkSync Era has just launched, and it’s too early to comment on its performance. zkSync 1.0 (now zkSync Lite), which only supports simple transactions, is one of the largest zk rollups in terms of TVL, with over $83M locked and over 19M total transactions, compared to just over $19M in TVL and 4M total transactions on StarkNet.
StarkNet is a type 4/Solidity-compatible zk-rollup that stands out from the other implementations as it uses a different type of zero-knowledge proof called STARKs (Scalable Transparent ARgument of Knowledge) to ensure the integrity of off-chain transactions. STARKs are considered more efficient and scalable than SNARKs, but they may require a more complex technical setup.
Polygon zkEVM is a zk-rollup that uses the custom language zkASM to interpret zkEVM code and verify the execution of smart contracts in a non-EVM runtime environment. The project, which began in 2021 with the acquisition of Hermez Network for $250 million, has been working to develop a solution that combines the security of STARKs and the efficiency of SNARKs to create an EVM-equivalent system. While STARK is used to generate proofs of validity for the state of the transactions, SNARK is used to assess the correctness of STARK proofs. This combination of solutions allows for security as well as speed and low transaction fees.
In July 2022, Polygon announced the rebranding of Polygon Hermez to Polygon zkEVM, which just launched at the time of writing. The latest testnet version of Polygon zkEVM introduced recursion, allowing for using one ZK validity proof to validate a batch of other ZK proofs, each of which can, in turn, validate multiple transactions. This feature is made possible by Plonky2, a recursive SNARK 100x faster than existing alternatives and natively compatible with Ethereum.
In addition to Polygon zkEVM, Polygon has also developed Polygon Avail, a blockchain optimized for data availability only. The network will be permissionless, allowing anyone to join as a validator, and, unlike existing Data Availability Committees (DACs), it will have hundreds of nodes acting in concert to provide network security. Avail will work in pairs with Polygon Hermez (Rollup) to post state data from Hermez instead of on Ethereum, providing a solution between Validium and Rollup.
While some experts have pointed out that the specifications provided by Polygon would be better described as EVM-compatible, the team is working towards creating the first fully EVM-equivalent solution.
Scroll is an EVM-equivalent zk-rollup developed by the Scroll team in collaboration with PSE (Privacy and Scaling Explorations) group at the Ethereum Foundation. It is currently in its Pre-Alpha testnet phase and aims to be fully compatible with the Ethereum Virtual Machine (EVM) at the bytecode level. This means developers can use any EVM-compatible language to create smart contracts and deploy them on Scroll. Although Scroll does not currently support EVM opcode, it plans to do so in the future by building a 1:1 opcode mapping. This will allow for the direct acceptance of EVM opcode without needing a compiler.
Scroll's architecture comprises a centralized sequencing node and a decentralized proving network. The centralized sequencer nodes are responsible for sequencing transactions, creating blocks, and submitting transaction data as calldata to the Rollup contract on Ethereum for data availability. Scroll plans to gradually decentralize the sequencing nodes. On the other hand, a decentralized prover, known as a Roller, generates the proof and publishes it to the L1 network, taking advantage of distributed computation power. Rollers are chosen randomly, and multiple proofs for different blocks can be generated in parallel on different Rollers to increase speed.
*While currently only supporting on-chain data availability, Scroll’s original design also included the Validium mode.
Both Scroll and Polygon adopted a bytecode-level approach in building their zkEVMs.
This approach eliminates the transpiler step altogether, meaning these zkEVMs don’t convert Solidity code into a different language before it gets compiled and interpreted. However, while Scroll’s only difference with Ethereum is the runtime environment, Polygon creates a custom VM with optimized performance, then converts EVM bytecode into bytecode for that VM. Unlike Scroll, Polygon’s runtime (the “zkExecutor”) runs tailor-made “zkASM’’ opcodes (Micro opcode in the image) rather than EVM opcodes to optimize the EVM interpretation (i.e., reduce the number of constraints vs. proving the EVM directly). Polygon zkEVM won’t probably be compatible with 100% of the Solidity code, tooling, and applications, although most of it will.
While these are the most notable projects focusing on launching general-purpose zkEVM implementations, zk technology has been put into practice by other application-specific projects.
Looping is an application-specific zk-rollup, used to power a decentralized exchange (DEX) protocol. Loopring is also a platform using zk proofs to enable anyone to build a dex. Immutable X is another application-specific zk-rollup built on StarkWare for NFT trading and gaming. Aztec is a privacy-first zk-rollup on Ethereum that encrypt data to keep them transparent and available for the protocol while maintaining privacy for the users. Among other things, Aztec invented the PLONK proof system, also used by zkSync and others.
Immutable X, Sorare, rhino.fi, ApeX, dYdX are some of the protocols built on StarkEx. In projects using StarkEx ZK-Rollup, data is sent as calldata to Ethereum and published on-chain. In Validium mode, data is stored off-chain, with only a hash stored on-chain. While Rollup mode ensures more security (one can recreate the ledger's state by only interacting with the Ethereum blockchain), Validium mode can ensure lower cost and more privacy.
Overall, while zkSync Lite is the largest zk rollup, StarkWare has the largest ecosystem, and including projects built on StarkEx, it has the most significant amount of TVL and market share.
In summary, zk-rollups are a promising solution for scaling blockchain networks, offering various implementations to meet different needs and requirements. While some categorizations exist, it is worth noting that they are approximate interpretations, and a lack of consensus on definitions and technical distinctions remains. As Scroll co-founder Sandy Peng admitted: “There isn't a clear consensus on any definitions. [Scroll’s] whole research team tends to gravitate towards a certain narrative or certain view on things, but it's by no means a definitive thing. There isn't even a consensus within our research team on what everything means.”
Despite this, some common trends have emerged among zk rollup implementations. Firstly, they all seem to adopt a hybrid approach regarding data availability, offering one traditional rollup with data posted on-chain and one validium solution with data posted off-chain. Avail lead Anurag Arjun told Blockworks: “You will see every rollup — at least in my opinion — will have a rollup version and a validium version.”
Secondly, they mostly avoided pure open-source code until they were live, also due to intense competition from optimistic rollups like Arbitrum and Optimism. Zk-rollups promise to be more efficient, but they are technically harder to implement. Moreover, as it’s clear from the table above, optimistic rollups and especially Arbitrum, are benefiting from the first-mover advantage and are leading the market both in terms of applications and in terms of volumes and market share. If proven successful, optimistic rollups could integrate the validity-proof model and combine it with their already established user bases (for example, Optimism’s upgrade Bedrock may introduce validity proofs).
Additionally, while all implementations started off with a centralized set of sequencers to make things more efficient, they all committed to gradually decentralizing it to address concerns about centralization. Interestingly, decentralizing sequencers will likely require economic incentives in the form of a native token, so this step is expected from all mentioned projects.
Finally, the astonishing results achieved by these zkEVM implementations in the past year have spurred a renewed interest in zk technology as a whole, with companies focusing on various aspects, including developing new zk hardware to improve proof generation speed.
While there are challenges to be addressed, the progress made in zkEVM design in just over a year is noteworthy, and 2023 is likely to be the decisive year for this technology.