Skip to content

Conversation

@akoidefi
Copy link

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.

@akoidefi akoidefi marked this pull request as draft December 18, 2025 14:21
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.
@akoidefi akoidefi marked this pull request as ready for review December 18, 2025 14:24
@markosg04 markosg04 self-requested a review December 18, 2025 15:07
Copy link
Collaborator

@markosg04 markosg04 left a 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.

Comment on lines 47 to 49
fn hasher() -> Poseidon<Fr> {
Poseidon::<Fr>::new_circom(POSEIDON_WIDTH).expect("Failed to initialize Poseidon")
}
Copy link
Collaborator

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.

Copy link
Author

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.

@akoidefi akoidefi force-pushed the feat/poseidon-hash branch from 57e10ed to b46cfbb Compare January 8, 2026 00:50
- 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.
@akoidefi akoidefi force-pushed the feat/poseidon-hash branch from b46cfbb to 34e0e30 Compare January 8, 2026 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants