feat(avm): Set gas allowance in public calls

[spalladino]

Allows user to set gas allowance in public calls, defaulting to the gas left in the current frame.

• Adds the (L1|L2|DA)GASLEFT instructions.
• Adds a new GasOpts option to the (Public|Avm)Context.call_public_function so the user can specify the gas allocation for a nested public call (ignored in public context, only used in avm context). Defaults gas to the result of gasleft, minus a buffer for L2 compute.
• Updates the noir interface codegen to handle this new argument.

[spalladino]

• feat(avm): Set gas allowance in public calls #5567 👈
• feat(avm): Track gas from memory accesses explicitly #5563
• feat(avm): Gas usage for nested calls #5495 : 1 other dependent PR (#5514 )
• master

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

Join @spalladino and the rest of your teammates on Graphite

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_successful_decrypting_time_in_ms (8): 223 (-16%)

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 a974ec82 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,424	6,424	6,400
l1_rollup_execution_gas	585,757	585,757	585,733
l2_block_processing_time_in_ms	1,299 (-3%)	4,629 (-2%)	9,352 (-1%)
note_successful_decrypting_time_in_ms	⚠️ 223 (-16%)	582 (+3%)	1,007 (-3%)
note_trial_decrypting_time_in_ms	23.6 (-64%)	92.7 (+22%)	25.8 (-60%)
l2_block_building_time_in_ms	11,638 (-3%)	42,325 (-1%)	83,236
l2_block_rollup_simulation_time_in_ms	11,603 (-3%)	42,208 (-1%)	83,014
l2_block_public_tx_process_time_in_ms	6,058 (-3%)	23,701 (-1%)	47,836

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,341	26,707 (-3%)
note_history_successful_decrypting_time_in_ms	1,244 (-5%)	2,390 (-2%)
note_history_trial_decrypting_time_in_ms	73.3 (-42%)	103 (-5%)
node_database_size_in_bytes	18,669,648	35,106,896
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	178 (-1%)	44,377	26,164
private-kernel-ordering	160 (-1%)	50,830	39,026
base-parity	3,904 (-2%)	128	311
root-parity	1,055 (+6%)	1,244	311
base-rollup	14,103 (-1%)	110,464	861
root-rollup	49.5	4,359	725
private-kernel-inner	215 (-1%)	71,744	26,164
public-kernel-app-logic	119	47,695	40,661
public-kernel-tail	163 (+1%)	53,372	7,125
merge-rollup	9.31 (-1%)	2,568	861
public-kernel-teardown	117 (+1%)	47,695	40,661
public-kernel-setup	116 (+1%)	47,695	40,661

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.99 (-1%)	16.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.582 (-1%)	0.498	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	45.6	71.5 (-1%)	226 (-2%)	447	850 (-3%)	1,688 (-2%)	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.467	0.441 (-1%)	0.412 (-2%)	0.417	0.405 (-3%)	0.405 (-2%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	53.8 (-1%)	105 (-2%)	327 (-3%)	659	1,278	2,570 (-1%)	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.475 (-1%)	0.476 (-2%)	0.445 (-3%)	0.454	0.443	0.446 (-2%)	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	60.6 (-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.529 (-1%)

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	40,372	496,534

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	905	1,161	1,377

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,682	1,072 (-1%)	5,377 (-1%)

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	573 (+1%)	398 (+1%)	1,063	524 (+3%)	1,742 (+1%)	584 (+2%)

[fcarreiro]

LGTM, when passing LMK and I'll approve!

[fcarreiro]

What happens if l2_gas_left() - NESTED_CALL_L2_GAS_BUFFER < 0 ? I guess it would rever with a wrapping check? (I think brillig has checked arithmetic)

[spalladino]

I think so, but it's probably nicer (and safer) to have an explicit check with an explicit assertion. I'll add it!

[spalladino]

I remember a joke from Condorito in which Condorito's boss (both are accountants or something like that) instructs him to use blue ink to write down the positive balance for the quarter. Condorito tells him there isn't any, so his boss angrily tells him to go buy some. To which Condorito says "then there won't be any positive balance!".

Turns out adding this check means an extra 1M gas for some reason, so I'm sticking with the current implementation.

assert(NESTED_CALL_L2_GAS_BUFFER.lt(l2_gas), "Not enough L2 gas left for nested call");

[fcarreiro]

Hahah, man this is bad. We should start a list of "things that cause blowups and are not meant to".

[fcarreiro]

https://hackmd.io/u-r2bilXSmiGEpha8QTACg

[fcarreiro]

Given the constructors this looks more like a

struct Gas {
  l1_gas: Field,
  l2_gas: Field,
  da_gas: Field,
}

and then Option<Gas> ?

I don't mind either way, because I can imagine a user wanting to specify just one of the three (but then maybe have GasOpts::l2Gas(xxx) constructors etc?.

[spalladino]

because I can imagine a user wanting to specify just one of the three

Yeah, that was the intention. A GasOpts::l2Gas(xxx) constructor using Fields instead of Option<Field>s would have required giving GasOpts knowledge to populate its own defaults, and I wanted to keep it as dumb as possible.

[fcarreiro]

Are these changes related to this PR?

[spalladino]

Yep. This interface wraps call_function methods for a given contract, and since we've updated that API, we need to update this as well. There are more changes than strictly that because this wrapper hadn't been regenerated in a while unfortunately.

[spalladino]

The next logical comment to this is "then why are we committing it at all" or "not checking in the CI that it's up to date". We could do that in a job that depends on yarn-project-build, since it requires ts code for the generation. But the plan is to remove this feature relatively soon, in favor of aztec macros.

[fcarreiro]

Thanks for making the changes then!

[fcarreiro]

gas not set?

[spalladino]

WDYM?

[fcarreiro]

Sorry, I meant that AFAICT
const gas = [/*l1=*/ 10000, /*l2=*/ 20, /*da=*/ 10000].map(g => new Fr(g)); is not used?

[fcarreiro]

I'd say Just send David a message on slack to confirm what the type should be.

[spalladino]

Thanks!

[spalladino]

@fcarreiro you were spot on in that the error in nested calls was just not allocating enough buffer. PR is now ready for its (hopefully) last review. Thanks!

[fcarreiro]

Hahah, man this is bad. We should start a list of "things that cause blowups and are not meant to".

[fcarreiro]

Thanks for making the changes then!

[fcarreiro]

Sorry, I meant that AFAICT
const gas = [/*l1=*/ 10000, /*l2=*/ 20, /*da=*/ 10000].map(g => new Fr(g)); is not used?