In the recent study “Survey of Confidentiality and Privacy Preserving Technologies for Blockchains” in section 2.10 mention is made of the computational inefficiency of zk-SNARKs and the need to optimize in this area. Is this an area of significant concern for future growth and scalability with plans to address it? Benchmarking of processing time of 48 seconds in a typical PC is documented so there would have to be extensive optimization to allow for sub-second performance which would be required for wide spread adoption.
2 Likes
Interesting questions. Hopefully Zooko can clear it up, as his name is on the paper.
You can see in this query that we have lots of ideas for improving performance of the Zcash circuit. single pour input, value commitment scheme · Issue #647 · zcash/zcash · GitHub and implement two-stage pour proofs. · Issue #43 · zcash/zcash · GitHub are particularly promising. As well as improving the circuit, there are other ways to optimize the implementation of the proving system.
I disagree somewhat that sub-second performance of proving is necessary for widespread adoption. Note that the most important measure of performance is the latency that the user experiences between confirming a payment and the payee accepting it. That’s only indirectly related to the overall proving time, since most of a payment proof could potentially be precomputed. Also the latency of on-chain payments is constrained by block confirmation times, so some form of micropayment or channel-based scheme (and/or techniques for improving the security of zero-conf on-chain payments, such as double-spend proofs) is necessary for very low latency. It isn’t the proving system that is the main constraint on this.
5 Likes
Also keep an eye on https://speed.z.cash/timeline/ . The performance measurement for this particular question is https://speed.z.cash/timeline/?exe=1&base=1%2B9&ben=time+createjoinsplit&env=1&revs=1000&equid=off&quarts=on&extr=on
3 Likes