feat: publish block body separately

[benesjan]

Fixes #3944

Note: Had to update Registry contract to handle AvailabilityOracle.

[benesjan]

Current dependencies on/for this PR:

• master
  • PR feat: publish block body separately #4118 👈
    • PR refactor: contract deployment cleanup #4137

This stack of pull requests is managed by Graphite.

[AztecBot]

Benchmark results

Metrics with a significant change:

• l1_rollup_execution_gas (8): 314,123 (-66%)
• l1_rollup_execution_gas (32): 984,460 (-75%)
• l1_rollup_execution_gas (128): 3,667,877 (-85%)

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 7438db31 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,412	179,524	716,068
l1_rollup_calldata_gas	221,704	866,788	3,448,288
l1_rollup_execution_gas	⚠️ 314,123 (-66%)	⚠️ 984,460 (-75%)	⚠️ 3,667,877 (-85%)
l2_block_processing_time_in_ms	1,384 (-1%)	5,257 (-4%)	21,214 (-2%)
note_successful_decrypting_time_in_ms	311	920 (+1%)	3,325
note_trial_decrypting_time_in_ms	23.8 (+9%)	46.2 (+22%)	143 (+5%)
l2_block_building_time_in_ms	16,112	63,869	255,680
l2_block_rollup_simulation_time_in_ms	11,719	46,505	186,366
l2_block_public_tx_process_time_in_ms	4,358	17,274	68,916

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,170	30,782 (+2%)
note_history_successful_decrypting_time_in_ms	2,327 (+7%)	4,202 (-2%)
note_history_trial_decrypting_time_in_ms	106 (-13%)	172 (-2%)
node_database_size_in_bytes	3,583,904	3,653,288
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	212 (-1%)	44,681	25,561
private-kernel-ordering	165	43,753	14,809
base-rollup	1,192	128,338	881
root-rollup	78.9	4,088	677
private-kernel-inner	291	71,208	25,561
public-kernel-private-input	205	31,863	25,561
public-kernel-non-first-iteration	203	31,905	25,561
merge-rollup	7.61	2,608	881

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	12.0 (-3%)	20.6 (-4%)	13.6 (-1%)	19.5 (-4%)	26.2 (+4%)	67.3 (+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.618 (-1%)	0.654 (-3%)	0.549	0.549	0.488	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	91.1 (-1%)	52.0 (+2%)	249	491 (+3%)	913 (-1%)	3,564
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.512 (+3%)	0.502 (+1%)	0.437	0.451 (+3%)	0.431 (-1%)	0.427
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	125 (-2%)	61.6 (-2%)	372 (-1%)	784 (+3%)	1,436	5,881
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.523 (+2%)	0.502 (-1%)	0.478	0.500 (+4%)	0.474	0.483
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	67.2 (-1%)	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.601 (+1%)	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	15,455	32,219

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	375 (-6%)	1,081

Metric	1 public data writes
tx_sequencer_processing_time_ms	534

[LHerskind]

Generally good, but have a few comments related to registries and synching.

[LHerskind]

As mentioned earlier. Think it is better to keep this immutable and non changing. In this model, it is possible to brick older instances.

Nevertheless I can follow adding in here for the purpose of getting addresses communicated to the nodes. Would it be useful for this case that we are making the snapshot to:
{instance, inbox, outbox, addresses_provider} where instance is the actor in the governance but addresses_provider can be an arbitrary contract that is just used for communicating instance specific addresses which might have a variable size. This way you could communicate 10 addresses if you need, or just a few.

[LHerskind]

When you are working on #3938 would it not mess with your decoding here? It would not longer be practical to get the full block from just this kind of function call as the bodyHex would not be here.

This part seems to be very reliant on the content being published at the same time for getting any data.

In my mind you would need to fetch the body separately through the extra event you added. And then as l2 blocks are seen you can combine the two pieces together for the block.

As this is the synching part, it can be handled separately, a new pr for it might be nice to have the split fully dealt with? This seems a bit like cheating. But let us talk about it, as the new changes for messages would likely mess with it a bit, so an initial pr could focus on just needing to pass the messages and nothing else. That way we can address synching separately to the hashing updates.

[benesjan]

In my mind you would need to fetch the body separately through the extra event you added. And then as l2 blocks are seen you can combine the two pieces together for the block.

Yes, exactly. Would find the relevant event based on txsHash, from that get the transaction hash and from that the calldata.

And I just realized that for that I will need the index the hash in TxsPublished event. Will do that once I'll deal with this in that other PR.

[LHerskind]

This is nice 👍 Could be a neat test to check cost of sending an empty block of a size that have been sent before. The effects should be the same, so it is essentially just the header and proof you put in. Making it a viable option to have a small empty block in the backhand when sequencing 🤔

Likely also something that @Cooper-Kunz would find interesting.

[LHerskind]

In the real world should probably apply a small multiplier on the gas value here.

[benesjan]

Why is that so? Are the estimations in precise?

[LHerskind]

If estimate is exact, and state that you touch is different than simulation you might revert. Don't know if the estimate is already applying one though.

[LHerskind]

When combined with the separate pr for fixing synching think this is a nice step ahead 👍