feat: add api for inclusion proof of outgoing message in block #4562

[sklppy88]

Resolves #4562.

[sklppy88]

@LHerskind: This is still a tentative proposal for this, my main questions are:

1. Is this okay to do regarding creating a tree ? Will this cause a memory leak ? Is there a better way to do this only in memory to let gc clean everything after calling ?
2. Is there a defined tree height for outgoing messages or will it be dynamically calculated for each block ?

Addendum:
I think it's a bit stupid what I'm doing to support calling it with blocknumber = 'latest', but I didn't want to remove it yet, would like confirmation that we only need to call it with a number, and won't need to support 'latest'

[LHerskind]

Is there a defined tree height for outgoing messages or will it be dynamically calculated for each block ?

Since the outgoing messages is per transaction, the number of transactions will change the height of the tree, this is why the heigh of the tree must also be conveyed as part of the data. Dynamic.

[AztecBot]

Benchmark results

Metrics with a significant change:

• batch_insert_into_append_only_tree_16_depth_ms (8): 11.7 (-31%)
• batch_insert_into_append_only_tree_16_depth_hash_ms (8): 0.499 (-31%)
• note_successful_decrypting_time_in_ms (32): 472 (-16%)
• note_trial_decrypting_time_in_ms (8): 53.1 (+238%)

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 77954ab5 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	64 txs
l1_rollup_calldata_size_in_bytes	5,700	18,884	36,452
l1_rollup_calldata_gas	66,528	239,252	470,420
l1_rollup_execution_gas	673,991	980,073	1,389,194
l2_block_processing_time_in_ms	1,273 (+6%)	4,569 (+1%)	8,996
note_successful_decrypting_time_in_ms	146 (-29%)	⚠️ 472 (-16%)	944 (-8%)
note_trial_decrypting_time_in_ms	⚠️ 53.1 (+238%)	87.4 (+12%)	72.7 (+31%)
l2_block_building_time_in_ms	11,602 (-4%)	45,929 (-4%)	91,898 (-4%)
l2_block_rollup_simulation_time_in_ms	7,032 (-4%)	28,057 (-4%)	56,265 (-4%)
l2_block_public_tx_process_time_in_ms	4,541 (-3%)	17,778 (-3%)	35,472 (-4%)

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	14,936 (+3%)	28,094 (+1%)
note_history_successful_decrypting_time_in_ms	1,178 (-7%)	2,485
note_history_trial_decrypting_time_in_ms	62.9 (-41%)	154 (+7%)
node_database_size_in_bytes	18,755,664	35,553,360
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	249 (-1%)	44,736	28,001
private-kernel-ordering	194 (-1%)	52,625	14,627
base-rollup	647 (-2%)	177,932	997
root-rollup	68.3 (-1%)	4,320	825
private-kernel-inner	316 (-1%)	73,715	28,001
public-kernel-app-logic	164	34,920	27,972
public-kernel-tail	81.5 (-1%)	34,507	27,972
merge-rollup	8.43 (-3%)	2,840	997

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	64 leaves	128 leaves	512 leaves	1024 leaves	2048 leaves	4096 leaves
batch_insert_into_append_only_tree_16_depth_ms	9.62 (-2%)	9.86 (-7%)	⚠️ 11.7 (-31%)	16.6 (+3%)	21.1 (-4%)	33.9 (-5%)	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	79.0	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.559 (-2%)	0.551 (-7%)	⚠️ 0.499 (-31%)	0.512 (+3%)	0.443 (-4%)	0.423 (-4%)	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	45.2 (-2%)	70.2 (-3%)	222 (-4%)	467 (+4%)	834 (-4%)	1,650 (-4%)
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	N/A	N/A	N/A	96.0	159	543	1,055	2,079	4,127
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	0.464 (-1%)	0.434 (-2%)	0.405 (-3%)	0.438 (+4%)	0.397 (-4%)	0.396 (-4%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	52.6 (-5%)	104 (-10%)	326 (-4%)	663 (-1%)	1,259 (-5%)	2,504 (-4%)
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	N/A	N/A	N/A	104	207	691	1,363	2,707	5,395
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	N/A	N/A	N/A	0.470 (-4%)	0.470 (-9%)	0.440 (-5%)	0.457	0.438 (-4%)	0.436 (-4%)
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	60.3 (-2%)	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	N/A	109	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	N/A	0.528 (-1%)	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
tx_size_in_bytes	19,179

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes
tx_pxe_processing_time_ms	2,627 (-3%)	1,359 (-2%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	5.16 (-21%)	570 (-1%)

[benesjan]

Looks good to me. Would just add more comments

[sklppy88]

Creating a new issue to figure out an interaction guaranteeing transactions make it in a specific block, or in the same block together. This is to address the case of different transactions not being put in the same block, even when run as a concurrent call, thus not allowing for testing a full tree (or even messages > max number of L1 -> L2 messages per tx) as right now putting in more than 1 transaction per block is doable on local, but not on CI.