feat: Sha256 refactoring and benchmark with longer input

[aakoshh]

Description

Problem*

Preparation for #6304

Summary*

Preparation for changing the message block type in sha256.nr:

• Added some type aliases and extra comments, rearranged some functions
• Added a new benchmark program with longer input so that we exercise the iteration and the last partial block as well
• Running the criterion benchmarks with and without the --force-brillig option, to cover what the AVM would do
• Added an option to the stdlib-tests.rs to pass a filter for test names

This is purely to make it a bit easier to see what is going on and to establish some baseline before trying to make changes.

Tried to rationalise the code a bit:

• Removed pad_msg_block: based on the constraints put on its results it looked like it's forbidden from doing anything. This allows the removal of some constraints because for example msg_block and last_block are equal by definition. Here's just that diff.
• Moved the verification of padding with zeroes after the input into the verify_block_msg_padding function. This is only called for the last (partially filled) block.

According to the Circuit Size report below 👇 there is a 33% reduction in the number of ACIR opcodes in some of the SHA256 benchmarks.

Testing

cargo test -p nargo_cli --test stdlib-tests -- run_stdlib_tests sha256
cargo test -p nargo_cli --test stdlib-props fuzz_sha256

Benchmarking

cargo bench -p nargo_cli --bench criterion sha256_long

The baseline benchmarks on my machine as of c600000 were as follows:

❯ cargo bench -p nargo_cli --bench criterion sha256_long
...
bench_sha256_long_execute
                        time:   [1.3613 ms 1.3688 ms 1.3782 ms]
bench_sha256_long_execute_brillig
                        time:   [286.64 µs 287.67 µs 288.96 µs]

For some reason after merging master into the PR the performance is worse in 636c9e9

❯ cargo bench -p nargo_cli --bench criterion sha256_long
...
bench_sha256_long_execute
                        time:   [1.7297 ms 1.7918 ms 1.8675 ms]
                        change: [+27.365% +29.911% +32.673%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 2 outliers among 20 measurements (10.00%)
  2 (10.00%) high severe

bench_sha256_long_execute_brillig
                        time:   [354.12 µs 360.31 µs 368.45 µs]
                        change: [+22.390% +24.264% +27.161%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 1 outliers among 20 measurements (5.00%)
  1 (5.00%) high severe

Maxim: We did just sync aztec packages which now conditionally inlines functions (we previously used to always inline functions). This may be the cause of some execution time increases.

Here's the diff between those commits.

Additional Context

In a follow-up PR I'll try to change the type of msg_block from [u8; 64] to [u32; 16] to avoid having to call msg_u8_to_u32. This should at least have the benefit of copying the array fewer times: at the moment an array copy is made every time an item in it is written to; with 16 items instead of 64 we get up to 4x less copies.

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: b0554a626ba85b9ca92ce09024a59f2ea5bd6ec7, compared to commit: 8dec84793d200dcb524aa5c397d0a84d38974e7e

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
conditional_regression_short_circuit	-101 ✅	-7.61%
sha256_var_witness_const_regression	-101 ✅	-7.88%
sha256	-151 ✅	-8.08%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
sha2_byte	3,105 (-51)	-1.62%
brillig_cow_regression	2,209 (-51)	-2.26%
conditional_1	1,207 (-51)	-4.05%
sha256_regression	6,609 (-301)	-4.36%
array_dynamic_blackbox_input	1,106 (-51)	-4.41%
sha256_var_size_regression	1,812 (-101)	-5.28%
ecdsa_secp256k1	911 (-51)	-5.30%
array_dynamic_nested_blackbox_input	887 (-51)	-5.44%
6	1,656 (-101)	-5.75%
sha256_var_padding_regression	4,735 (-301)	-5.98%
regression_4449	757 (-51)	-6.31%
brillig_sha256	698 (-51)	-6.81%
conditional_regression_short_circuit	1,227 (-101)	-7.61%
sha256_var_witness_const_regression	1,180 (-101)	-7.88%
sha256	1,717 (-151)	-8.08%

[github-actions]

Changes to circuit sizes

Generated at commit: b0554a626ba85b9ca92ce09024a59f2ea5bd6ec7, compared to commit: 8dec84793d200dcb524aa5c397d0a84d38974e7e

🧾 Summary (10% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
regression_4449	-8,820 ✅	-33.32%	-10,395 ✅	-3.40%
bench_sha256_30	-3,870 ✅	-33.14%	-4,727 ✅	-3.56%
bench_sha256_100	-12,900 ✅	-33.15%	-15,752 ✅	-3.63%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
sha256_regression	39,233 (+52)	+0.13%	202,513 (-189)	-0.09%
sha2_byte	20,161 (-129)	-0.64%	93,861 (-159)	-0.17%
sha256_var_padding_regression	14,288 (-774)	-5.14%	208,517 (-395)	-0.19%
ecdsa_secp256k1	638 (-129)	-16.82%	43,707 (-105)	-0.24%
sha256_var_witness_const_regression	2,138 (+155)	+7.82%	18,205 (-47)	-0.26%
array_dynamic_blackbox_input	1,732 (-258)	-12.96%	22,680 (-131)	-0.57%
sha256	2,436 (+26)	+1.08%	22,398 (-205)	-0.91%
conditional_1	4,496 (-129)	-2.79%	12,698 (-152)	-1.18%
array_dynamic_nested_blackbox_input	367 (-129)	-26.01%	7,966 (-155)	-1.91%
bench_sha256	269 (-129)	-32.41%	7,672 (-158)	-2.02%
conditional_regression_short_circuit	591 (-258)	-30.39%	11,923 (-306)	-2.50%
6	563 (-258)	-31.43%	11,897 (-308)	-2.52%
sha256_var_size_regression	17,682 (-1,552)	-8.07%	72,507 (-2,090)	-2.80%
regression_4449	17,647 (-8,820)	-33.32%	295,719 (-10,395)	-3.40%
bench_sha256_30	7,809 (-3,870)	-33.14%	128,030 (-4,727)	-3.56%
bench_sha256_100	26,009 (-12,900)	-33.15%	418,546 (-15,752)	-3.63%

[TomAFrench]

LGTM, Good spot on pad_msg_block