feat(bb): unoptimized blake2b opcode

[ordian]

Summary

• Add a native Blake2b implementation to barretenberg/crypto (C++ API, C bindings, tests, and integration into hashers.hpp).
• Introduce a stdlib Blake2b gadget (Ultra) with 64‑bit helpers: modular add with overflow bound, 64‑bit bit‑decomposition/XOR/rotate, plookup‑based 64‑bit XOR, and the full compression/round function plus fuzzer and tests.
• Wire Blake2b into ACIR: new opcode constraint builder, ACIR serde, gate‑count constant, mocks, and tests so Blake2b is available as a blackbox opcode.
• Register the Blake2b plookup table(s) (64‑bit XOR) and expose the new multitable IDs in types.hpp/plookup_tables.cpp.
• Build system updates to include the new crypto and stdlib targets.

Notable details

• Blake2b round uses 64‑bit add normalization with a small overflow bound and a single XOR plookup per op; rotations are handled in the bit domain.
• Gate count constant for Blake2b opcode set to ~104k (lookup XOR + bit‑rotate path). Extremely unoptimized, but appears to be working.

Fixes #15240

[ludamad]

Hi. We'd need a decent rationale for introducing a new crypto primitive. How much more efficient is this than a pure Noir implementation (preferable if possible)? Can you provide more detail about what project this would enable?

[ordian]

Can you provide more detail about what project this would enable?

See the links in the linked issue. This would enable an Noir integration with Kusama/Polkadot ecosystem as they use blake2b as a primary hash function. Things like state proofs need this.

How much more efficient is this than a pure Noir implementation (preferable if possible)

Given that all hash functions are implemented as an opcode in bb, it seems like there's a decent gap between doing this and a pure Noir impl. The current impl here can be optimized further, but in a follow up work. I'd like to have something minimal and working initially.

[ludamad]

It would be nice from our point of view to see the use-case first fleshed out with a pure Noir prototype as we are in the midst of audits. I will ask around if there is appetite for this, but be aware that we are refining the surface area we provide to just an audited one and we prefer for code to be iterated on in forks or #ifdef code. The starknet proving system variant is one example.

[ludamad]

I have discussed with the broader team and we have decided that at this time to recommend this is explored in vanilla noir code. We welcome you to experiment with a noir and barretenberg fork with these changes, of course, however vanilla noir should be very viable for a prototype. There is plenty of cryptography in pure noir

[ludamad]

Flakey Tests

🤖 says: This CI run detected 2 tests that failed, but were tolerated due to a .test_patterns.yml entry.

\033FLAKED\033 (\0338;;http://ci.aztec-labs.com/758535a544396482758535a5443964828;;\033): yarn-project/end-to-end/scripts/run_test.sh simple src/e2e_p2p/multiple_validators_sentinel.parallel.test.ts "collects attestations for validators in proposer node when block is not published" (147s) (code: 1) group:e2e-p2p-epoch-flakes (\033Aztec Bot\033: feat: merge-train/barretenberg (#18809))
\033FLAKED\033 (\0338;;http://ci.aztec-labs.com/11118c825d8b6b3811118c825d8b6b388;;\033): yarn-project/end-to-end/scripts/run_test.sh simple src/e2e_p2p/inactivity_slash.test.ts (379s) (code: 1) group:e2e-p2p-epoch-flakes (\033Aztec Bot\033: feat: merge-train/barretenberg (#18809))

[ordian]

going to close this for now