# Is there concern for Zcash scalability due to zk-SNARKs processing inefficiency? **URL:** \ **Category:** Technology\ **Created:** [March 21, 2017, 1:32am UTC](https://forum.zcashcommunity.com/t/is-there-concern-for-zcash-scalability-due-to-zk-snarks-processing-inefficiency/14844 "2017-03-21T01:32:34Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![edstewbob](https://avatars.discourse-cdn.com/v4/letter/e/e274bd/32.png) [@edstewbob](https://forum.zcashcommunity.com/u/edstewbob)\ **Post date:** [March 21, 2017, 1:32am UTC](https://forum.zcashcommunity.com/t/is-there-concern-for-zcash-scalability-due-to-zk-snarks-processing-inefficiency/14844/1 "2017-03-21T01:32:34Z")
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. ---
**Author:** ![tearo](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/tearo/32/2287_2.png) [@tearo](https://forum.zcashcommunity.com/u/tearo)\ **Post date:** [March 21, 2017, 2:54pm UTC](https://forum.zcashcommunity.com/t/is-there-concern-for-zcash-scalability-due-to-zk-snarks-processing-inefficiency/14844/2 "2017-03-21T14:54:51Z")
Interesting questions. Hopefully Zooko can clear it up, as his name is on the paper. ---
**Author:** ![daira](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/daira/32/43253_2.png) [@daira](https://forum.zcashcommunity.com/u/daira)\ **Post date:** [March 21, 2017, 8:38pm UTC](https://forum.zcashcommunity.com/t/is-there-concern-for-zcash-scalability-due-to-zk-snarks-processing-inefficiency/14844/3 "2017-03-21T20:38:36Z")
You can see in [this query](https://github.com/zcash/zcash/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20label%3A%22performance%22%20label%3A%22zkSNARK%20circuit%22) that we have lots of ideas for improving performance of the Zcash circuit. [single pour input, value commitment scheme · Issue #647 · zcash/zcash · GitHub](https://github.com/zcash/zcash/issues/647) and [implement two-stage pour proofs. · Issue #43 · zcash/zcash · GitHub](https://github.com/zcash/zcash/issues/43#issuecomment-286803090) 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. ---
**Author:** ![zooko](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/zooko/32/32232_2.png) [@zooko](https://forum.zcashcommunity.com/u/zooko)\ **Post date:** [March 23, 2017, 1:15am UTC](https://forum.zcashcommunity.com/t/is-there-concern-for-zcash-scalability-due-to-zk-snarks-processing-inefficiency/14844/4 "2017-03-23T01:15:42Z")
Also keep an eye on [https://speed.z.cash/timeline/](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](https://speed.z.cash/timeline/?exe=1&base=1%2B9&ben=time+createjoinsplit&env=1&revs=1000&equid=off&quarts=on&extr=on)