Can Prover Witness Wires serve as NIZKInputs in pinocchio?

[yylluu]

Hi Ahmed,

Great project! Thanks a lot for such a contribution. Please excuse me that there might be a naive question.

I have look at the FieldDivision example and find the prover_witness_wire seems to be directed to output. I read your document and am thinking any output will be public to the verifier. As a result, will the prover_witness_wire in that example become public?

If the prover_witness_wire in that example is public, is it possible to make a prover_witness_wire as a secret one, like NIZKInput does in Pinocchio? For example, a prover has ten numbers, and she only would like to convince the verifier their average instead of leaking these numbers. Will prover_witness_wires work in this scenario?

[akosba]

Hi Yuan,

Thanks for your interest in jsnark.

Prover witness wires are secret by default (similar to Pinocchio's NIZKInput) and are not revealed to the verifier, unless the programmer chooses to make them part of the public statement (as in the example you are referring to), or of course in the case that the verifier can figure their values out by running the computation itself if possible.

In the division example, secrecy is not important, and the verifier can figure out the witness value as long as the inputs are public. The purpose of introducing a prover witness wire here was to show how to do some things in a more efficient way when you are writing circuits for zk-SNARKs. In cases like this, the programmer does not have to compute the result in the circuit, but it's possible to introduce the solution as a witness and just verify one or more constraints about it.

On the other hand, if you give a look to the example here: you will see prover witness wires created in the beginning. These are going to remain secret in this example, and what will only be public are their hashes as computed by the gadgets. In other words, the circuit here proves the knowledge of SHA-2 preimages in this example among other things.

[yylluu]

Thanks so much for your kindly explaining. It really helps me a lot.

[hasinitg]

Hi Ahmed @akosba

I was trying to understand the last part of your above reply. You have mentioned:

the circuit here proves the knowledge of SHA-2 preimages in this example among other things.

I went trough the referenced circuit: AugmentedAuctionCircuitGenerator, to understand how it proves the knowledge of SHA-2 preimages. However, what that circuit does (among other things) is, computing set of SHA256 digests of (concatenated) secrets. Those digests serve as commitments for parties' input and output balances. Here, the verifier learns the SHA256 digests of 'some' concatenated secrets. But that does not prove to the verifier that the prover knows the correct pre-images of any given SHA256 digests. Therefore, I am bit confused about what kind of zero-knowledge proof is expected by the augmentation work done by the aforementioned circuit.

Is this the expected way of proving the knowledge of SHA-2 preimages?

Thank you very much! I would appreciate a lot any clarifications.

[akosba]

Is this the expected way of proving the knowledge of SHA-2 preimages?

There can be more than one way.

1. You can let the expected digest be an input to the circuit, and let the prover provide the preimage as a witness. You can then compute the digest of the prover's witness and finally assert the equality of both the expected and computed digests. I guess this is the approach you have in mind. Here, the statement will be (input: {expected digest}, output: {}). (By the statement here, I mean the public I/O that the verifier sees).
2. Another way is not to provide any input to the circuit, let the prover provide a preimage as a witness, and just make the statement include the output of the gadget directly. Now, the prover will have the freedom to produce any valid proof for any digest, but simply the verifier won't accept the proof and the statement unless the statement looks like this: statement = (input= {}, output = {expected digest}). In other words, we moved the assertion away from the circuit, and will only accept a statement that has a specific property. If the prover sends a valid proof for that particular statement, it will mean that it knows the preimage.

Both methods achieve the requirement. The first one looks easier to follow, and the second saves the coding of few checks/adding input wires.

If you go through the jsnark-libsnark C++ interface code, you will find that both the input and outputs of the circuit are mapped to "primary input" in libsnark (as mentioned in the jsnark readme), i.e. both kinds of wires are eventually dealt with in a similar manner.

[hasinitg]

Thank you very much Ahmed @akosba for the detailed explanation. I appreciate it a lot.