feat: make public l1tol2 message consumption take leafIndex

[fcarreiro]

No description provided.

[fcarreiro]

• fix(avm-simulator): L1TOL2MESSAGEEXISTS opcode #5807
• feat: make public l1tol2 message consumption take leafIndex #5805 👈
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @fcarreiro and the rest of your teammates on Graphite

[AztecBot]

Benchmark results

Metrics with a significant change:

• batch_insert_into_append_only_tree_32_depth_ms (4096): 1,960 (-30%)
• batch_insert_into_append_only_tree_32_depth_hash_ms (4096): 0.468 (-30%)
• batch_insert_into_indexed_tree_20_depth_ms (4096): 2,935 (-24%)
• note_successful_decrypting_time_in_ms (8): 234 (+41%)
• note_trial_decrypting_time_in_ms (32): 36.3 (+127%)
• note_trial_decrypting_time_in_ms (64): 69.2 (+142%)

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	772	772	772
l1_rollup_calldata_gas	6,844	6,844	6,844
l1_rollup_execution_gas	587,325	587,325	587,325
l2_block_processing_time_in_ms	1,477	5,291 (+1%)	10,561 (-14%)
note_successful_decrypting_time_in_ms	⚠️ 234 (+41%)	527 (-13%)	1,048 (+4%)
note_trial_decrypting_time_in_ms	36.8 (-45%)	⚠️ 36.3 (+127%)	⚠️ 69.2 (+142%)
l2_block_building_time_in_ms	18,093 (+2%)	71,207 (-1%)	142,239
l2_block_rollup_simulation_time_in_ms	17,857 (+2%)	70,359 (-1%)	140,568
l2_block_public_tx_process_time_in_ms	8,208 (+2%)	32,038	64,148

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,750	30,389 (+2%)
note_history_successful_decrypting_time_in_ms	1,263 (+8%)	2,384 (+3%)
note_history_trial_decrypting_time_in_ms	58.6 (+30%)	104 (-29%)
node_database_size_in_bytes	19,161,168 (+2%)	35,774,544 (+2%)
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	150 (-3%)	45,173 (+1%)	27,384 (+4%)
private-kernel-inner	164	73,608 (+2%)	27,384 (+4%)
private-kernel-ordering	122 (+7%)	53,138 (+4%)	41,123 (+5%)
base-parity	45.7 (+9%)	128	311
root-parity	7.44 (+2%)	1,244	311
base-rollup	19,296 (+1%)	110,928	957
root-rollup	47.7 (+1%)	4,551	821
public-kernel-app-logic	93.5 (+3%)	50,319 (+4%)	42,853 (+5%)
public-kernel-tail	376 (+2%)	159,352 (+1%)	7,493
merge-rollup	8.09 (+4%)	2,760	957
public-kernel-teardown	89.6 (+5%)	50,319 (+4%)	42,853 (+5%)
public-kernel-setup	88.5 (+5%)	50,319 (+4%)	42,853 (+5%)

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	11.1	18.0	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.645	0.557	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	52.4 (+1%)	81.7 (+1%)	260	519 (+3%)	979	⚠️ 1,960 (-30%)	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.536 (+1%)	0.503 (+1%)	0.474	0.485 (+3%)	0.464	⚠️ 0.468 (-30%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.9	120 (+1%)	374	746 (+1%)	1,463	⚠️ 2,935 (-24%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	207	691	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.536	0.541 (+1%)	0.509	0.513 (+1%)	0.506	0.508 (-23%)	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	67.7
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.589

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	42,886 (+5%)	535,757 (+1%)

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%)	1,145 (-1%)	1,345 (-2%)

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,266 (+4%)	844 (+4%)	3,522 (+2%)

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	805 (+3%)	679 (+4%)	1,293 (+4%)	886 (+9%)	1,984 (+4%)	1,140 (+8%)

[fcarreiro]

What are our assumptions here regarding nullified messages?

1. Should we explicitly check here that the message has not been nullified?
2. Should we instead expect the L1TOL2MESSAGEEXiSTS opcode to only return yes if the message is not nullified? (then it needs the secret as input as well I think)
3. What do we want consume_l1_to_l2_message to do if the message is nullified? Revert?

[LHerskind]

I don't think an exists should also check if it have been nullified, that is different checks.

If the message is nullified, it should fail to be inserted at the base, not fully sure how the revert case would actually be, e.g., if it is reverted as normally or if the tx is simply not able to be inserted into a block. Seems like it would be better if we are doing an explicit check such that we can ensure that the revert is done as part of the public execution in here.

[dbanks12]

@LHerskind thoughts?

[dbanks12]

Oh i hadn't refreshed and Lasse had already replied...

[dbanks12]

👍

[dbanks12]

This looks fine to me, although I'm interested to see what Lasse thinks about it. This might be the right time to introduce new message functions to the DB interface.

[LHerskind]

I don't think an exists should also check if it have been nullified, that is different checks.

If the message is nullified, it should fail to be inserted at the base, not fully sure how the revert case would actually be, e.g., if it is reverted as normally or if the tx is simply not able to be inserted into a block. Seems like it would be better if we are doing an explicit check such that we can ensure that the revert is done as part of the public execution in here.

[LHerskind]

Consistency wise it would probably be nice to have the public context and avm context behave similarly unless the time until it being "swapped" is fairly short.

[dbanks12]

It should be fairly short.

[fcarreiro]

Merge activity

• Apr 17, 1:25 PM EDT: @fcarreiro merged this pull request with Graphite.