feat!: Acir call opcode

[vezenovm]

Resolves noir-lang/noir#4427

This PR just introduces the Call opcode to cleanly separate the breaking serialization change from its implementation. There will be followup work as specified under noir-lang/noir#4426 for implementing this opcode.

I ultimately settled on just having three fields for the opcode.

1. We just need an ID which acts as a function pointer that the execution environment will use for setting up the circuit that gets passed to the backend.
2. Inputs/Outputs just need to be witnesses as they should be treated the same way we treat inputs and outputs from any entry point function
3. I did not add a field for including metadata as I don't see the need. There is only two things a backend can really do with a function call. Either inline the function or fold the function. If a backend has the ability to fold is there a case where it would chose not to fold a function and would rather inline the function call? If we feel this is too restrictive I can add a metadata field. However, any metadata field should be an enum so any need to attach metadata to a function call would still require a breaking change.

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_successful_decrypting_time_in_ms (8): 158 (-30%)
• note_trial_decrypting_time_in_ms (8): 59.3 (+82%)

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 c34a299e 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,668	18,820	36,356
l1_rollup_calldata_gas	66,436	239,032	469,760
l1_rollup_execution_gas	667,117	953,942	1,337,117
l2_block_processing_time_in_ms	1,323 (-1%)	4,892 (+1%)	9,290 (-2%)
note_successful_decrypting_time_in_ms	⚠️ 158 (-30%)	564 (+2%)	1,021 (+9%)
note_trial_decrypting_time_in_ms	⚠️ 59.3 (+82%)	78.7 (+8%)	55.8 (-22%)
l2_block_building_time_in_ms	18,536 (-1%)	69,378	138,295 (+1%)
l2_block_rollup_simulation_time_in_ms	8,299	28,925	57,614 (+2%)
l2_block_public_tx_process_time_in_ms	10,213 (-1%)	40,396	80,574 (+1%)

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,126 (+2%)	27,006 (+1%)
note_history_successful_decrypting_time_in_ms	1,205 (+2%)	2,470
note_history_trial_decrypting_time_in_ms	67.1 (-17%)	150 (-13%)
node_database_size_in_bytes	19,103,824	35,627,088 (-1%)
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	283 (-1%)	44,370	27,700
private-kernel-ordering	218	52,324	14,326
base-parity	1,839 (+2%)	128	311
base-rollup	726 (+1%)	177,083	925
root-parity	1,561 (-1%)	1,244	311
root-rollup	69.0	4,487	789
private-kernel-inner	642	73,229	27,700
public-kernel-app-logic	451	35,262	28,215
public-kernel-tail	177	40,926	28,215
merge-rollup	8.35 (+1%)	2,696	925

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.97	15.9	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.581	0.493	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.1 (-1%)	71.9	230	442	873	1,734 (+1%)	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.474 (-1%)	0.444	0.420	0.415	0.415	0.415 (+1%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	53.8 (-2%)	106 (-1%)	336 (-2%)	658	1,311 (-1%)	2,620 (+1%)	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.479 (-2%)	0.479 (-1%)	0.457 (-1%)	0.453	0.454	0.453	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.0
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.534

Miscellaneous

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

Metric	0 registered classes
tx_size_in_bytes	22,014

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes
tx_pxe_processing_time_ms	3,397 (+3%)	1,743

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	12.6 (+10%)	1,261

[guipublic]

We would need the function signature at some point, so I wonder if it will be good to have this in the opcode?

[TomAFrench]

We're also going to need to modify the Circuit struct to hold these other ACIRs so we're going to need another breaking change to add those.

[vezenovm]

We would need the function signature at some point, so I wonder if it will be good to have this in the opcode?

Do you mean for resolving the call ID to the ACIR? I was thinking we should only need this signature during generation?

EDIT: To followup here we have decided that we should not need the function signature in the opcode. It will be needed during codegen but should not be needed by the backend (which only cares about ACIR and witnesses).

[vezenovm]

We're also going to need to modify the Circuit struct to hold these other ACIRs so we're going to need another breaking change to add those.

I started work to make the recursive Circuit type but I am now leaning towards a flat list of circuits as outlined under number 2 in this issue (noir-lang/noir#4428) as this is ultimately what the backend will need to accept to fold multiple circuits either way. The recursive circuit structure just lends itself to repeated ACIRs when really it should just be the witness that is growing in size.

We may still need some Program structure that represents a list of ACIR functions as we need an ordered list to maintain the call IDs. However, the Circuit type would not necessarily be a breaking serialization change in this case.

I am thinking to perhaps hold off on breaking the circuit structure in this PR just yet as it may change again.

[critesjosh]

I see this is a breaking change. Do we need to add anything to the Migration Notes page in the Aztec docs?

[vezenovm]

I see this is a breaking change. Do we need to add anything to the Migration Notes page in the Aztec docs?

This purely a serialization change so not right now. The work that builds upon it will need migration notes.