chore(perf): Simplify poseidon2 algorithm

[vezenovm]

Description

Problem*

Resolves

Optimizations found while looking exploring other Brillig opts.

Summary*

There are a couple optimizations here:

1. I noticed that we loop over the cache and do some resetting inside of squeeze of Poseidon2. However, we our Hasher always creates a fresh Poseidon2 object so it seems unnecessary to reset the cache in this way. In Brillig this leads to an extra loop that is essentially unused and blows up the code size of any programs using poseidon in an unconstrained environment.
2. We were writing into a result array and returning it from perform_duplex. This result was unused inside of absorb and we can directly access self.state inside of squeeze. I no longer return anything from perform_duplex.

Additional Context

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.

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 64b93d35bc0288be342717618ca1624393db8423, compared to commit: a764c5be9b15e499e0720f28a1a177bfecbef352

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
fold_numeric_generic_poseidon	-1,130 ✅	-36.66%
no_predicates_numeric_generic_poseidon	-1,130 ✅	-36.66%
poseidon2	-565 ✅	-45.02%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
eddsa	67,507 (-565)	-0.83%
regression_5252	36,021 (-565)	-1.54%
uhashmap	38,908 (-11,888)	-23.40%
hashmap	69,878 (-27,761)	-28.43%
fold_numeric_generic_poseidon	1,952 (-1,130)	-36.66%
no_predicates_numeric_generic_poseidon	1,952 (-1,130)	-36.66%
poseidon2	690 (-565)	-45.02%

[github-actions]

Changes to circuit sizes

Generated at commit: 64b93d35bc0288be342717618ca1624393db8423, compared to commit: a764c5be9b15e499e0720f28a1a177bfecbef352

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hashmap	-1,554 ✅	-0.77%	-1,721 ✅	-0.47%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
hashmap	200,173 (-1,554)	-0.77%	361,203 (-1,721)	-0.47%

[michaeljklein]

LGTM

I wondered whether this could cause issues if someone manually cloned the Poseidon2Hasher struct to provide both the hash of a prefix and the hash of the whole collection efficiently, i.e. hash([a, b, c]) and hash([a, b, c, d, ..]), but the following test both executes w/o error and prints the same results as before:

use std::hash::poseidon2;

fn main() {
    let mut hasher_1 = poseidon2::Poseidon2Hasher::default();
    for _ in 0..128 {
        hasher_1.write(42);
    }
    hasher_1.write(1);

    let mut hasher_2 = poseidon2::Poseidon2Hasher { _state: hasher_1._state };
    for _ in 0..128 {
        hasher_2.write(42);
    }
    let result_1 = hasher_1.finish();
    hasher_2.write(2);
    let result_2 = hasher_2.finish();

    let mut hasher_3 = poseidon2::Poseidon2Hasher::default();
    for _ in 0..128 {
        hasher_3.write(42);
    }
    hasher_3.write(1);

    for _ in 0..128 {
        hasher_3.write(42);
    }
    hasher_3.write(2);

    let result_3 = hasher_3.finish();

    assert(result_2 == result_3);
    println(result_1);
    println(result_2);
}

[guipublic]

LGTM
I just wonder why the code was like this, as if it was done to work also in other 'mode'

[vezenovm]

as if it was done to work also in other 'mode'

Looks like it. But we never use the other "mode" so I figured we should delete it. If we want it back, we can bring it back.