R1CS PPZKSNARK verifying knowledge of preimage of hash

418 views
Skip to first unread message

ma...@appliedblockchain.com

unread,
Aug 24, 2018, 8:24:23 AM8/24/18
to libsnark
Hello!

First of all thank you for creating libsnark! I'm still trying to wrap my head around it and zero-knowledge proofs/zk-SNARKs in general, so please excuse my probably rather noob question. I'm trying to get a simple example set up, a circuit that verifies the knowledge of a preimage of a SHA256 hash. Eventually I want to verify the proof on Ethereum. What I did was take the test for the SHA256 gadget (https://github.com/scipr-lab/libsnark/blob/3e92af18df7ea11588c9e59769e78dc7bc7ad4d9/libsnark/gadgetlib1/gadgets/hashes/sha256/tests/test_sha256_gadget.cpp) and put it into the scheme provided by Christian Lundkvist's tutorial (https://github.com/christianlundkvist/libsnark-tutorial). (Can I even do this?) What I have now is this: https://github.com/mariogemoll/libsnark-tutorial/blob/sha256/src/test-knowledge-of-preimage.cpp . It somehow works, as in the verification passes, and when I change any of the inputs the verification fails (as it should). However I think there is something wrong with the "wiring", pb.primary_input().size() is just 1. Would be great if anyone could have a look and tell me what I'm missing. Thanks!

Mario

S Fanghao

unread,
Mar 27, 2019, 10:36:30 AM3/27/19
to libsnark
Hi Mario,

Really appreciate your post.
Do you still have the same problem? I have the same problem right now. 

Thank you.
Fanghao

在 2018年8月24日星期五 UTC-4上午8:24:23,ma...@appliedblockchain.com写道:

ma...@appliedblockchain.com

unread,
Mar 27, 2019, 5:18:18 PM3/27/19
to libsnark
Hi Fanghao,

I just updated the code at https://github.com/mariogemoll/libsnark-tutorial/tree/sha256 , it should work now. It wasn't too far off actually but a few bits were wrong/missing. Some things to note:
- The number of public inputs is set explicitly through pb.set_input_sizes(num_public_inputs).
- In the original code the correct number of public inputs would have been 256 (the number of bits in the hash). That would have resulted in a very costly verification (I tried a bit but didn't get it to run on Ethereum). However what one can do is make all the bit inputs private and add two public inputs which are their representation as two 128 bit numbers (because of the size of the underlying field they need to be split into two 128 bit values). The "multipacking" gadget adds the constraints that these numbers match the hash bits in the private inputs.

Hope that helped!

Mario
Reply all
Reply to author
Forward
0 new messages