feat: poseidon port

[iammadab]

Latest Benchmarks

Old Poseidon

• 2 to 1 hash: 4.4820 µs
• 60 to 1 hash: 23.615 µs

Poseidon Port (before changing x.square() to x * x)

• 2 to 1 hash: 1.5236 µs
• 60 to 1 hash: 12.114 µs

Poseidon Port (current)

• 2 to 1 hash: 1.3905 µs
• 60 to 1 hash: 11.177 µs

Plonky2 Poseidon

• 2 to 1 hash: 1.0108 µs
• 60 to 1 hash: 8.1342 µs

[iammadab]

Underlying field benchmarks

plonky add time: [316.34 ps 319.03 ps 323.61 ps]
ceno add time: [316.63 ps 317.28 ps 317.96 ps]

plonky mul time: [315.96 ps 319.49 ps 326.42 ps]
ceno mul time: [316.42 ps 319.67 ps 325.48 ps]

plonky square time: [315.50 ps 316.08 ps 316.72 ps]
ceno square time: [318.17 ps 320.28 ps 323.67 ps]

Rough field op count estimate (for one permutation)

• N_ADD: 251
• N_MUL: 357
• N_SQUARE: 236

[iammadab]

Changing x.square() to x * x improves our time from

2 to 1 hash: 1.5236 µs
60 to 1 hash: 12.114 µs

to:

2 to 1 hash: 1.3905 µs
60 to 1 hash: 11.177 µs

[bgillesp]

Hi there, I'm giving this PR a look today and tomorrow. A couple questions:

• Is this code based on a previous implementation of Poseidon, and if so where?
• Are the constants newly generated or imported?

[iammadab]

Hi there, I'm giving this PR a look today and tomorrow. A couple questions:

• Is this code based on a previous implementation of Poseidon, and if so where?
• Are the constants newly generated or imported?

Hi @bgillesp, the port comes from plonky2 https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/hash/poseidon.rs

[bgillesp]

Looks solid to me! I made sure to compare with the Plonky2 source material fairly carefully, and none of the suggested changes are correctness issues.

[bgillesp]

Consider changing this function signature to use a tuple input instead of two separate input parameters -- this is the convention used in similar functions in Plonky2 (including reduce_u160 and add_u160_u128 imported just above this), and will make the interfaces more consistent. Something like

fn from_noncanonical_u96((n_lo, n_hi): (u64, u32)) -> Self;

[iammadab]

This didn't work, cannot use patterns under trait definition, getting the following error: error[E0642]: patterns aren't allowed in functions without bodies

[bgillesp]

Totally right, I guess the syntax here should just be

fn from_noncanonical_u96(n: (u64, u32)) -> Self;

Looks like there are only three references to this declaration so far in poseidon.rs and poseidon_goldilocks.rs that would need to be updated if you're okay with change in the function signature.

[iammadab]

@bgillesp resolved all comments except for tuple input in the function signature, please have a look again.

[bgillesp]

Revisions look good to me! Take a look at the alternate syntax I mentioned for the from_noncanonical_u96 signature in AdaptedField, but aside from that the PR seems ready to go.

I might also take a quick look now to see if I can hunt down anything that might explain the performance difference between the Plonky2 Poseidon benchmarks and this port.

[bgillesp]

Initial look at the benchmarks is a bit mystifying: broke down the parts of the permutation bench into full rounds and partial rounds, and both of these are slower in the Ceno port. Further benchmarked the parts of a full round -- the round constant update, the monomial S-box, and the MDS matrix transform -- and strangely, at this level the performance difference vanished.

Probably would be worth applying some more in-depth analysis tools to the respective Poseidon::full_rounds functions to see what is going on. If I have time soon I might give it a look, but I don't have a ton of background in this level of optimization if there's anyone else who already knows the right tools.

[bgillesp]

Changing review status to Approve now, though it would be nice to know what is causing the performance regression -- perhaps we can make an issue if it turns out to be difficult to resolve.

[kunxian-xia]

@iammadab Can you resolve the merge conflict so that we can merge it ?