feat: add fee payment methods

[alexghr]

This PR updates the account entrypoints to add support for fee payments. The concept of a fee payment method has been added, with two examples: a native token payment method (where the caller pays in the native gas token) and a generic payment method (where the sender can use a fee preparation contract).

Example of how the API could be used:

import { NativeFeePaymentMethod, GenericFeePaymentMethod } from '@aztec/aztec.js/fee'
const cardGame = CardGameContract.at(someKnownAddress, myWallet);

await cardGame.methods.playCard(someGame, myCard).send({
  fee: {
    paymentMethod: new NativePaymentMethod();
  }
}).wait();

// or, say I want to pay in some other token
await cardGame.methods.playCard(someGame, myCard).send({
  fee: {
    paymentMethod: new GenericFeePaymentMethod(TOKEN,FEE_PREP_CONTRACT,true) // private payment
  }
}).wait();

I think that once we add metering we should make tx simulation mandatory (right now one can call .send() directly and that will simulate internally) and the final API could look something like the following:

const txWithCosts = await cardGame.methods.playCard(someGame, myCard).simulate({
  fee: {
    priorityFee: {}, // TBD
    paymentMethod: new GenericFeePaymentMethod(TOKEN,FEE_PREP_CONTRACT,true) // private payment
  }
});

console.log(txWithCosts.getGasCosts());

// it's too expensive, change to native payment
const newTxWithCosts = await cardGame.methods.playCard(someGame, myCard).simulate({
  fee: {
    priorityFee: {}, // TBD
    paymentMethod: new NativePaymentMethod()
  }
});

await newTxWithCosts.send().wait();

[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 da2f5ed3 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,700 (-1%)	180,580 (-1%)	720,100 (-1%)
l1_rollup_calldata_gas	222,772 (-2%)	871,324 (-2%)	3,466,012 (-2%)
l1_rollup_execution_gas	315,963 (-1%)	989,772 (-2%)	3,686,390 (-2%)
l2_block_processing_time_in_ms	1,148	4,630 (+6%)	17,203
note_successful_decrypting_time_in_ms	308 (-1%)	1,020 (+1%)	3,669 (-3%)
note_trial_decrypting_time_in_ms	20.2 (-9%)	46.7 (+1%)	138 (-5%)
l2_block_building_time_in_ms	18,283	72,502	292,591
l2_block_rollup_simulation_time_in_ms	13,436	53,251	215,612
l2_block_public_tx_process_time_in_ms	4,816 (-1%)	19,171	76,719

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,965 (-1%)	27,926 (-2%)
note_history_successful_decrypting_time_in_ms	2,533 (-1%)	5,033 (+8%)
note_history_trial_decrypting_time_in_ms	93.1 (+10%)	231 (+31%)
node_database_size_in_bytes	17,338,448	33,030,224 (-1%)
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	328 (+6%)	44,528	25,825
private-kernel-ordering	197	44,145	16,193
base-rollup	1,457	130,286	933
root-rollup	84.6 (+3%)	4,192	729
private-kernel-inner	439 (+1%)	71,331	25,825
public-kernel-private-input	249	34,687	27,457
public-kernel-non-first-iteration	248	34,729	27,457
merge-rollup	8.51 (+8%)	2,712	933

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.3	11.6 (+4%)	12.6	16.9	22.8 (-1%)	63.6 (-1%)	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.595	0.649 (+4%)	0.537	0.523	0.478	0.439 (-1%)	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	75.1 (-5%)	47.7	238	463	897 (-1%)	3,552
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.462 (-5%)	0.489	0.436	0.433	0.427	0.427
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	103 (-2%)	56.8	347 (-1%)	692 (+1%)	1,365	5,410
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 (-1%)	0.497	0.474	0.475	0.475	0.471
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	56.6	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.578	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	16,827	40,014

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	553	1,447 (+10%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	0.512 (-1%)	597

[alexghr]

fee.nr and app.nr look very similar now. Would it make sense to build a generic "payload" app that took the number of function calls as a generic parameter? I'm not sure how serialisation/bytes implementation would work then as they'd need different lengths (derived from number of function + size of function).

[rahul-kothari]

it might also increase circuit size no?

[rahul-kothari]

these docs macros seem to be copied from somewhere - let's make sure we also update the docs to point to the right macro
(no need to talk about app_payload, fee_payload in docs yet but just fix the macros to prevent it from breaking)

[alexghr]

I have updated the docs markers and the docs mentioning EntrypointPayload. @rahul-kothari would you have another look? :D

[PhilWindle]

This can be accessed from aztec.js can't it?