feat(test): Fuzz test poseidon2 hash equivalence

[aakoshh]

Description

Problem*

Related to #6141

Summary*

Adds a fuzz test for poseidon2.nr comparing the results to bn254_blackbox_solver::poseidon_hash, which says it's "Performs a poseidon hash with a sponge construction equivalent to the one in poseidon2.nr"

To pass the test the Rust implementation was given a new is_variable_length parameter to inform it whether it needs to append an extra 1 like Noir and Berratenberg do.

Additional Context

The test initially failed:

❯ cargo test -p nargo_cli --test stdlib-props poseidon
  
test fuzz_poseidon2_equivalence ... FAILED

---- fuzz_poseidon2_equivalence stdout ----
Test failed: assertion failed: `(left == right)` 
  left: `Field(1187863985434533916290764679013201786939267142671550539990974992402592744116)`, 
 right: `Field(11250791130336988991462250958918728798886439319225016858543557054782819955502)`: max_len = 1 at tooling/nargo_cli/tests/stdlib-props.rs:106.
minimal failing input: io = SnippetInputOutput {
    description: "max_len = 1",
    inputs: {
        "input": Vec(
            [
                Field(
                    0,
                ),
            ],
        ),
        "message_size": Field(
            0,
        ),
    },
    expected_output: Field(
        11250791130336988991462250958918728798886439319225016858543557054782819955502,
    ),
}

So we pass in input = [0; 1] with message_size=0. It fails because the Noir code treats the case where the message_size is different from the maximum length differently by appending an extra 1, to keep variable and fixed length hashes distinct. The Rust implementation doesn't do this, nor did the other hashes tested so far. I'm not sure if it's worth noting that the hash will not depend on how much shorter the message is than the maximum, just that it's shorter.

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[TomAFrench]

This appending of 1 matches with the barretenberg implementation of poseidon2 so looks like the issue is that we're not telling the rust impl to do this also. We could modify poseidon_hash but also could modify the fuzz test so that we just append 1 to the input there.

[aakoshh]

Okay, so as I understand the Rust implementation should be able to perform the same hash, but it needs a hint because it takes a slice and cannot tell if it's dealing with variable length data.

We could ... also could modify the fuzz test so that we just append 1 to the input there.

Unfortunately that would result in a change in the IV, which depends on the input length.

I'll add some other function to the module and document this gotcha.

I was trying to find external implementations of Poseidon2 to test with. For example there is this one which we might be able to configure for bn254, but it's not obvious for me what the configuration are as it takes more parameters than ours. Do you think it's worth pursuing this, or if the Noir parts on top of the foreign permutation agree with the Rust parts then we're okay?

[TomAFrench]

Ah yeah, that was a brainfart. If we could manipulate the input to emulate this it would be a pretty useless method to distinguish between fixed and variable length inputs. Adding a variable length variant to the implementation in the solver is the way to go then.

I was trying to find external implementations of Poseidon2 to test with. For example there is this one which we might be able to configure for bn254, but it's not obvious for me what the configuration are as it takes more parameters than ours. Do you think it's worth pursuing this, or if the Noir parts on top of the foreign permutation agree with the Rust parts then we're okay?

I think matching with barretenberg is the most important consideration for us as we're going to want to agree with the hashes as outputted by them.

[aakoshh]

I added a parameter to the Rust function to match Noir; couldn't think of a more elegant way to do it.

Perhaps it's worth taking a note that Barretenberg has a variable and a fixed length variant of the hash function, while Noir decides based on the actual input length. That is, one can call hash_variable_length in Barretenberg with an array that just happens to be as long as the N is, but in theory it could be less, and then Noir would treat it as if it was fixed length without a doubt. So the caller of the C++ code has to know N and do the if/then/else on their side, or Noir would have to have two methods as well.

[aakoshh]

I couldn't actually find anything calling hash_variable_length. OTOH poseidon2::hash calls hash_fixed_length but says it should "just call the variable length" 🤷‍♂️

[TomAFrench]

LGTM!

[aakoshh]

FWIW I found we already have a test against an external implementation, showcasing the mapping of configuration as well (it's the same library I found above).