First of all, this is a sketch written in one hour. At this point it's just to gather information quickly, so there may be very many potential errors and incomplete information.

The main criticisms against ZK would include two, one being the long proof time, (hence the various benchmarks, various new ZK protocols, and various hardware optimizations), and one being that system and application security still needs to be tested.

Zero-knowledge proof is a very popular technology in the blockchain space. Due to the scarce and expensive on-chain computational resources, zero-knowledge proofs allow these computations to be performed off-chain, and while the total time consumption for proof generation off-chain is very high, it still compresses the final proof and the associated computational verification, thus allowing the computation to be "on-chain".

The problem of extremely long proof generation times for ZK is often overlooked by researchers and developers, because it is essentially a trade-off that ZK needs to make.

Although they do not directly criticize this drawback of ZK, they have many approaches and discussions to address this drawback from the opposite side. That is, they implicitly talk about the extremely long proof time of ZK by proposing various solutions and performing a lot of benchmarking.

Before measuring the ZK application, we first had to test the performance of the underlying commitment of the ZK protocol (https://2π.com/23/pc-bench/index.html). For example, FRI leads to STARK, KZG leads to regular SNARK, and IPA leads to Bulletproof (https://blockdoc.substack.com/p/an-introduction-to-commitment-schemes). The performance testing of the underlying commitment is not intuitive to the performance of the ZK application, but it is useful for understanding the long proof time of ZK.

As we can see from the above links, these underlying commitment protocols are not only computationally complex (which may lead to long proof times), but also have the problem of consuming very large amounts of memory. Of course, memory consumption is actually more related to hardware configuration requirements, which is different from the topic we are discussing today.

For specific SNARK performance tests, a16z crypto divides them into front-end and back-end (https://a16zcrypto.com/content/article/measuring-snark-performance-frontends-backends-and-the- future/). The front-end is usually the Cairo language/zkVM high level language etc. that ZK application developers are exposed to, while the back-end is the underlying cryptographic operations such as commitment that are closer to the SNARK proof generation time. Among them, the authors mention that SNARK proof generation has about 100 times more computational overhead, and each ZK protocol has additional overhead, e.g. "In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups 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 slow down relative to the 100-|C| estimate above.". Overall, the additional performance overhead of zk-SNARK is in the range of 200 - 1000 times. In addition, the article also mentions other limitations of zk-SNARK, such as trusted setup and memory usage.

The Modulus Labs article (https://medium.com/@ModulusLabs/chapter-5-the-cost-of-intelligence-da26dbf93307) measures the actual performance of some ZK protocols. Some of the benchmarks are for the number of parameters, which is not very intuitive for us. However, in the application, the article mentions that in the Worldcoin use case, even with the "fastest" Plonky2, it still requires several minutes of proof generation time and tens of gigabytes of memory consumption, which cannot be run on a personal computer.

To reduce the proof generation time, we can prove multiple proofs in parallel. Usually, there are two ways to do this, one is batching and the other is recursion. In simple terms, batching is proving a batch of proofs simultaneously and finally aggregating them together, while recursion is verifying other proofs in one proof. In general, the recursion approach has the additional advantage of smaller proof size (https://twitter.com/bobbinth/status/1608690628652838915).

Some of the more common aggregation methods include Halo2, Plonky2 (https://www.youtube.com/watch?v=HE06BAsoWjw&list=PLlcfbEGVTa-gfVw5oz6a3BxAaUvstvxzf), Nova. Each of them performs batching and recursion in different ways, thus reducing the proof time. (https://kb.delendum.xyz/zk-knowledge#proof-aggregation)

In addition to the protocol level of ZK, the application level (https://www.youtube.com/watch?v=VmYpbFxBdtM) of ZK can also be optimized specifically. For example, multiple ZK protocols can be used simultaneously (STARK + SNARK (https://www.youtube.com/watch?v=ZwG3UI_iDAs)), or application-specific tuning on macroscopic recursive strategies (https://ethresear.ch/t/proving-a-chain-of-hashes-using-plonky2/15246, https://www.youtube.com/watch?v=t34Pt40COKg).

In general, this actually reduces the proof generation time in terms of protocol and proof allocation. In the exploration of new ZK protocols, reducing the proof time is the most important consideration.

In addition, many efforts have been made to further reduce the proof time at the physical and node levels for ZK applications from the hardware perspective.

First, like the new protocols mentioned before, the ZK protocol is designed to be as hardware friendly as possible, for example HyperPlonk (https://hackmd.io/@omershlo/rJhgKJPtj).

Paradigm mentions (https://www.paradigm.xyz/2022/04/zk-hardware) that the slow proof generation for ZK is mainly due to the large number of MSMs and FFTs involved which are not hardware friendly, resulting in slow final proof generation due to random memory access and other issues. With respect to these underlying cryptographic computations, the ZK protocol requires some trade-offs in their composition and scale (https://www.youtube.com/watch?v=5hO9NbtFc0g&t=3882s) to make it more hardware friendly.

Several ZK hardware acceleration manufacturers (https://www.youtube.com/watch?v=3wLYtzHuu5U&list=PLlcfbEGVTa-gfVw5oz6a3BxAaUvstvxzf) and researchers (https://trapdoortech.medium.com/zero-knowledge-proof-fpga-or-gpu-97b96ffbf0f) have said that GPUs are actually the most economical and configurable hardware option right now, and that we will have FPGAs to transition to the ASIC stage eventually. According to the zk hardware companies, the first version of their ASIC can reduce the ZK proof generation time by at least 30% directly.

In addition, running different cloud servers as nodes may involve different hardware-specific optimizations due to different server configurations (https://twitter.com/ingo_zk/status/1597963357772214272).

Another criticize ZK has right now is the code of circuit still need to be right (no bug). If a ZK protocol is attacked from the Soundness, Completeness, Zero-knowledge perspective, we will no longer have a valid ZK system. We can see examples of attacks from various perspectives at this link (https://kb.delendum.xyz/zk-knowledge#vulnerabilities).

Although a ZK application can be called trustless, we still need to ensure that the project's ZK protocol and the application's code and architecture are correct. There are many kinds of ZK bugs in the blockchain space (https://www.youtube.com/watch?v=FMXTvxo3NsI). For example, Vitalik talks about the need for multi-prover of ZK applications, due to the problem of huge codebase of ZK circuit of zkEVM (https://youtu.be/6hfVzCWT6YI?t=164).

So a ZK system may need to be paired with security tools like Formal Verification (https://medium.com/delendum/formal-verification-of-zk-constraint-systems-ab22f17b0525), or other security related tools like Ecne (https://github.com/franklynwang/EcneProject). Application level, it needs more auditing especially for big projects like zkEVM (https://www.youtube.com/watch?v=WJewE8fdlmU).

In practice (https://mirror.xyz/privacy-scaling-explorations.eth/BaqGMfBhEZR1cvTJlA9E3Xu5ZhD7IthLiUK-Q75rQMM), Ethereum PSE maintains zk bug tracker repo (https://github.com/0xPARC/zk-bug-tracker), which tracks bugs to help auditors quickly find common vulnerability in zk applications. Veridise has done a lot of research and development on formal verification of zk circuits (zk circuits natively can be easily expressed with mathematical formulas, which lend themselves well to formal verification), as well as universal tools for static analysis of zk.

First of all, this is a sketch written in one hour. At this point it's just to gather information quickly, so there may be very many potential errors and incomplete information.

The main criticisms against ZK would include two, one being the long proof time, (hence the various benchmarks, various new ZK protocols, and various hardware optimizations), and one being that system and application security still needs to be tested.

Zero-knowledge proof is a very popular technology in the blockchain space. Due to the scarce and expensive on-chain computational resources, zero-knowledge proofs allow these computations to be performed off-chain, and while the total time consumption for proof generation off-chain is very high, it still compresses the final proof and the associated computational verification, thus allowing the computation to be "on-chain".

The problem of extremely long proof generation times for ZK is often overlooked by researchers and developers, because it is essentially a trade-off that ZK needs to make.

Although they do not directly criticize this drawback of ZK, they have many approaches and discussions to address this drawback from the opposite side. That is, they implicitly talk about the extremely long proof time of ZK by proposing various solutions and performing a lot of benchmarking.

Before measuring the ZK application, we first had to test the performance of the underlying commitment of the ZK protocol (https://2π.com/23/pc-bench/index.html). For example, FRI leads to STARK, KZG leads to regular SNARK, and IPA leads to Bulletproof (https://blockdoc.substack.com/p/an-introduction-to-commitment-schemes). The performance testing of the underlying commitment is not intuitive to the performance of the ZK application, but it is useful for understanding the long proof time of ZK.

As we can see from the above links, these underlying commitment protocols are not only computationally complex (which may lead to long proof times), but also have the problem of consuming very large amounts of memory. Of course, memory consumption is actually more related to hardware configuration requirements, which is different from the topic we are discussing today.

For specific SNARK performance tests, a16z crypto divides them into front-end and back-end (https://a16zcrypto.com/content/article/measuring-snark-performance-frontends-backends-and-the- future/). The front-end is usually the Cairo language/zkVM high level language etc. that ZK application developers are exposed to, while the back-end is the underlying cryptographic operations such as commitment that are closer to the SNARK proof generation time. Among them, the authors mention that SNARK proof generation has about 100 times more computational overhead, and each ZK protocol has additional overhead, e.g. "In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups 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 slow down relative to the 100-|C| estimate above.". Overall, the additional performance overhead of zk-SNARK is in the range of 200 - 1000 times. In addition, the article also mentions other limitations of zk-SNARK, such as trusted setup and memory usage.

The Modulus Labs article (https://medium.com/@ModulusLabs/chapter-5-the-cost-of-intelligence-da26dbf93307) measures the actual performance of some ZK protocols. Some of the benchmarks are for the number of parameters, which is not very intuitive for us. However, in the application, the article mentions that in the Worldcoin use case, even with the "fastest" Plonky2, it still requires several minutes of proof generation time and tens of gigabytes of memory consumption, which cannot be run on a personal computer.

To reduce the proof generation time, we can prove multiple proofs in parallel. Usually, there are two ways to do this, one is batching and the other is recursion. In simple terms, batching is proving a batch of proofs simultaneously and finally aggregating them together, while recursion is verifying other proofs in one proof. In general, the recursion approach has the additional advantage of smaller proof size (https://twitter.com/bobbinth/status/1608690628652838915).

Some of the more common aggregation methods include Halo2, Plonky2 (https://www.youtube.com/watch?v=HE06BAsoWjw&list=PLlcfbEGVTa-gfVw5oz6a3BxAaUvstvxzf), Nova. Each of them performs batching and recursion in different ways, thus reducing the proof time. (https://kb.delendum.xyz/zk-knowledge#proof-aggregation)

In addition to the protocol level of ZK, the application level (https://www.youtube.com/watch?v=VmYpbFxBdtM) of ZK can also be optimized specifically. For example, multiple ZK protocols can be used simultaneously (STARK + SNARK (https://www.youtube.com/watch?v=ZwG3UI_iDAs)), or application-specific tuning on macroscopic recursive strategies (https://ethresear.ch/t/proving-a-chain-of-hashes-using-plonky2/15246, https://www.youtube.com/watch?v=t34Pt40COKg).

In general, this actually reduces the proof generation time in terms of protocol and proof allocation. In the exploration of new ZK protocols, reducing the proof time is the most important consideration.

In addition, many efforts have been made to further reduce the proof time at the physical and node levels for ZK applications from the hardware perspective.

First, like the new protocols mentioned before, the ZK protocol is designed to be as hardware friendly as possible, for example HyperPlonk (https://hackmd.io/@omershlo/rJhgKJPtj).

Paradigm mentions (https://www.paradigm.xyz/2022/04/zk-hardware) that the slow proof generation for ZK is mainly due to the large number of MSMs and FFTs involved which are not hardware friendly, resulting in slow final proof generation due to random memory access and other issues. With respect to these underlying cryptographic computations, the ZK protocol requires some trade-offs in their composition and scale (https://www.youtube.com/watch?v=5hO9NbtFc0g&t=3882s) to make it more hardware friendly.

Several ZK hardware acceleration manufacturers (https://www.youtube.com/watch?v=3wLYtzHuu5U&list=PLlcfbEGVTa-gfVw5oz6a3BxAaUvstvxzf) and researchers (https://trapdoortech.medium.com/zero-knowledge-proof-fpga-or-gpu-97b96ffbf0f) have said that GPUs are actually the most economical and configurable hardware option right now, and that we will have FPGAs to transition to the ASIC stage eventually. According to the zk hardware companies, the first version of their ASIC can reduce the ZK proof generation time by at least 30% directly.

In addition, running different cloud servers as nodes may involve different hardware-specific optimizations due to different server configurations (https://twitter.com/ingo_zk/status/1597963357772214272).

Another criticize ZK has right now is the code of circuit still need to be right (no bug). If a ZK protocol is attacked from the Soundness, Completeness, Zero-knowledge perspective, we will no longer have a valid ZK system. We can see examples of attacks from various perspectives at this link (https://kb.delendum.xyz/zk-knowledge#vulnerabilities).

Although a ZK application can be called trustless, we still need to ensure that the project's ZK protocol and the application's code and architecture are correct. There are many kinds of ZK bugs in the blockchain space (https://www.youtube.com/watch?v=FMXTvxo3NsI). For example, Vitalik talks about the need for multi-prover of ZK applications, due to the problem of huge codebase of ZK circuit of zkEVM (https://youtu.be/6hfVzCWT6YI?t=164).

So a ZK system may need to be paired with security tools like Formal Verification (https://medium.com/delendum/formal-verification-of-zk-constraint-systems-ab22f17b0525), or other security related tools like Ecne (https://github.com/franklynwang/EcneProject). Application level, it needs more auditing especially for big projects like zkEVM (https://www.youtube.com/watch?v=WJewE8fdlmU).

In practice (https://mirror.xyz/privacy-scaling-explorations.eth/BaqGMfBhEZR1cvTJlA9E3Xu5ZhD7IthLiUK-Q75rQMM), Ethereum PSE maintains zk bug tracker repo (https://github.com/0xPARC/zk-bug-tracker), which tracks bugs to help auditors quickly find common vulnerability in zk applications. Veridise has done a lot of research and development on formal verification of zk circuits (zk circuits natively can be easily expressed with mathematical formulas, which lend themselves well to formal verification), as well as universal tools for static analysis of zk.