feat(avm): implement serialization for all existing operations

[fcarreiro]

This PR implements serialization for all existing operations. It also adds indirect and other missing parameters to the operations (but does not use them).

It's a big PR but the most interesting changes are

• The serialization/ folder.
• Things that are not tests.

What I like

• Easy to add types and modify existing wire formats.
• Very explicit tests that will tell you exactly what we expect (too repetitive? see DRY vs DAMP in tests).
• Well-defined interfaces.
• Instruction serialization from object is also supported! This made creating bytecode a breeze.

What I don't like

• Due to limitations of TypeScript, there is more boilerplate in each operation than I would like. Time permitting I will try to simplify things further. Thanks to @Maddiaa0 for coming up with a boilerplate-less version.
• Some typing is not as strict (uses of any).

What's still missing

• External calls cannot be added to the instruction set, because they create a dependency cycle. This stems from the context using decodeFromBytecode or, to paraphrase, from an instruction using an interpreter (this was not introduced in this PR). It might be fixable but not in this PR.

Closes #4218.

[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 e7db0da2 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,656	866,908	3,448,276
l1_rollup_execution_gas	314,143	984,648	3,667,933
l2_block_processing_time_in_ms	1,149	4,334	17,347 (+1%)
note_successful_decrypting_time_in_ms	302	957 (-1%)	3,718 (+3%)
note_trial_decrypting_time_in_ms	12.3 (+2%)	85.1 (-9%)	148 (+5%)
l2_block_building_time_in_ms	18,362 (+1%)	72,101	288,726
l2_block_rollup_simulation_time_in_ms	13,121 (+1%)	51,795	207,759
l2_block_public_tx_process_time_in_ms	5,188 (+2%)	20,231	80,692

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,319 (+12%)	29,113 (+10%)
note_history_successful_decrypting_time_in_ms	2,385 (-3%)	4,706 (+2%)
note_history_trial_decrypting_time_in_ms	119 (+42%)	232 (+18%)
node_database_size_in_bytes	17,330,256	33,222,736
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	309	44,481	26,193
private-kernel-ordering	193	44,513	14,929
base-rollup	1,405	128,970	881
root-rollup	82.4	4,088	677
private-kernel-inner	411	71,640	26,193
public-kernel-private-input	242	32,615	26,193
public-kernel-non-first-iteration	242	32,657	26,193
merge-rollup	7.62	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	10.2	10.8 (-1%)	12.7 (-2%)	16.9	23.1 (+1%)	63.8	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.594	0.604 (-1%)	0.540 (-2%)	0.522	0.485 (+1%)	0.440	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	74.5	47.5	239	463	898	3,593 (+1%)
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.460	0.487	0.436	0.433	0.428	0.431 (+1%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	103	56.6	349	689	1,355	5,425
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.492	0.495	0.477	0.473	0.471	0.473
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	56.5	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.577	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,575	37,972

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	587 (+7%)	1,372

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	0.552 (+13%)	629

[dbanks12]

Overall nice work! Most of my comments are requests to add comments where things aren't super clear.

[Maddiaa0]

I like the over all format of this a good amount (and the thoroughness with testing is elite), i read what was written in the description about you not liking the amount of boilerplate, so I decided to think about it abit.

This is what ive come up with, it is slightly looser on typing, but it manages to get rid of most of the boilerplate, next steps would be to see if we can use the type definitions alone to infer the wireFormat structure.

https://github.com/AztecProtocol/aztec-packages/compare/fc/avm-serialization...md/fc/avm-serialization?expand=1

[fcarreiro]

Integrated Sean's changes. I think the boilerplate removal is worth the type-unsafety! I still have to add some small tests but things are mostly done.

[fcarreiro]

I like the over all format of this a good amount (and the thoroughness with testing is elite), i read what was written in the description about you not liking the amount of boilerplate, so I decided to think about it abit.

This is what ive come up with, it is slightly looser on typing, but it manages to get rid of most of the boilerplate, next steps would be to see if we can use the type definitions alone to infer the wireFormat structure.

https://github.com/AztecProtocol/aztec-packages/compare/fc/avm-serialization...md/fc/avm-serialization?expand=1

This was great! integrated your changes and some more on top.

[dbanks12]

LGTM!

[Maddiaa0]

! ye buddy !