ZK Rollups: The Elephant in the Room
For various types of DApps, ZK rollups may not be the best choice of development stack.Original Title: 《[ZK series - 1] ZK Rollups: Elephant In the Room》
Author: Jaehyun Ha
Compiled by: Shenchao TechFlow
Abstract
While zero-knowledge proofs (ZKPs) hold the promise of creating a more private and scalable blockchain ecosystem, many aspects of zero-knowledge (ZK) are misunderstood or differ from the common understanding of their implementation.
ZKPs primarily have two aspects: "zero-knowledge" and "succinctness." While this statement is not incorrect, most ZK rollups only utilize the succinctness property, and transaction data and account information are not fully kept zero-knowledge or private.
For various types of DApps, ZK rollups may not be the best choice of development stack. For example, generating ZKPs may become a bottleneck for fast finality, thereby reducing the performance of Web3 games, while data availability guarantee methods based on state differences may compromise the services of DeFi lending protocols.
Figure 1: ZK is a great buzzword
The current state of the blockchain industry can be likened to the zero-knowledge (ZK) era. Wherever you go, ZK is prominent, and it is becoming increasingly rare to find the next generation of blockchain projects that do not incorporate ZK into their names. From a technical perspective, it is undeniable that ZK is a promising technology that can contribute to a more scalable and private blockchain ecosystem. However, due to the complex technical background of ZK, many investors, whether retail or institutional, often invest in ZK projects based on "belief" that it looks cool, novel, and may solve the blockchain trilemma, without fully understanding how ZK technology benefits each project.
In this ZK series, we will explore the hard-to-ignore facts (disadvantages and drawbacks) of ZK rollups and their beneficial applications. First, we will analyze the two core properties of ZK proofs (ZKPs) in blockchain: "zero-knowledge" and "succinctness." Then, we will discuss why many ZK rollups currently in service do not truly leverage the "zero-knowledge" aspect. Next, we will examine in which areas applying ZK rollups may be more harmful than beneficial, avoiding well-known issues such as implementation complexity. Finally, we will highlight outstanding projects that effectively embody ZK principles and gain significant benefits from using ZK technology.
Review: The Transaction Lifecycle in ZK Rollups
Rollup is a scaling solution that addresses the throughput limitations of L1 by executing batches of transactions off-chain and then storing the summary data of the latest L2 state on L1. Among them, the standout feature of ZK Rollups is the ability to quickly extract funds by submitting validity proofs of off-chain computations on-chain. Before we delve into the issues of ZK rollups, let’s briefly review its transaction lifecycle.
Figure 2: Transaction lifecycle in ZK rollups
Each L2 user generates and submits their transactions to the sequencer.
The sequencer aggregates and orders multiple transactions, then executes these transactions off-chain to compute the new rollup state. Subsequently, the sequencer submits this new rollup state to the on-chain state smart contract in the form of a "batch" and compresses the corresponding L2 transaction data into a data block to ensure data availability.
This batch is sent to the prover, who creates a validity proof (or ZKP) for the execution of that batch. This validity proof is then sent to the L1 validator smart contract along with additional data (i.e., the previous state root), which helps the validator identify what it is verifying.
After the validator contract checks the proof's validity, the rollup's state is updated, and the L2 transactions in the submitted batch are considered completed.
(Note that this explanation is a simplified version of the ZK Rollup process, and each implementation may vary by protocol. If we distinguish roles, there may be more entities in L2, such as aggregators, executors, and proposers. The hierarchy of data blocks may also differ, such as blocks, block groups, and batches, depending on their use. The above explanation assumes a scenario where a centralized sequencer has strong authority to execute transactions and also generates a unified data block format as a batch.)
Unlike Optimistic Rollups, ZK Rollups can verify the correctness of the execution of thousands of transactions by validating a simple proof, thanks to ZKPs (such as ZK-SNARKs or ZK-STARKs), without needing to replay all transactions. So, what is this ZKP, and what are its characteristics?
Two Properties of ZKPs: Zero-Knowledge and Succinctness
As the name suggests, a ZKP is essentially a proof. A proof can be anything that sufficiently supports the provider's claim. Suppose Bob (the provider) wants Alice (the verifier) to believe he has authority over his laptop. The simplest way to prove this is for Bob to just tell Alice the password, and Alice types the password on the laptop to verify that Bob indeed has access. However, this verification process is unsatisfactory for both Alice and Bob. If Bob sets a very long and complex password, it would be very challenging for Alice to input it correctly (assuming Alice cannot copy and paste). More realistically, Bob might not want to disclose his password to Alice to prove his authority.
What if there were a verification process where Alice could quickly verify the authority of the computer without Bob revealing his password? For example, Bob could unlock the laptop in front of Alice using fingerprint recognition, as shown in Figure 3 (note that this is not a perfect example of ZKP). This is where both Alice and Bob can benefit from the two key properties of ZKPs: the zero-knowledge property and the succinctness property.
Figure 3: High-level intuition of zero-knowledge and succinctness
Zero-Knowledge (ZK)
The zero-knowledge property means that the proof generated by the provider does not leak any information about the secret witness (i.e., private data) other than the validity of the proof, leaving the verifier completely unaware of the data. In blockchain, this property can be used to protect the privacy of individual users. If ZKPs are applied to every transaction, users can prove the legitimacy of their actions (i.e., proving that a user has sufficient funds to make a transaction) without exposing their transaction details (such as transfers, account balance updates, smart contract deployments, and executions) to the public.
Succinctness
The succinctness property refers to the ability of ZK to generate a short and quickly verifiable proof from a large-sized statement; in other words, it compresses large things into a compact form. In blockchain, this is particularly useful for rollups. Using ZKPs, validators in L2 can claim the correct execution of transactions by submitting a succinct proof to validators in L1 (the validity of TB-level transactions can be represented with a proof of 10~100 KB). Then, validators can easily confirm the validity of the execution in a short time (i.e., 10 milliseconds to 1 second) by verifying the succinct proof instead of replaying all transactions.
ZK Rollups are Great, but That Doesn't Mean Privacy
The aforementioned characteristics of ZKPs are well utilized in ZK Rollups. Although validators cannot infer the original transaction data from the ZKPs received from the provider, the verification of succinct proofs allows them to effectively verify the provider's claims (i.e., the new L2 state). That said, asserting that current ZK Rollups fully adhere to the properties of zero-knowledge and succinctness is misleading. While this may be true when focusing on the interaction between providers and validators, there are other components in ZK Rollups, such as sequencers, providers, and rollup nodes. So, does the "zero-knowledge" principle also ensure them?
The challenge of achieving complete privacy with ZKPs in any ZK Rollups arises from the compromises that may occur when some parts remain public while others become private through ZK. Consider the transaction lifecycle in ZK Rollups: is privacy maintained when transactions are sent from users to the sequencer? What about for the provider? Or when the L2 batch is submitted to the DA layer, is the privacy of individual account information protected? Currently, these situations do not hold.
Figure 4: Privacy leaks in ZK rollups
In most mainstream ZK Rollups, the sequencer or provider (or other centralized entities with strong authority) can clearly see transaction details, including transfer amounts, account balance updates, contract deployments, and executions. For a simple example, you can easily observe all the mentioned details by accessing any ZK Rollup block explorer. Moreover, consider a scenario where a centralized sequencer stops service for some reason, and another rollup node attempts to recover the rollup state. It will extract information from the publicly published L2 data in the DA layer (which is mostly L1 Ethereum) and reconstruct the L2 state. In this process, any node capable of replaying the L2 transactions stored in the DA layer can recover information about the state of each user account.
Thus, the term "zero-knowledge" is implemented in a fragmented manner in current ZK Rollups. While this cannot be considered incorrect, it is clear that it differs from the common perception that "ZK means zero-knowledge is equivalent to complete privacy." The novelty of current ZK Rollups lies in leveraging the "succinctness" property rather than "zero-knowledge," that is, executing transactions off-chain and generating succinct proofs for validators so they can quickly and scalably verify the validity of the execution without re-executing them.
For this reason, some ZK Rollups, such as Starknet, refer to themselves as "validity rollups" to avoid confusion, while others that ensure true ZK privacy, such as Aztec, label themselves as ZK-ZK rollups.
In-Depth Consideration of the Practicality of ZK Rollups
As mentioned earlier, most ZK Rollups do not fully achieve ZK privacy. So, what is our next goal? Achieving complete transaction privacy by fully deploying ZK in every part of the Rollup? In fact, this is not a simple question. Besides requiring significant technological advancements to further mature the technology, ZK still faces controversial issues in ideology (e.g., the illegal use of private transactions) and practicality (e.g., is it really useful?). Given that discussing the ethical issues of complete transaction privacy is beyond the scope of this article, we will focus on two practicality issues encountered by ZK Rollups in blockchain projects.
Point 1: Generating ZKP May Be a Bottleneck for Fast Finality
First, let’s discuss the practicality of ZK Rollups themselves. The most striking selling point of ZK Rollups is the reduced asset withdrawal delay due to their transactions' "fast finality," thanks to ZKPs. Increased TPS and low transaction fees are additional benefits. The area that most effectively utilizes the characteristics of ZK Rollups is the gaming industry, as the access and withdrawal of in-game currency occur very frequently, generating a large number of in-game transactions every second.
But can ZK Rollups really be considered the best tech stack for games? To address this, we need to think more deeply about the concept of "fast finality" in ZK Rollups. Imagine a user enjoying a Web3 game running on a ZK Rollup-based tech stack. The user trades in-game items for game currency and attempts to withdraw that asset from the game.
To withdraw the asset, the in-game transaction must be finalized. This means the transaction must be included in the new Rollup state commitment, the corresponding ZKP should be submitted to L1, and one must wait for the finality of the proof in L1 Ethereum to ensure the transaction is irreversible. If all these processes could happen instantly, we could achieve the "instant transaction confirmation" that ZK Rollups are often touted for, allowing users to withdraw assets immediately.
However, reality is far from this. According to finality time statistics for different ZK Rollups provided by L2beat, zkSync Era takes about 2 hours, Linea takes 3 hours, and Starknet averages about 8 hours. This is because generating a ZKP takes time, and including more transactions in a single batch (i.e., a single proof) to reduce transaction fees also requires additional time. In other words, the speed of generating and submitting proofs is a potential bottleneck for achieving fast finality in ZK Rollups, which may degrade the user experience in Web3 games.
Figure 5: ZKP generation may be a potential bottleneck for fast finality in ZK rollups
On the other hand, chains optimized for gaming, like Ronin (which supports Web3 games like Pixels and Axie Infinity), ensure ultra-fast finality while sacrificing decentralization and security. Ronin is not a ZK or Rollup-based chain: it operates under a PoA (Proof of Authority) + DPoS (Delegated Proof of Stake) consensus algorithm. It selects 22 validators based on the number of delegated stakes, and these validators generate and verify blocks in a PoA manner (i.e., a voting process among the 22 validators). Therefore, transactions on Ronin can quickly achieve finality, with almost no delay in being included in blocks, and verification times are very short. After the Shillin hard fork, the average time for each transaction to achieve finality is only 6 seconds. Ronin achieves all this without ZKP.
Of course, Ronin also has its drawbacks. Being managed by centralized validators makes it relatively more susceptible to 51% attacks. Additionally, since it does not use Ethereum as a settlement layer, it cannot inherit Ethereum's security. There are also security risks associated with using cross-chain bridges. But from the user's perspective: do they care about these? Current non-decentralized ZK Rollups also face single point of failure (SPOF) issues. Ethereum provides them with assurance as it reduces the likelihood of transaction rollbacks, but if a centralized sequencer or validator fails, ZK Rollups will also freeze. Again, note that the "ZK" in ZK Rollups is only used to validate the correctness of execution. If another project offers the same functionality but faster and cheaper, ZK Rollups may no longer be seen as the preferred tech stack by Web3 game users and developers.
Point 2: State Difference Publishing is a Double-Edged Sword
Another point is the practicality of ZK Rollup protocol implementations. Here, we focus on state difference publishing, which is one of the methods to ensure data availability in ZK rollups (see Unlocking Dencun Upgrade: Unseen Truth of Scaling DA Layers, Jaehyun Ha, 12Apr24).
A simple way to understand data availability in Rollups is to imagine an amateur climber proving and recording his ascent of Mount Everest. The simplest method is to record a video of every step from base camp to the summit. Although the video file may be large, anyone can verify the climber's ascent and potentially replay the footage. This analogy can be likened to the raw transaction data publishing method used to ensure data availability. Optimistic Rollups follow this method so that individual challengers can replay and verify the correct execution, as the sequencer's state commitment cannot be trusted. In ZK Rollups, Polygon zkEVM and Scroll adopt this method, storing the raw L2 transaction data in a compressed form on L1 so that anyone can replay L2 transactions to restore the Rollup's state when needed.
Returning to the amateur climber's example, another verification method might involve a famous climber ascending Everest with the amateur climber to prove to the world that the climb was indeed completed. Since the ascent has been verified by a trusted individual, the climber no longer needs to record every step for documentation. A photo taken at the starting point and the summit would suffice for others to believe the climber has reached the top. This analogy reflects the state difference method used to ensure data availability. In ZK Rollups, zkSync Era and StarkNet adopt this method, storing only the state differences before and after L2 transactions are executed on L1, so that anyone can calculate the state difference from the initial state to restore the Rollup's state when necessary.
Figure 6: Raw transaction publishing vs. state difference publishing
This state difference method is undoubtedly advantageous in terms of cost compared to the raw transaction data publishing method, as it eliminates the need to store intermediate transactions, thereby reducing storage costs on L1. Although this is generally not an issue, there is a potential drawback: this method does not allow for the recovery of the complete L2 transaction history, which may be a problem for certain DApps.
Taking the DeFi lending protocol Compound as an example, suppose it is built on a state difference-based ZK Rollup tech stack. These protocols require a complete transaction history to calculate supply and borrowing rates every second. However, what happens if the ZK Rollup sequencer fails, and other Rollup nodes attempt to recover the latest state? It may recover the state, but the interest rates will be inaccurately restored because it can only track snapshots between batches rather than each intermediate transaction.
Conclusion
This article primarily asserts that most of today's ZK Rollups do not possess "ZK," and in many places within DApps, using ZKP and ZK programs may not be the best choice. ZK technology may feel innocent of blame, as it has no inherent issues; rather, in the process of leveraging its technological advancements, it may lead to potential performance declines in DApps. However, this does not mean that ZK technology is useless for the industry. When ZKPs and ZK rollups eventually mature technologically, they can certainly provide better solutions to address the blockchain trilemma. In fact, there are already ZK-based projects that maintain ZK privacy, and many types of DApps effectively leverage the advantages of ZKP and ZK rollups.
