Critiquing the "Crypto Mainstream" Zero-Knowledge Proof (ZKP)
TechFlow Selected TechFlow Selected
Critiquing the "Crypto Mainstream" Zero-Knowledge Proof (ZKP)
ZK systems may need to be used in conjunction with safety tools such as formal verification or other safety-related tools like Ecne.
Navigating Web3 tides with focused insights*Note: First, this is a draft written in one hour. It is mainly intended for rapid information collection, so there may be numerous potential errors and incomplete information.
The main criticisms of ZK include two aspects:
-
One is the long proof generation time (hence various benchmarks, new ZK protocols, and hardware optimizations);
-
The other is that system and application security still require testing.
Proof Generation Performance
Zero-knowledge proofs are a highly popular technology in the blockchain field. Since on-chain computational resources are scarce and expensive, zero-knowledge proofs allow these computations to be performed off-chain. Although the total time cost for off-chain proof generation is very high, they compress the final proof and related verification computation, enabling computation to effectively occur "on-chain."
The issue of excessively long ZK proof generation times is often overlooked by researchers and developers because it is essentially a trade-off inherent to ZK.
While they do not directly criticize this drawback of ZK, many have proposed alternative solutions and discussions addressing it.
In other words, they implicitly acknowledge the extremely long proof times in ZK by proposing various solutions and conducting extensive benchmarking.
a) Benchmark
Before measuring ZK applications, we first need to test the performance of the underlying commitment schemes in ZK protocols.
For example, FRI leads to STARKs, KZG enables standard SNARKs, and IPA underpins Bulletproofs. While performance testing of these underlying commitments is not directly indicative of ZK application performance, it helps understand why ZK proof generation takes so long.
From the link above, we can see that these foundational commitment protocols are not only computationally complex (potentially leading to long proof times), but also suffer from extremely high memory consumption.
Of course, high memory usage relates more to hardware configuration requirements, which is a separate topic from our current discussion.
Regarding specific SNARK performance evaluations, a16z crypto divides them into frontend and backend components:
-
The frontend typically refers to high-level languages like Cairo or zkVMs, which are accessible to ZK application developers;
-
The backend involves low-level cryptographic operations such as commitments, which are closer to the actual SNARK proof generation process.
Among these, the author notes that SNARK proof generation incurs approximately a 100x computational overhead, with each ZK protocol adding further overhead. For example:
"In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups that aren't pairing friendly. This results in at least an additional factor-6 slowdown relative to the 100-|C| estimate above."
Overall, it can be said that the additional performance overhead of zk-SNARKs ranges between 200x and 1000x.
Additionally, the article mentions other limitations of zk-SNARKs, such as trusted setup requirements and memory usage.
An article by Modulus Labs measures the real-world performance of several ZK protocols. Some benchmarks focus on parameter counts, which are not very intuitive for us. However, in practical applications, the article notes that even using the "fastest" Plonky2 in the Worldcoin use case, proof generation still takes several minutes and consumes tens of gigabytes of memory, making it impossible to run on personal computers.
b) Recursion and Batching
To reduce proof generation time, we can parallelize the generation of multiple proofs.
Typically, there are two ways to achieve this: batching and recursion.
Simply put, batching involves proving a batch of statements simultaneously and then aggregating them, while recursion verifies other proofs within a single proof. Generally, recursive methods offer the added advantage of smaller proof sizes.
Some common aggregation methods include Halo2 and Plonky2. Each implements batching and recursion differently, thereby reducing proof generation time.
Beyond the protocol layer, the application layer of ZK can also be specifically optimized. For instance, multiple ZK protocols (e.g., STARK + SNARK) can be used together, or recursive strategies can be applied macroscopically for application-specific tuning.
Generally speaking, this actually reduces proof generation time in terms of protocol and proof distribution. When exploring new ZK protocols, minimizing proof time remains the top priority.
c) Hardware Acceleration
Furthermore, significant efforts have been made to reduce ZK application proof generation time at the physical and node levels through hardware improvements.
First, similar to the previously mentioned new protocols, ZK protocols are being designed to be as hardware-friendly as possible—for example, HyperPlonk.
Paradigm points out that slow ZK proof generation is primarily due to heavy use of MSM (multi-scalar multiplication) and FFT (fast Fourier transform), which are hardware-unfriendly and result in slow final proof generation due to issues like random memory access. For these low-level cryptographic computations, ZK protocols must make certain trade-offs in their composition and scale to become more hardware-efficient.
Several ZK hardware acceleration companies indicate that GPUs are currently the most cost-effective and configurable hardware option, though the industry will eventually transition from FPGAs to ASICs. According to ZK hardware firms, their first-generation ASICs could directly reduce ZK proof generation time by at least 30%.
Moreover, due to varying server configurations, running different cloud servers as nodes may involve distinct hardware-specific optimizations.
Security
Another current criticism of ZK is that circuit code must still be correct (bug-free).
If a ZK protocol is compromised in terms of soundness, completeness, or zero-knowledge properties, we no longer have a valid ZK system. We can find examples of attacks from various angles at this link.
Although ZK applications can be described as trustless, we still need to ensure that the project's ZK protocol, code, and architecture are correct. There are various types of ZK-related vulnerabilities in the blockchain space. For example, due to the massive size of zkEVM's ZK circuit codebase, Vitalik has discussed the need for multi-prover systems in ZK applications.
Therefore, ZK systems may need to be paired with security tools such as formal verification or other security-related tools like Ecne. At the application level, especially for large projects like zkEVM, more audits are required.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
msfew / Suning Yao
