feat: note hash read requests fixes and refactoring

[LeilaWang]

Validating note hash read requests in the private tail circuits.
Also ensure that a read happens before the note hash is nullified.

[AztecBot]

Benchmark results

Metrics with a significant change:

• circuit_simulation_time_in_ms (private-kernel-init): 89.8 (-53%)
• circuit_simulation_time_in_ms (private-kernel-inner): 158 (-30%)
• circuit_simulation_time_in_ms (private-kernel-ordering): 499 (+100%)
• circuit_simulation_time_in_ms (merge-rollup): 6,478 (+21%)
• circuit_input_size_in_bytes (private-kernel-init): 11,075 (-76%)
• circuit_input_size_in_bytes (private-kernel-inner): 41,502 (-46%)
• circuit_input_size_in_bytes (private-kernel-ordering): 194,864 (+267%)
• batch_insert_into_append_only_tree_32_depth_ms (512): 259 (-26%)
• tx_sequencer_processing_time_ms (2): 808 (-21%)
• tx_sequencer_processing_time_ms (4): 955 (-22%)
• tx_sequencer_processing_time_ms (8): 1,137 (-26%)
• node_history_sync_time_in_ms (10): 31,448 (+16%)
• l2_block_public_tx_process_time_in_ms (8): 9,037 (-18%)

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.

L2 block published to L1

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

Metric	8 txs	32 txs	64 txs
l1_rollup_calldata_size_in_bytes	740	740	740
l1_rollup_calldata_gas	6,680	6,668	6,692
l1_rollup_execution_gas	586,812	586,800	586,824
l2_block_processing_time_in_ms	1,516 (-9%)	5,444 (+4%)	10,630 (+8%)
l2_block_building_time_in_ms	22,745 (-12%)	89,897	178,711 (+6%)
l2_block_rollup_simulation_time_in_ms	22,530 (-12%)	89,129	177,221 (+6%)
l2_block_public_tx_process_time_in_ms	⚠️ 9,037 (-18%)	35,509 (-6%)	70,464

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	16,452 (+11%)	⚠️ 31,448 (+16%)
node_database_size_in_bytes	20,742,224	37,396,560
pxe_database_size_in_bytes	29,868	59,425

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	⚠️ 89.8 (-53%)	⚠️ 11,075 (-76%)	29,334 (+2%)
private-kernel-inner	⚠️ 158 (-30%)	⚠️ 41,502 (-46%)	29,334 (+2%)
private-kernel-ordering	⚠️ 499 (+100%)	⚠️ 194,864 (+267%)	43,232 (+1%)
base-parity	70.8 (-12%)	128	64.0
base-rollup	16,443 (+13%)	111,062	925
root-parity	1,580 (-6%)	27,064	64.0
root-rollup	64.9 (-15%)	11,454	789
public-kernel-app-logic	2,048 (+1%)	54,833 (+1%)	22,935 (+1%)
public-kernel-tail	4,887 (-1%)	160,282	3,898
merge-rollup	⚠️ 6,478 (+21%)	2,696	925
public-kernel-teardown	167 (-3%)	54,833 (+1%)	30,383 (+1%)
public-kernel-setup	227	54,833 (+1%)	30,383 (+1%)

Tree insertion stats

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

Metric	1 leaves	16 leaves	64 leaves	128 leaves	512 leaves	1024 leaves	2048 leaves	4096 leaves	32 leaves
batch_insert_into_append_only_tree_16_depth_ms	10.9 (-5%)	17.8 (-10%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.7	31.8	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.638 (-5%)	0.547 (-9%)	N/A	N/A	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	51.4 (-5%)	79.8 (-3%)	⚠️ 259 (-26%)	501 (+3%)	984	1,950 (+1%)	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	159	543	1,055	2,079	4,127	N/A
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.526 (-5%)	0.493 (-3%)	0.472 (-25%)	0.467 (+3%)	0.466 (-1%)	0.466 (+1%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.7 (-4%)	120 (-6%)	374 (-15%)	737 (+3%)	1,463 (-5%)	2,912	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.533 (-4%)	0.538 (-5%)	0.510 (-14%)	0.507 (+3%)	0.506 (-5%)	0.507	N/A
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	66.8 (-1%)
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	108
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	0.587 (-1%)

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes	1 registered classes
tx_size_in_bytes	45,110 (+1%)	535,551

Transaction size based on fee payment method

Metric	native fee payment method	fpc_public fee payment method	fpc_private fee payment method
tx_with_fee_size_in_bytes	897	1,145	1,345

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	1,499 (-15%)	1,147 (+4%)	3,816 (-8%)

Metric	1 public data writes	2 public data writes	3 public data writes	4 public data writes	5 public data writes	8 public data writes
tx_sequencer_processing_time_ms	898 (-2%)	⚠️ 808 (-21%)	1,475 (-7%)	⚠️ 955 (-22%)	2,285 (-14%)	⚠️ 1,137 (-26%)

[github-actions]

Changes to circuit sizes

Generated at commit: 991fa6e5eb623adc35590a3ad15c514723599bcd, compared to commit: cf026d2c5928ce081bfac1e0d85260075b06f418

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_tail	+60,255 ❌	+57.54%	+778,420 ❌	+248.93%
private_kernel_tail_to_public	+60,383 ❌	+16.89%	+778,669 ❌	+94.35%
private_kernel_inner_simulated	0 ➖	0.00%	+128 ❌	+11.73%
private_kernel_init_simulated	0 ➖	0.00%	+128 ❌	+11.73%
private_kernel_tail_to_public_simulated	0 ➖	0.00%	+128 ❌	+7.72%
public_kernel_setup_simulated	0 ➖	0.00%	+128 ❌	+7.72%
public_kernel_app_logic_simulated	0 ➖	0.00%	+128 ❌	+7.72%
public_kernel_teardown_simulated	0 ➖	0.00%	+128 ❌	+7.72%
public_kernel_setup	+128 ❌	+0.18%	+256 ❌	+0.09%
public_kernel_teardown	+128 ❌	+0.18%	+256 ❌	+0.09%
public_kernel_app_logic	+128 ❌	+0.14%	+256 ❌	+0.07%
private_kernel_inner	+5,408 ❌	+5.32%	-146,623 ✅	-27.87%
private_kernel_init	+3,995 ❌	+4.55%	-149,000 ✅	-34.30%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
private_kernel_tail	164,976 (+60,255)	+57.54%	1,091,124 (+778,420)	+248.93%
private_kernel_tail_to_public	417,862 (+60,383)	+16.89%	1,603,958 (+778,669)	+94.35%
private_kernel_inner_simulated	1 (0)	0.00%	1,219 (+128)	+11.73%
private_kernel_init_simulated	1 (0)	0.00%	1,219 (+128)	+11.73%
private_kernel_tail_to_public_simulated	1 (0)	0.00%	1,787 (+128)	+7.72%
public_kernel_setup_simulated	1 (0)	0.00%	1,787 (+128)	+7.72%
public_kernel_app_logic_simulated	1 (0)	0.00%	1,787 (+128)	+7.72%
public_kernel_teardown_simulated	1 (0)	0.00%	1,787 (+128)	+7.72%
public_kernel_setup	71,800 (+128)	+0.18%	301,051 (+256)	+0.09%
public_kernel_teardown	71,941 (+128)	+0.18%	301,188 (+256)	+0.09%
public_kernel_app_logic	89,228 (+128)	+0.14%	385,645 (+256)	+0.07%
private_kernel_inner	106,967 (+5,408)	+5.32%	379,469 (-146,623)	-27.87%
private_kernel_init	91,739 (+3,995)	+4.55%	285,396 (-149,000)	-34.30%

[MirandaWood]

I see that they won't match because of the siloing issues, but is there no check we could do here in the interim?
Seems like the below loop could assign the wrong note hash to a read request as long as the counters are in the range, but I could be missing something.

[LeilaWang]

We are using the siloed value to select the note hashes below:

 const pendingNoteHash = noteHashMap
      .get(siloedValue.toBigInt())
      ?.find(n => isValidNoteHashReadRequest(readRequest, n.noteHash));

Actually, now you point this out, we don't need to compare the values in this function at all! Because the note hashes passed to this function are picked by matching the value.

[MirandaWood]

Ah yep, I had missed that siloedValue is from the ReadRequest! Got it - no worries.