chore: Apply hash abstraction over aztec-nr

[kevaundray]

Rationale in comment below

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[AztecBot]

Benchmark results

No metrics with a significant change found.

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Values are compared against data from master at commit 69c1d663 and shown if the difference exceeds 1%.

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	8 txs	32 txs	128 txs
l1_rollup_calldata_size_in_bytes	45,444	179,588	716,132
l1_rollup_calldata_gas	222,984	868,028	3,447,860
l1_rollup_execution_gas	842,071	3,595,136	22,203,229
l2_block_processing_time_in_ms	1,019 (-2%)	3,885 (-1%)	15,364
note_successful_decrypting_time_in_ms	331 (-2%)	1,026 (-1%)	3,908 (-3%)
note_trial_decrypting_time_in_ms	34.0 (-15%)	108	137 (-1%)
l2_block_building_time_in_ms	8,926 (-1%)	35,675 (-1%)	156,977 (-1%)
l2_block_rollup_simulation_time_in_ms	6,594 (-1%)	26,349	104,951
l2_block_public_tx_process_time_in_ms	2,294 (-2%)	9,201 (-2%)	51,367 (-2%)

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric	5 blocks	10 blocks
node_history_sync_time_in_ms	11,951 (+6%)	22,940 (+5%)
note_history_successful_decrypting_time_in_ms	2,456 (+4%)	4,997 (+4%)
note_history_trial_decrypting_time_in_ms	122	149 (+2%)
node_database_size_in_bytes	1,628,072	1,097,210
pxe_database_size_in_bytes	27,188	54,187

Circuits stats

Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit	circuit_simulation_time_in_ms	circuit_input_size_in_bytes	circuit_output_size_in_bytes
private-kernel-init	47.7 (+1%)	61,697	18,841
private-kernel-ordering	23.4	24,233	8,089
base-rollup	852	639,797	811
root-rollup	38.0	4,072	1,097
private-kernel-inner	42.7	81,504	18,841
public-kernel-private-input	47.9	41,455	18,841
public-kernel-non-first-iteration	31.0 (+1%)	41,497	18,841
merge-rollup	0.884 (+7%)	2,592	873

Miscellaneous

Transaction sizes based on how many contracts are deployed in the tx.

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	8,723	27,510

[kevaundray]

This PR was extracted from #2592 and has the highest likelihood of causing merge conflicts.

Rationale

Previously we were calling pedersen or pedersen_with_separator then taking the x coordinate, in order to hash. This PR extracts that behaviour into one function in hash.nr called pedersen_hash and all other functions call this method from now on. Note: pedersen was implicitly passing the hash_index as 0.

This was done for three reasons:

• Less duplication of the same commit(input)[0] pattern.
• When feat: refactor pedersen hash standard #2592 lands, we want to have a followup PR which modifes the pedersen_hash and having it one place makes this easier
• I removed the domain separator from feat: refactor pedersen hash standard #2592 but once we add it back, then we would need to pass in a string to all calls to pedersen hash which ideally would only be done in one place. We would ultimately have a method that looks like:

use dep::std::hash::pedersen_hash as generic_noir_pedersen_hash;

// Aztec variant of pedersen hash with the "AZTEC" string as a domain separator
fn pedersen_hash<N>(inputs : [Field;N], hash_index : u32) -> Field {
   generic_noir_pedersen_hash("AZTEC", inputs, hash_index)
}

[rahul-kothari]

this looks like a breaking change? If so could you add ! in the PR after chore?

[kevaundray]

I think it shouldn't change any functionality and doesn't modify any function that was exposed before!