A Comparison of ZK Rollups

I put together a brief beginner’s overview of ZK rollups on Ethereum as of fall 2022.

Brief Overview of ZK Rollup Mechanics

ZK rollups are scaling solutions. The goal is to derive economic security from Ethereum, but scale throughput by moving execution off-chain. The set-up works as follows:

• Users submit transactions on the rollup, which runs an independent VM.
• A sequencer executes the transactions and batches them into blocks.
• A prover generates a ZK proof for the block, which is used to check the state transitions in the rollup have been correctly applied.
• A smart contract on Ethereum verifies the ZK proof, providing L1 finality for users.

Design Choices

Here I describe several key ZK rollup design choices.

Data Availability (DA)

ZK rollups move execution off-chain, but typically rely on the L1 for DA. Alongside the ZK proof, they publish a small amount of data for each transaction on Ethereum via calldata. DA allows anyone to verify the state of the rollup.

However, DA gas costs increase with L1 blockspace demand. Further, the rollup is ultimately bound by the data capacity of Ethereum, limiting long-term scalability.

So, ZK rollups are often designed as volitions, which contain: 1) a rollup with on-chain DA and 2) a validium with off-chain DA. In a volition, ZK proofs are published to Ethereum, but users choose between expensive, more secure rollup settlement or cheap, less secure validium settlement. One way to improve off-chain DA is with a DA committee, a group of trusted parties who attest to DA. An even stronger alternative is to rely on a POS DAC, where anyone can join as a “DA validator.”

STARKs vs SNARKs

The choice of ZK proof system is crucial. SNARKs are based on elliptic curve primitives, while STARKs are built on collision-resistant hash functions. The nitty-gritty technical differences have important implications for rollups.

• Decentralization: SNARKs rely on an set-up process with a small group of trust entities in order to generate some randomness necessary for initializing the proof system. STARKs require no such trust assumptions. Recently, there have been attempts to move SNARKs towards a “transparent” set-up.
• Security: In theory, advances in quantum computing could break the computational hardness assumptions of SNARKs.
• Scalability: SNARK proofs are smaller, consume less gas and are faster to verify. A SNARK proof for a single transaction may be around 200 bytes, while a STARK proof is closer to 45kB. However, SNARK proof generation is more expensive. Further, SNARK proof costs scale quickly with the complexity of the underlying circuits. So, in the long-run, STARKs are more scalable as throughput (and hence proof complexity) on rollups grows.
• Developer Experience: STARKs are a relatively new technology introduced in 2018, while SNARKs have been around since 2012. There is less tooling to support developers in the STARKs world. Further, it is much easier to make SNARKs EVM compatible.

Below is a summary from Vitalik’s blog of where popular ZK proof systems lie on the the security vs proof size trade-off:

Escape Hatch

Most ZK-rollups are bootstrapped with centralized sequencers/provers (ZK proofs are computationally intensive and often require specialized hardware), which creates the risk of censorship. Rollups are committed to decentralization, but the process will take a while.

In the meantime, rollups can provide a weak liveness guarantee by implementing an escape hatch. This allows users to withdraw even if the sequencer/prover stops operating by sending a “forced transaction” to the rollup’s L1 smart contract.

Upgradability

As ZK proof systems evolve, teams want to be able to upgrade their L1 smart contracts. So while the contracts are mostly controlled by multisigs at the moment, teams can improve security guarantees by implementing: 1) pmandatory timelocks, 2) mandatory timelocks which can be reduced with a majority vote by a Security Council made up of trusted community members.

zkEVM

ZK rollup teams have quite a bit of flexibility in their zkEVM designs.

Making the VM as compatible as possible with Ethereum is great for developer experience. Engineers could rely on standards that have been refined in the Ethereum ecosystem, including DSLs (Solidity/Vyper), token standards (ERC20/ERC721) and block explorers. In an ideal world, developers could simply copypasta smart contracts from Ethereum onto ZK rollups.

However, such backwards compatibility comes at the expense of longer proof times. Several of Ethereum’s cryptographic primitives, including Keccak and RLP-based Merkle Patricia tree, require expensive ZK computation. Supporting such complex ZK proofs may also require specialized proving hardware at the expense of decentralization.

Below is a summary of the zkEVM design space taken from Vitalik’s blog, where Type 1 is fully Ethereum-equivalent and Type 4 is high-level language equivalent:

Current Projects

The table below summarizes the design choices made by players in the ZK rollup space (taking into consideration recent zkEVM announcements).

zkSync

• Short-term Scalability: Of the live rollups, zkSync seems best positioned to support high TPS activity. Specifically, zkPorter is offered as an off-chain DA solution which is supposed to support 10x TPS and interoperate with their on-chain DA rollup.
• Developer Experience: Although only a high-level language equivalent, zkSync’s zkEVM solution compiles Solidity/Vyper to Yul IR before going to LLVM IR. Down the line, developers should be able to write smart contracts in other languages like Rust or C that can compile to LLVM IR.

Starknet

• Long-term Scalability: As one of the only projects with a pure STARKs based approach, Starknet could win the long-term scalability battle, leveraging favorable proof generation times for complex circuits.
• Decentralization: Given the closed-source prover, DAC approach to the Validium and lack of escape mechanism, Starknet seems a bit more centralized, for the time being.
• Developer Experience: Developers will be required to use Starkware’s DSL programming language Cairo, which is not EVM compatible. Although Nevermind’s Wrap project is building a Solidity $\rightarrow$ Cairo transpiler.

Polygon zkEVM

• Many unknowns given it is not live.
• Decentralization: The only project committed to launching with a decentralized sequencer/prover network (based on proof-of-efficiency).
• Developer Experience: Attempting to build a Type 2 zkEVM, which achieves perfect equivalence at the VM level, though the data structures that hold Ethereum state may be different. Ethereum execution clients may not work, but most developer tooling should carry over.
• Scalability: A Type 2 zkEVM sacrifices performance for backwards compatibility. It cannot eliminate all the ZK-unfriendly parts of the Ethereum stack.

Scroll

• Many unknowns given it is not live.
• Developer Experience: Want to build the most backwards compatible VM.
• Scalability: The Type 2 zkEVM plus on-chain DA may limit throughput and proof generation times.

Aztec

• Privacy: Most Aztec use is limited to the DEX zk.money, but is the only project building privacy directly into its rollup.
• Developer Experience: All smart contracts have to be written in Noir, which is fairly new and lacks tooling.