The Future of Blockchain Scalability: Part 2 - A Deep Dive into Zk-Rollups Technology
This guide provides an in-depth analysis of Zk-Rollups, their types based on EVM compatibility, and the improvements they offer compared to traditional Layer 1 networks.
Abstract: Zk-Rollups are a Layer 2 scaling solution that leverages zero-knowledge proofs to bundle multiple transactions into a single proof, reducing on-chain data and computational requirements. This guide provides an in-depth analysis of Zk-Rollups, their types based on EVM compatibility, and the improvements they offer compared to traditional Layer 1 networks. As blockchain networks continue to evolve, Zk-Rollups will play an increasingly important role in addressing the scalability challenges and promoting the growth of decentralized applications and services.
Section 1: Introduction
Section 2: What are Zk-Rollups
Section 3: The Different Types of Zk-EVMs
Section 4: The Anatomy of Zk-Rollups
Section 5: The Zk-Rollup Lifecycle
Section 6: zkSTARK vs zkSNARK
Section 7: Zk-Rollups Improvements Over Traditional Layer 1 Network
Section 8: Conclusion
Introduction
Zk-Rollups (ZKR) are a Layer 2 scaling solution built on top of existing Layer 1 networks such as Ethereum, designed to enhance scalability, security, and efficiency.
This guide provides an in-depth exploration of Zk-Rollups, the different types, and the improvements they offer compared to traditional Layer 1 networks. In case you missed Part 1 - The Evolution, we delved into the historical context and key developments, exploring subjects such as Bulletproofs and Plasma technology.
What are Zk-Rollups
Zk-Rollups are a Layer 2 scaling solution that bundles multiple transactions into a single proof called a "rollup."
Zk-Rollups utilize zero-knowledge proofs (ZKPs), a cryptographic technique that allows a prover to demonstrate the veracity of a statement without revealing any underlying information about it.
The fundamental concept behind rollups is aggregating multiple transactions into a single hash, rather than recording each transaction individually on the blockchain. This method significantly enhances scalability while maintaining the security and decentralization of the network.
ZKR rely on intricate mathematical computations to generate cryptographic proofs for transaction packets, which ensure the proper execution of all transactions within the packet. Zero-Knowledge Proofs (ZKPs) can hash transaction data, but they cannot independently interact with smart contracts. This limitation arises from the separate calculations performed for each block, as state transitions strictly follow valid states. Consequently, compilers or alternative programming languages must be employed to achieve EVM compatibility.
Furthermore, Zk-rollups exhibit limited EVM compatibility due to their unique approach to mapping Layer 2 (L2) wallet addresses to Layer 1 (L1) wallet addresses through a single set of private keys. To minimize transaction sizes, Zk-rollups represent account indices, which occupy less space than full addresses. This approach allows for the utilization of 3 bytes of memory, as opposed to 20 bytes.
These nuances result in Zk-Rollups exhibiting distinct characteristics in terms of proof generation and EVM compatibility.
Vitalik Buterin proposed four categories of Zk Rollups in his 2022 article, "The different types of ZK-EVMs" based on their EVM compatibility. The categorization has been slightly modified to reflect the current landscape and facilitate comprehension.
ZK-EVM is a virtual machine that executes smart contracts in a way that is compatible with zero-disclosure computing. This is the key to creating an EVM-compatible ZK Rollup, retaining the battle-tested code and knowledge gained from years of working with Solidity.The Different Types of ZK-EVMs
Zk-Rollups can be classified into four categories based on their compatibility with the Ethereum Virtual Machine (EVM).
ZK-EVM (Zero-Knowledge Ethereum Virtual Machine) refers to the incorporation of zero-knowledge proof techniques into the Ethereum Virtual Machine (EVM). It allows smart contracts to be executed in a zero-knowledge environment, providing privacy and scalability benefits.
Type 1 - Full Ethereum equivalence: Logic, hashes, architecture, and clients remain unchanged, with no compiler usage. Examples include Taiko. Solidity/Vyper code can be translated into virtual machine byte-code and verified within the schema to ensure the execution trace is valid. ASICs can be employed for proof generation.
Type 2 - EVM equivalence, but not native geth compatibility: Minor differences in block structure, receipts, state tree, and hash functions exist. EVM applications generally require no significant changes, but some modifications in the executing clients may be necessary. Scroll is an example of a Type 2 Zk-rollup.
Type 3 - Partial EVM equivalence: Differences in contract code and stack processing may necessitate the rewriting of some applications. Internal logic can be used to verify EVM code, with most applications being compatible. zkSync is an example of a Type 3 Zk-rollup.
Type 4 - No direct EVM compatibility: Applications run using native language compilers for Zk-compatible virtual machines (zkVM). The prover natively processes the code with high efficiency. However, native languages for zkVM are challenging for developers, and compilers often struggle. Starknet exemplifies a Type 4 Zk-rollup.
The Anatomy of Zk-Rollups
There are several components involved in Zk-Rollups, including nodes, smart contracts, and other key participants. It is essential to understand that the lifecycle of a transaction within a Zk-Rollup system involves the interaction of various elements, including validators or full nodes.
Some researchers and projects might inadvertently overlook the role of validators or full nodes in their descriptions, potentially leading to misconceptions about the storage of Layer 2 history on the Ethereum blockchain. For example, zkSync's documentation may cause confusion by using the terms "validator" and "sequencer" interchangeably. It is crucial to note that even recursive blockchains, such as Mina, maintain full nodes that store the complete blockchain history.
To avoid misunderstandings, it is necessary to distinguish between the different components and their roles in the Zk-Rollup ecosystem:
Validators/Full Nodes: Even though transaction information is stored on the Ethereum network, Zk-rollups also have full nodes. These full nodes maintain the entire state of the blockchain and enable the use of JSON-RPC API functionality. Starknet uses Equilibrium's Pathfinder (with much of Starknet's backend developed by third-party teams), while zkSync has zkPorter, ensuring data availability for crucial transaction data needed to recover state. However, it is important to note that in Starknet, transactions are currently processed via the sequencer, which adds confusion to understanding the transaction lifecycle in ZK-Rollups.
Sequencers: Sequencers play a vital role in organizing transactions within a Zk-Rollup. They receive and aggregate individual transactions from users, batching them together in a specific order to create a single proof. The sequencer's role is critical for maintaining consistency within the Zk-Rollup and ensuring that transaction data can be efficiently processed and verified.
Confusion often arises regarding sequencers, as developers sometimes refer to them as "validators." This leads to the incorrect assumption that sequencers are responsible for data storage. In reality, sequencers arrange transactions and generate blocks, which are then provided to the prover for proof generation. Sequencers take transaction batches and generate a list of changes resulting from the transactions (storage changes, residuals, etc.), along with a proof that confirms the network state will change if the transactions succeed.
At the moment, sequencers are centralized due to their sensitive role in the consensus process. All Zk-protocols aim to transition to a decentralized sequencer model eventually.Provers: Provers, sometimes referred to as aggregators, generate the zero-knowledge proofs that validate transaction bundles within a Zk-Rollup. They use cryptographic tools like zk-SNARKs or zk-STARKs to produce a proof that attests to the validity of the transaction data. Once the proof has been generated, it is submitted to the validators for verification.
Provers require significant power for hashing headers. In theory, anyone who hashes their means in a smart contract can run a prover (zkSync and Starkware have mentioned this). Provers can operate as part of zkEVM or as an independent entity (as in the case of Zk-Rollups with type 1 and 2 EVM compatibility).
A prover working as part of zkEVM does not execute bytecode but generates proofs that confirm the network state's correctness after executing smart contracts. Repeaters produce a succinct, non-interactive, non-public knowledge argument that compares the blockchain state before and after each transaction (e.g., wallet balance). This is then sent to the underlying (L1) network as a verifiable hash. In some instances, when users send a transaction, the protocol might wait for the block to fill before generating a proof.Verifiers: The verifiers are smart contracts residing on L1 (Ethereum) that checks ZK proofs and records changes to the contract without considering addresses and balance changes. Following this, the state is updated to its final state. They enable users to deposit, withdraw, and interact with the Layer 2 state. These smart contracts also handle the on-chain commitment of Zk-Rollup proofs, ensuring that the main chain's state is updated to reflect the latest Zk-Rollup transactions.
Another crucial aspect of operation and differences between Zk-rollups is the trusted setup. The trusted setup is the process of creating a Common Reference String (CRS), which informs proving and verifying users that they are using the same statement. CRS is a piece of data used each time the cryptographic protocol runs. To create this data, secret information is required; "trust" arises because an individual or group must create these secrets, use them to generate the data, then publish the data and discard the secrets.
The Zk-Rollup Lifecycle
The Zk-Rollup transaction lifecycle consists of several stages, including deposit, aggregation, proof generation, verification, and withdrawal.
Deposit: Users deposit their assets (e.g., tokens or cryptocurrency) into the Zk-Rollup smart contract on the main chain, effectively "locking" them for use within the Zk-Rollup ecosystem.
Aggregation: Sequencers receive and aggregate individual transactions from users, batching them together in a specific order.
Proof Generation: Provers generate a zero-knowledge proof that attests to the validity of the aggregated transactions, using cryptographic tools like zk-SNARKs or zk-STARKs.
Verification: Validators verify the zero-knowledge proof submitted by the provers, ensuring its validity and consistency with the main chain's state.
On-Chain Commitment: Once verified, the proof, along with a new state root, is committed to the main chain through the Zk-Rollup smart contract. This commitment updates the global state of the Zk-Rollup without revealing the details of individual transactions.
Withdrawal: Users can withdraw their assets from the Zk-Rollup by submitting a withdrawal request. The assets are then unlocked and transferred back to the user's main chain address.
zkSTARK vs zkSNARK
Proofs (zk-SNARKs, zk-STARKs) enable the verification of a large number of transactions in a single batch, rather than checking each transaction individually. This process is faster and more cost-effective. The smaller the proof, the lower the gas consumption and the higher the speed.
zk-SNARKs
Succinctness: zk-SNARK proofs are relatively small in size and can be verified quickly, which is beneficial for blockchain scalability.
Non-interactivity: zk-SNARKs do not require interaction between the prover and verifier, making them efficient for blockchain implementations.
Soundness: zk-SNARKs are computationally sound, meaning that a malicious prover cannot convince a verifier of a false statement without being detected.
However, zk-SNARKs have some drawbacks:
Trusted setup: zk-SNARKs require a trusted setup phase where a common reference string is generated. This phase demands trust, as the setup's initial participants must discard secret information. If the secret is not discarded, it could be used to create false proofs.
Lack of transparency: zk-SNARKs rely on a complex mathematical setup that obscures the underlying cryptographic operations, making them less transparent than other zero-knowledge proof systems.
zk-STARKs
Transparency: zk-STARKs do not require a trusted setup, making them more transparent and secure compared to zk-SNARKs. They rely on cryptographic assumptions that are widely believed to be secure even against quantum adversaries.
Scalability: zk-STARK proofs are highly scalable, with proof size and verification time growing only logarithmically with the computation size.
Post-quantum security: zk-STARKs are considered post-quantum secure due to their reliance on hash functions and other cryptographic primitives that are resistant to quantum attacks.
However, zk-STARKs come with their own set of drawbacks:
Larger proof sizes: zk-STARK proofs are generally larger than zk-SNARK proofs, which may be a disadvantage in certain use cases where storage and bandwidth are constrained.
Increased computational requirements: zk-STARKs require more computational resources to generate proofs compared to zk-SNARKs.
The primary distinction between zk-STARKs (Starkware) and zk-SNARKs (zkSync) is the trusted setup. zk-STARKs have a 10 times faster proof generation speed than zk-SNARKs. Moreover, zk-SNARKs' computational complexity increases linearly under load, requiring more resources, whereas zk-STARKs experience less increase in load as the computation (number of transactions) grows. Under load, zk-STARKs require significantly less time, and they also offer quantum stability.
But zkSTARK has its own disadvantage: their proof size is much larger than that of zkSNARK. It is also worth considering that zkSNARK appeared much earlier and this technology is better understood by the developers.
And in fact zkSNARK has several implementations, the most recent of which have come close to zkSTARK in terms of functionality. Let's take a look at several variants of zkSNARK technology:
Growth16 is the first implementation of zk-SNARK introduced in 2018. It is currently the fastest and smallest known zk-SNARK and is used in Zcash. But the small size has a disadvantage: only a small amount of data can be written.
Sonic a continuation of Growth16, appeared in 2019 and supports a universal and updatable general reference string. Sonic proofs are of constant size, but verification is expensive. Sonic can only provide good speed with multiple proofs in batch mode. Sonic also has a universal and updatable CRS, which improves security.
Plonk is an improved algorithm with a 5x faster pruver runtime and a small proof size. It offers better pruver times, but worse run times than Sonic. It is used in all recent iterations of zk-SNARK (zkSync, Scroll, Aztec, Mina Protocol, Dusk) and has different variants: fflonk, turbo PLONK, ultra PLONK, plonkup and plonky2.
Marlin - introduced in 2019 along with Sonic and Plonk, positioned as a solution that is suitable for use cases where batch processing cannot be used. Has 10 times better pruver time and 4 times faster verification time than Sonic.
Fractal is the most advanced version of zkSNARK, introduced in 2020, requires no trusted installation and is quantum resistant, as Fractal is based on hash functions for which quantum attacks are currently feasible. But there is a serious disadvantage: Fractal's proof size is 2.5x larger than STARK's proof.
Zk-Rollups Improvements Over Traditional Layer 1 Networks
Zk-Rollups offer several key improvements over traditional Layer 1 networks:
Scalability: By aggregating multiple transactions into a single proof, Zk-Rollups significantly reduce the data and computational requirements on the Layer 1 network, enabling much higher transaction throughput.
Security: The cryptographic nature of zero-knowledge proofs ensures transaction validity without relying on external validators, thereby enhancing the security of the network.
Cost-efficiency: Reduced data storage and computation requirements lead to lower transaction fees, making Zk-Rollups a more cost-effective scaling solution.
Finality: Zk-Rollups provide faster transaction finality, as the verification of the cryptographic proof is sufficient to consider a transaction valid.
Privacy: While not inherently designed for privacy, Zk-Rollups can be adapted to include privacy-preserving features by incorporating advanced cryptographic techniques. As a result, Zk-Rollups can cater to users who seek increased privacy in their transactions, while still maintaining the transparency and auditability required for regulatory compliance.
Conclusion
Rollups have come a long way since Plasma. Zk-Rollups represent a powerful technology that holds the potential to revolutionize the scalability of blockchain networks. With their ability to enhance scalability, security, privacy, and cost efficiency, Zk-Rollups have the potential to drive the widespread adoption of blockchain technology across various industries. As more projects continue to explore and implement Zk-Rollup solutions, we can expect the landscape of the blockchain space to evolve, ushering in a new era of innovation and growth.