IPA over Grumpkin #51
Conversation
| for (uint256 index = 0; index < r_vec.length; index++) { | ||
| // b"L" in Rust | ||
| label[0] = 0x4c; | ||
| transcript = KeccakTranscriptLib.absorb(transcript, label, input.L_vec[index].x); |
There was a problem hiding this comment.
So in arecibo, I could find the implementation of Keccak256Transcript::absorb and the use of to_transcript_bytes but I could not find the implementation for the latter for CompressedCommitment.
Why is it that we only need to absorb the x of the curve point and not x+y+infinity_byte as we are in a lot of our implementations in arecibo?
There was a problem hiding this comment.
The implementation of to_transcript_bytes for CompressedCommitment is indeed hidden in following macro. As far as I know, all the necessary information about y coordinate is already stored in x.
Compression / uncompression of EC points is one of the boring thing in our codebase (@huitseeker is aware of it). from one side we want to keep proof size as smaller as possible (hence compression is our friend). On the other hand some cryptographic operations can be performed only with points in uncompressed form
There was a problem hiding this comment.
The implementation of to_transcript_bytes for CompressedCommitment is indeed hidden in following macro.
Thanks! I understand now that it trace all the way to the defined Compressed type which in our case is the G1Compressed structure defined through the usage of the new_curve_impl macro in the halo2 crate.
As far as I know, all the necessary information about y coordinate is already stored in x.
So from what I get of your sentence and a few research, the compressed point is the data of x along with a sign bit that is derived from the y value of an affine point. And it seems that this is what we absorb in the Rust implementation. Aren't we missing the sign bit then? Or do we not need it?
There was a problem hiding this comment.
I think sign is also encoded in the information behind x (consider from_bytes function in halo2curves). The field element for Bn256 (and Grumpkin) have 254 bits in size (link), while x is uint256, which is 256 bits - so we have two bits for the metadata and by absorbing whole uint256 we absorb sign as well.
For the uncompressed commitment (which is essentially a Grumpkin affine point with two coordinates) we have different absorb where we put x, y and an extra-byte representing whether point is infinity (usually this is not the case, so this is 0x00) to the transcript's memory.
There was a problem hiding this comment.
I believe the authoritative format for this conversion is in SECG1, section 2.3.3. read with compression active.
This PR implements InnerProductArgument PCS over Grumpkin.
The implementation is quite dense, so please review it carefully.
The reference one is: https://github.com/lurk-lab/arecibo/tree/d65918097724e7b9e3d63e7e7db55c43d9e6e7cd
TBD in next PR: #52