feat!: autogenerate compute_note_hash_and_nullifier

[nventuro]

Closes #2918.

This adds a new macro function that processes the unresolved trait impls and injects a new function before name resolution takes place. This lets us leverage the parser and write the function in Noir instead of having to deal with more complicated processed objects.

In order to find all of the note types we look for impls of the NoteInterface trait. This is a bit more involved than it seems, since other crates may also have structs that impl this trait, and those will have already been processed. We rely on the fact that the contract crate is processed last, and search for external crate impls via the NodeInterner and internal ones in the unresolved functions. This method is robust as long as we do the contract crate after all of its imports, which holds because the imports are recursively collected from the root crate.

I also added a small escape hatch mechanism by skipping any code generation if the function is already defined by the user. This could use some polishing since it is possible for the user to e.g. provide the function but get the arity or parameter types wrong, in which case they'd get a duplicate definition error. Diagnosis and error messages can be improved here (#4647), but I think a simple mechanism is sufficient for now.

---

Minor issues

• One of the function arguments is a fixed-size array, which should be as big as the largest note length. We are not yet pulling the note length (refactor(AztecMacro): Correctly determine the maximum serialized note length #4649), so I'm passing a hardcoded value for now. 12 Fields ought to be enough for anyone.

• Doing this introduces an implicit dependency on AztecAddress on all contracts. This won't be an issue once feat: Aztec prelude #4496 is in, but I did have to manually add it to some of the account contracts for now.

• I created a new macro function that is called on each crate after collection but before resolution. Due to some internal compilers shenanigans (mostly who holds mut references to what) I chose to specialize this function so that for now it only passes the collected unresolved functions, making it a bit niche for the current use case. @vezenovm and I are planning to generalize this down the road (Generalize process_unresolved_traits_impls macro function #4653).

• I'm now importing in the macro from some places that were not previously used, notably the HIR and Noir errors. I am not sure if we might want to pull those differently - I simply imported what I needed.

• I also introduced some getters to provide mutable access to private fields of the HIR Context and CrateDefMap. This is because we need to modify the contract module in the def map by declaring the new function (which is how we get things like duplicate definition detection). We're already mutating the HIR Context in the macros, so also mutating its members doesn't feel like a stretch.

• Finally, I don't know enough about how Noir errors work to know how to produce a useful Location value for the new function, if indeed that can be done. Providing an empty span seems to at least not cause weird errors on the LSP plugin, so that's how I left it for now.

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_history_successful_decrypting_time_in_ms (5): 1,391 (-39%)
• note_history_successful_decrypting_time_in_ms (10): 2,712 (-41%)
• note_history_trial_decrypting_time_in_ms (5): 164 (+87%)
• note_successful_decrypting_time_in_ms (8): 218 (-50%)
• note_successful_decrypting_time_in_ms (32): 600 (-38%)
• note_successful_decrypting_time_in_ms (128): 2,125 (-41%)

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 e63f0226 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	46,020	181,668	724,260
l1_rollup_calldata_gas	226,992	888,696	3,535,848
l1_rollup_execution_gas	321,178	1,008,144	3,757,249
l2_block_processing_time_in_ms	1,193 (-1%)	4,487	17,775
note_successful_decrypting_time_in_ms	⚠️ 218 (-50%)	⚠️ 600 (-38%)	⚠️ 2,125 (-41%)
note_trial_decrypting_time_in_ms	29.3 (-30%)	137 (+30%)	173 (-2%)
l2_block_building_time_in_ms	18,403 (+1%)	72,967 (+1%)	292,593 (+1%)
l2_block_rollup_simulation_time_in_ms	13,595 (+1%)	53,847 (+1%)	216,527 (+1%)
l2_block_public_tx_process_time_in_ms	4,776 (+2%)	19,041 (+2%)	75,777 (+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	15,316 (-4%)	28,588 (-6%)
note_history_successful_decrypting_time_in_ms	⚠️ 1,391 (-39%)	⚠️ 2,712 (-41%)
note_history_trial_decrypting_time_in_ms	⚠️ 164 (+87%)	207 (-17%)
node_database_size_in_bytes	17,289,296	33,239,120
pxe_database_size_in_bytes	29,923	59,478

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	331 (+1%)	44,664	25,409
private-kernel-ordering	196	43,729	16,289 (+1%)
base-rollup	1,467 (+1%)	129,870	933
root-rollup	83.2 (+1%)	4,192	825 (+13%)
private-kernel-inner	433	71,051	25,409
public-kernel-private-input	246 (+2%)	33,895 (+1%)	27,041
public-kernel-non-first-iteration	241 (+1%)	33,937 (+1%)	27,041
merge-rollup	7.80	2,712	933

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric	1 leaves	2 leaves	8 leaves	16 leaves	32 leaves	128 leaves	64 leaves	512 leaves	1024 leaves	2048 leaves	8192 leaves
batch_insert_into_append_only_tree_16_depth_ms	10.2 (-1%)	11.3 (+2%)	12.7	16.8 (-3%)	23.0 (+1%)	64.3	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.9	17.5	23.0	31.6	47.0	143	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.593 (-1%)	0.629 (+2%)	0.541	0.517 (-3%)	0.481 (+1%)	0.443	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	N/A	N/A	N/A	75.3 (-1%)	47.6 (-1%)	240	461 (-2%)	906 (+1%)	3,576 (+1%)
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	N/A	N/A	N/A	159	96.0	543	1,055	2,079	8,223
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	0.465 (-1%)	0.488 (-1%)	0.437	0.431 (-2%)	0.432 (+1%)	0.430 (+1%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	104	57.1 (+1%)	352	687 (-1%)	1,369	5,446
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	N/A	N/A	N/A	197	104	691	1,363	2,707	10,771
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	0.492	0.498	0.479	0.472 (-1%)	0.475	0.473
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	57.0	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	94.1	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	0.578	N/A	N/A	N/A	N/A	N/A	N/A	N/A

Miscellaneous

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

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	17,050 (+1%)	37,663 (+6%)

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	554	1,472 (+2%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	0.505 (-1%)	588 (+2%)

[benesjan]

Fantastic work! Please just wait for Maxim to make the review before merging since I don't really know enough about Noir compiler to really give you a thorough feedback on the macro implementation.

[nventuro]

Some CI jobs are failing due to small updates that have to be done on tests in the different packages, but these fixes should be minor and most likely won't affect the review at all.

[LHerskind]

Interested in hearing if @TomAFrench and @vezenovm happy with us playing in here. We are sorta crossing the boundaries for where we are usually welcome 😬

[LHerskind]

[LHerskind]

Should we have a utility of something for computing this one? 🤔

[nventuro]

Ah good idea, I'll do this in a separate PR.

[vezenovm]

• Finally, I don't know enough about how Noir errors work to know how to produce a useful Location value for the new function, if indeed that can be done. Providing an empty span seems to at least not cause weird errors on the LSP plugin, so that's how I left it for now.

This is a long standing tech debt (#4373) which does not have an obvious solution so no need to worry about it right now.

[nventuro]

@critesjosh I removed all mentions of developers having to include this function, since it's now autogenerated. It's still mentioned in some places since it does still exist, and is used by the PXE internals.

I think we may want to have a small section somewhere that acknowledges its existence, and maybe mentions that you can override the autogeneration and define your own if you really want (though I don't see why you'd do it - I left that mostly in case there's any bugs here and we need to disable this mechanism). Do you think this is a good idea? Where should this go?

[vezenovm]

Following #4496 being merged and any reserved names used in this PR getting included in the prelude I am ready to merge.

fixed