feat: read_calldata

[ledwards2225]

Add a read_calldata method to clarify and robustify the interface to calldata. Update the expository DataBus test accordingly.

Closes AztecProtocol/barretenberg#821 (I was proposing something weird in that issue but all I really wanted was for the updating of read counts to be automated. That's achieved through simply placing it in read_calldata).

[ledwards2225]

Moving this to the private access specifier to enforce the use of read_calldata as the interface. This method is called from within read_calldata.

[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 060fa1e1 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	676	676	676
l1_rollup_calldata_gas	6,412	6,424	6,412
l1_rollup_execution_gas	585,745	585,757	585,745
l2_block_processing_time_in_ms	1,293 (-1%)	4,787 (+2%)	9,113 (+1%)
note_successful_decrypting_time_in_ms	183 (+2%)	532 (-3%)	976 (-3%)
note_trial_decrypting_time_in_ms	64.4 (-21%)	49.1 (-24%)	106 (-21%)
l2_block_building_time_in_ms	17,261 (+1%)	65,438 (+2%)	129,458 (+2%)
l2_block_rollup_simulation_time_in_ms	7,969	28,600 (+1%)	55,669 (+1%)
l2_block_public_tx_process_time_in_ms	9,273 (+2%)	36,782 (+3%)	73,690 (+3%)

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,108 (+5%)	27,188 (+4%)
note_history_successful_decrypting_time_in_ms	1,234 (-2%)	2,349 (-5%)
note_history_trial_decrypting_time_in_ms	92.6 (-5%)	117
node_database_size_in_bytes	18,669,648	35,045,456
pxe_database_size_in_bytes	29,859	59,414

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	235 (-2%)	44,377	28,214
private-kernel-ordering	209 (-1%)	52,880	14,296
base-parity	4,448	128	311
root-parity	1,588 (-3%)	1,244	311
base-rollup	17,915	165,760	861
root-rollup	49.4	4,359	725
private-kernel-inner	592 (-2%)	73,794	28,214
public-kernel-app-logic	387 (-1%)	35,251	28,217
public-kernel-tail	170 (-1%)	40,928	28,217
merge-rollup	8.75	2,568	861

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	9.87 (-1%)	15.7 (-1%)	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.8	31.6	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.575 (-1%)	0.485 (-2%)	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	46.3 (-2%)	71.6	231	431 (-3%)	877	1,720	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	96.0	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.475 (-2%)	0.442	0.420	0.404 (-3%)	0.416	0.411	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	53.4 (-1%)	107	336	642 (-4%)	1,316	2,622	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	104	207	691	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.474 (-1%)	0.480 (-1%)	0.457	0.442 (-5%)	0.456 (-1%)	0.455	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	61.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	109
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.535

Miscellaneous

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

Metric	0 registered classes
tx_size_in_bytes	22,024

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes
tx_pxe_processing_time_ms	3,012 (+1%)	1,611 (-2%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	15.4 (+7%)	1,113 (-1%)

[maramihali]

looks good to me overall - just had a question

[maramihali]

maybe this is a stupid question cus i'm missing sth - but is it in the 'responsabilities' of the circuit writer to ensure the calldata_value corresponds to the calldata_read? just wondering if this gate shouldn't be implicitly added by the circuit writer somewhere

[ledwards2225]

If I understand your question correctly, this is exactly the purpose of the calldata read gate - it shows that the value read is indeed present in the calldata at the corresponding index

[maramihali]

So this final add gate here is solely for testing purposes

[maramihali]

I was just wondering whether read_calldata actually needs to return the index because I only see it being used in testing

[ledwards2225]

Yeah that’s what I was trying to get at in the comments. In practice the whole point of doing the read is to then use the result somewhere else. I realize now my choice of gate was a little misleading, but it was meant to just be an arbitrary add gate. But there would be no reason to ever do a read unless you use the result. I’ll add a comment to that effect to the test. There will be many more incremental PRs in the near future

[ledwards2225]

The value proposition of the databus is it allows us to pass large amounts of data from circuit to circuit but only pay a gate for the values we actually want to read. This is valuable since the nature of the data is that we only want to read a small amount of what’s actually there, the rest is just being carried on for future use

[maramihali]

Thanks for explaining!