What is ZK-conSNARK?

The maximum throughput of a blockchain protocol is mainly determined by the maximum block size and average transaction size, which is further determined by the size of SNARK when it comes to a privacy-preserving blockchain protocol.

There are mainly two types of ZK-SNARK schemes used in the cryptocurrency space:

There are mainly two types of ZK-SNARK schemes:

– Zcash has a constant SNARK size but requires a trusted setup step, the compromise of which will allow the attacker to print infinite amounts of Zcash out of thin air without the possibility of being detected [12, 4].

– Setup-free cryptocurrency such as Monero, Grin, and Beam do not scale well due to their asymptotically larger SNARK size. Their proof size remains logarithmic even after adopting the very elegant Bulletproof technique [7].

We can literally “eat the cake and have it”. We see two routes moving forward to design ZK-ConSNARK schemes:

– The first possible direction is by combining probabilistically verifiable proofs with the recently-proposed efficient subvector commitment [8, 5] scheme over groups of unknown order. However, the prover, in this case, might have to perform redundant computation to guarantee the soundness of ZK-SNARK. On the other hand, when the statement of ZK-SNARK is as specific as a confidential transaction with range proof, this extra computational overhead might be acceptable. On the other hand, we are also working on a tailored design of confidential transaction by drawing inspiration from similar schemes based on the RSA group.

– We can also base our ZK-ConSNARK scheme on the recently-proposed Spartan scheme [11]. The Spartan is a succinct variant of the sum-check protocol, which is run with a low-degree polynomial encoding a circuit satisfiability instance. Their proof size is k×n^{−c}, where n is the size of the arithmetic circuit and k is a small constant.

It is possible to achieve almost constant SNARK size using the Spartan framework since our confidential payment scheme has a pretty simple statement for the underlying SNARK scheme and c can be chosen to be sufficiently large.

Since the core technical functionality of our system is an anonymous payment mechanism for smart contract platforms, applying the existing ZK-ConSNARK to our system is non-trivial. The interested user can check our yellow paper [Lin19] to find out how this can be done.

[Lin19] Dr. Lin. Suterusu Yellowpaper 1.0. https://github.com/suterusu-team/Suter_yellowpaper.