For various types of DApps, ZK rollups may not be the best choice for development stack.
Author: Jaehyun Ha
Translation: DeepTechFlow
Abstract
While zero-knowledge proofs (ZKPs) are expected to create a more private and scalable blockchain ecosystem, many aspects of zero-knowledge (ZK) are misunderstood or implemented differently from common knowledge.
ZKPs mainly have two aspects: "zero-knowledge" and "succinctness". While this statement is not wrong, 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 for the development stack. For example, generating ZKPs may become a bottleneck for quick termination, thereby reducing the performance of Web3 games, and the data availability guarantee method based on state difference release may harm the services of DeFi lending protocols.
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 three major problems of blockchain, without fully understanding how ZK technology benefits each project.
In this ZK series, we will explore the undeniable facts (disadvantages and drawbacks) of ZK rollups and their beneficial applications. First, we will analyze the two core attributes of ZK proofs (ZKPs) in the blockchain: "zero-knowledge" and "succinctness." Then, we will discuss why many ZK rollups currently in service have not truly utilized the "zero-knowledge" aspect. Next, we will study in which areas the application of ZK rollup is more harmful than beneficial, avoiding well-known problems such as implementation complexity. Finally, we will highlight outstanding projects that effectively embody ZK principles and actually derive significant benefits from using ZK technology.
Review: The Transaction Lifecycle in ZK Rollups
Rollup is a scaling solution that resolves the throughput limitations of L1 by executing transaction batches off-chain and storing the latest L2 state's summary data on L1. Among them, the prominent feature of ZK Rollups is the ability to quickly withdraw funds by submitting on-chain the validity proof of off-chain computation. Before we delve into the issues of ZK rollups, let's briefly review its transaction lifecycle.
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 in "batches" to the on-chain state smart contract and compresses the corresponding L2 transaction data into data blocks to ensure data availability.
This batch is sent to the prover, who creates the validity proof (or ZKP) of the batch's execution. Then, this validity proof, along with additional data (i.e., the previous state root), is sent to the verifier smart contract on L1, which helps the verifier identify what it is verifying.
After the verifier contract checks the proof's validity, the rollup state is updated, and the L2 transactions submitted in the batch are considered completed.
(Note that this explanation is a simplified version of the ZK Rollup process, and each implementation may vary due to protocols. 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 purposes. The above explanation assumes a scenario where a centralized sequencer has the authority to execute transactions and also generates a uniform data block format for batches.)
Unlike Optimistic Rollups, thanks to ZKPs (such as ZK-SNARKs or ZK-STARKs), ZK Rollups can verify the correctness of executing thousands of transactions by verifying a simple proof without replaying all transactions. So, what is this ZKP, and what are its characteristics?
Two Properties of ZKPs: Zero-Knowledge and Succinctness
As the name suggests, ZKP is essentially a proof. A proof can be anything that sufficiently supports the provider's claim. Suppose Bob (the provider) wants to convince Alice (the verifier) that he has authority over his laptop. The simplest way to prove this is for Bob to tell Alice the password, and Alice inputs the password on the laptop to verify that Bob indeed has authority. However, this verification process is unsatisfactory for both Alice and Bob. If Bob sets a very long and complex password, it will be very challenging for Alice to input it correctly (assuming Alice cannot copy and paste). More realistically, Bob may not want to reveal his password to Alice to prove his authority.
Is there a verification process where Alice can quickly verify the computer's authority without Bob revealing his password? For example, Bob can unlock the laptop with fingerprint recognition in front of Alice, 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: zero-knowledge property and succinctness property.
Zero-Knowledge (ZK)
The zero-knowledge property means that the proof generated by the provider does not reveal any information about the secret witness (i.e., private data) other than the proof's validity, making 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., prove that a user has enough funds for a transaction) without exposing their transaction details (such as transfers, account balance updates, smart contract deployment, and execution) to the public.
Succinctness
The succinctness property means that ZK can generate a short and quickly verifiable proof from a large statement, in other words, it compresses large things into a compact form. In blockchain, this is particularly useful for rollups. Using ZKPs, verifiers in L2 can easily confirm the validity of execution within a short time (i.e., 10 milliseconds to 1 second) by verifying a succinct proof instead of replaying all transactions.
ZK Rollup is great, but it does not necessarily mean privacy
The above characteristics of ZKP are well utilized in ZK Rollups. Although verifiers cannot infer the original transaction data from the ZKPs provided, the ability to verify succinct proofs effectively allows them to verify the provider's claim (i.e., the new L2 state). In other words, it is misleading to assert that current ZK Rollups fully adhere to the zero-knowledge and succinctness properties. This may be correct when focusing on the interaction between the provider and the verifier, but 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 comes from the compromise that may occur when some parts remain public while certain parts become private through ZK. Think about 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 L2 batches are submitted to the DA layer, is the privacy of individual account information protected? Currently, these scenarios are not valid.
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 deployment, and execution. For example, you can easily observe all mentioned details by accessing any ZK Rollup block explorer. Furthermore, 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 L2 data publicly released by the DA layer (in most cases, L1 Ethereum) and reconstruct the L2 state. During this process, any node capable of replaying L2 transactions stored in the DA layer can recover information about the state of each user account.
Therefore, the term "zero-knowledge" is implemented in a fragmented form in current ZK Rollups. While this cannot be considered wrong, it is evident that it differs from the common understanding that "ZK implies zero-knowledge is equivalent to complete privacy." The novelty of current ZK Rollups lies in utilizing the "succinctness" property rather than "zero-knowledge," i.e., executing transactions off-chain in rollups and generating succinct proofs for verifiers to quickly and scalably verify the validity of 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? Is it to achieve complete transaction privacy by deploying ZK comprehensively in every part of the Rollup? In fact, this is not a simple question. In addition to requiring significant technological advancements to further mature the technology, ZK still faces controversial issues in ideology (e.g., 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 practical issues encountered in blockchain projects with ZK Rollups.
Point 1: Generating ZKPs may be a bottleneck for quick termination
First, let's discuss the practicality of ZK Rollups themselves. The most notable selling point of ZK Rollups is the shortened asset withdrawal delay due to the "quick termination" of transactions, thanks to ZKP. Increased TPS and low transaction fees are additional benefits. The area that most effectively utilizes the features of ZK Rollups is the gaming industry, as in-game currency transactions are very frequent, generating a large number of in-game transactions every second.
But can ZK Rollups really be considered the best technology stack for games? To answer this, we need to delve deeper into the concept of "quick termination" in ZK Rollups. Imagine a user enjoying a Web3 game running on a technology stack based on ZK Rollup. The user is trading in-game items for game coins and is trying to withdraw that asset from the game.
To withdraw the asset, in-game transactions must be terminated. This means the transactions must be included in a new Rollup state commitment, the corresponding ZKP must be submitted to L1, and it is necessary to wait for finality proof in L1 Ethereum to ensure the transactions are irreversible. If all these processes could happen instantly, then we could achieve the "instant transaction confirmation" often boasted about ZK Rollups, allowing users to withdraw assets immediately.
However, reality is far from this. According to the termination time statistics of different ZK Rollups provided by L2beat, zkSync Era takes about 2 hours, Loopring takes 3 hours, and Starknet averages about 8 hours. This is because generating a ZKP takes time, and including more transactions in a batch (i.e., a single proof) to reduce transaction fees also takes additional time. In other words, the speed of generating and submitting proofs is a potential bottleneck for achieving quick termination in ZK Rollups, which may reduce the user experience in Web3 games.
On the other hand, gaming-optimized chains like Ronin (supporting Web3 games such as Pixels and Axie Infinity) ensure super-fast termination while sacrificing decentralization and security. Ronin is not based on ZK or Rollup technology: it is an EVM blockchain running on a PoA (Proof of Authority) + DPoS (Delegated Proof of Stake) consensus algorithm. It selects 22 validators based on the amount of delegated shares, and these validators generate and verify blocks in a PoA manner (i.e., only through a voting process among the 22 validators). Therefore, on Ronin, transactions can be terminated quickly, included in blocks with almost no delay, and have short verification times. After the Shillin hard fork, each transaction only takes 6 seconds on average to complete termination. Ronin achieves all of this without needing ZKP.
Of course, Ronin also has drawbacks. Its management by centralized validators makes it relatively more susceptible to the threat of a 51% attack. Additionally, as it does not use Ethereum as the settlement layer, it cannot inherit the security of Ethereum. There are also security risks when using cross-chain bridges. But from the user's perspective: do they care about these? Current ZK Rollups without decentralized sequencing also have single point of failure (SPOF) issues. Ethereum provides guarantees for them by reducing the possibility of transaction rollbacks, but if centralized sequencers or verifiers fail, ZK Rollups will also freeze. Again, note that the "ZK" in ZK Rollups is only used for verifying the validity of execution. If another project provides the same functionality but faster and cheaper, ZK Rollups may no longer be the preferred technology stack for Web3 game users and developers.
Point 2: State difference release is a double-edged sword
Another point is the practicality of the ZK Rollup protocol implementation. Here, we focus on state difference release, which is one of the methods in ZK rollups to ensure data availability (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 mountaineer proving and recording their ascent of Mount Everest. The simplest method would be to record every step from base camp to the summit in a video. Although the video files may be large, anyone can verify the mountaineer's ascent and potentially replay the footage. This metaphor can be likened to the raw transaction data publishing method to ensure data availability. Optimistic Rollups follow this method so that individual challengers can replay and verify 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 compressed form on L1 so that anyone can replay L2 transactions to recover the Rollup's state when needed.
Returning to the amateur mountaineer example, another verification method could be a famous mountaineer climbing Mount Everest with the amateur to prove the ascent to the world. Since the climb has been confirmed by a trusted individual, the mountaineer no longer needs to record every step for documentation. Only a photo at the starting point and the summit is needed, and others will believe the mountaineer has reached the summit. This metaphor 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 the execution of L2 transactions on L1 so that anyone can calculate the state differences from the initial state to recover the Rollup's state when necessary.
This state difference method undoubtedly has cost advantages over the raw transaction data publishing method, as it eliminates the step of storing intermediate transactions, reducing the storage cost on L1. Although this is usually not a problem, there is still 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 Compound DeFi lending protocol as an example, suppose it is built on a state difference-based ZK Rollup technology stack. These protocols require a complete transaction history to calculate supply and lending rates every second. However, if the ZK Rollup sequencer fails and other Rollup nodes attempt to recover the latest state, what will happen? It may recover the state, but the rates will be inaccurately restored because it can only track snapshots between batches, not every intermediate transaction.
Conclusion
This article mainly asserts that "ZK" does not exist in most of today's ZK Rollups, and in many cases, using ZKPs and ZK procedures may not be the best choice for DApps. ZK technology may feel innocent of the accusations, as it is not inherently problematic, but in the process of leveraging its technological advancements, it may bring potential performance degradation to DApps. However, this is not to say that ZK technology is useless in this industry. When ZKPs and ZK rollups mature technologically, they can certainly provide better solutions to solve the blockchain trilemma. In fact, there are already ZK-based projects maintaining ZK privacy, and many types of DApps effectively leverage the advantages of ZKPs and ZK rollups.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
