-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify proof format #43
Comments
Ugh. I cannot check this because the design totally obscures the length. The serialization of the proof in PourTransaction is here, which ends up delegating to libsnark here. That appears to be using an encoding that includes newlines, which doesn't seem right. (See also zcash/zcash#799 .) |
The serialization of a proof roughly looks like this:
This appears to be 9 points on the curve, which can be compressed to 288 bytes with point compression and binary serialization. |
I enabled point compression and binary serialization and got a proof string with this (hex):
That's 321 bytes. |
Now I'm confused as to which proof system we're using. A BCG+13 proof is 322 bytes: "Given σ and (x, a) in the relation RC, the SNARK prover outputs a proof consisting of 12 group elements (11 in G1 and 1 in G2). The proof length is 2576 bits (322 bytes)." But that's for an 80-bit security level. I thought Zerocash was using a different proof system (BCTV14), in which a proof has 7 G1 elements and 1 G2 element (see Figure 10 of that paper), and is 288 bytes for a 128-bit security level. |
OK, we're definitely using BCTV14 because there are 8 elements in the text serialization. (The third point is from G2 and is twice as long.) Not sure where the extra 33 bytes came from. |
Are you sure it's 321 bytes? I make that string 312 bytes:
|
I may have mismathed. |
I implemented point compression and binary serialization with ALT_BN128, and got 304 byte proofs. Is it possible that the two implementations don't have the same serialization? |
I believe point compression makes for some really slow deserialization of the proving key, something on the order of several minutes. |
Compression of points in a proof should be independent of compression of points in the proving key. The former would not cause a significant performance problem. |
Agreed; however we don't have that flexibility yet. I filed scipr-lab/libsnark#28 for that. |
See also scipr-lab/libsnark#38 |
Fixed in 2016.0-beta-1. |
The current spec and the paper say 288 bytes (2304 bits), but the output of the prover says "Proof size in bits: 2294". I think the prover output is just not taking into account some padding up to byte boundaries, but it needs checking.
The text was updated successfully, but these errors were encountered: