-
Notifications
You must be signed in to change notification settings - Fork 279
feat: add Poseidon transcript #1173
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
base: main
Are you sure you want to change the base?
Conversation
Adds PoseidonTranscript using light_poseidon over BN254. Uses width-3 Poseidon to include n_rounds in every hash call for domain separation, same as Blake2b/Keccak. Chunks large inputs into 32-byte pieces since Poseidon has fixed-width inputs. Gated behind transcript-poseidon feature flag.
1212e6b to
c897f74
Compare
markosg04
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent job! Just have one question about the usage of Fr.
| fn hasher() -> Poseidon<Fr> { | ||
| Poseidon::<Fr>::new_circom(POSEIDON_WIDTH).expect("Failed to initialize Poseidon") | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
light-poseidon seems to rely on trait PrimeField from arkworks.
I think it is fine to couple to arkworks for now, especially if this is the best poseidon lib. Ideal world is that this would be generic over F: JoltField, which I don't think we can achieve. Maybe if it was over generic like F: PrimeField then it's easier to swap to Fq or BLS fields later.
Do you foresee any problems with fixing Fr in a snark composition context? In snark composition, sum-checks are over Fq (BN254 base field), and in this implementation we interpret all bytes as arkworks Fr. My hunch is that it's fine, but I wonder if there could be some weird attacks since Fq modulus is larger than Fr (a tiny number of collisions). Probably this fact is not really exploitable, but maybe worth a bit of thought.
if we make generic over F: PrimeField we could probably avoid this by just using Fq when the sum-check is working with Fq.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good catch. I'll make it generic on F: PrimeField.
Co-authored-by: Markos <[email protected]>
57e10ed to
b46cfbb
Compare
- Add PoseidonParams<F> trait for type-level parameter configuration - Implement FrParams (uses new_circom) and FqParams (generated params) - Add poseidon_fq_params.rs with BN254 Fq parameters (128-bit security) - Create type aliases PoseidonTranscriptFr and PoseidonTranscriptFq - Fq params generated with poseidon-paramgen v0.4.0 (audited by NCC Group) This enables SNARK composition where sumchecks operate over Fq.
b46cfbb to
34e0e30
Compare
Adds PoseidonTranscript using light_poseidon over BN254.
Uses width-3 Poseidon to include n_rounds in every hash call for domain separation, same as Blake2b/Keccak. Chunks large inputs into 32-byte pieces since Poseidon has fixed-width inputs.
Gated behind transcript-poseidon feature flag.