feat: e2e token contract can run in 2m with snapshots and test separation.

[charlielye]

Trying to run e2e tests makes one want to live a different life. They're slow (for root reasons that will eventually be addressed). e2e tests ultimately should be able to run in the "seconds" not "minutes" range. One day we may have a foundry like solution that could give sub-second state transitions, but that's a whole different ball game and won't happen soon.

Developers should not be spending their time watching a minute of setup time in an e2e test before it even hits their code. Our CI is also horribly slow, and this PR could eventually help alleviate that. There are two main things of note in this PR.

• It introduces a little snapshot engine for our e2e tests, that builds upon our ability to have our own anvil per test.
• It splits our e2e_token_contract.test into 8 separate test files, and a TokenContractTest class to capture common behaviour/state.

The second, is something we simply should be doing anyway. It's independent of the snapshot engine. People have got into the habit of rightward-drifting describe blocks into single e2e test files, but it's a bad pattern because jest cannot parallelise within a single test file. Better, for some of these larger e2e tests, would be to create a folder named after the test and to split them up, getting rid of the right-drifting describes, and having a nice flat test file. That's what this PR does with the token contract.

Ignoring snapshotting, this get's running the e2e token contract tests time down from 10m to about 3m. That's with every test file still doing it's own ~1m of setup.

Snapshot Engine

If you're a developer, and you're just wanting to run a part of your tests, the turnaround time of waiting 1 minute before you even hit your code is unacceptable. This PR introduces a small engine for reusing state snapshots within, and across test runs. To enable the snapshot engine, set e.g. E2E_DATA_PATH=./data before running tests. On the first run you'll notice the data folder is created, this contains snapshotted state. Subsequent runs leverage this to avoid having to do setup again. Within the data folder you'll see two folders:

• live
• snapshots

The live folder contains subfolders scoped by test name, and reflects the currently executing state of that test. We generate snapshots from this live state, or restore the live state from snapshots.

The snapshots folder contains a tree of folders that reflects the state snapshot tree. An example path here might be:

./data/snapshots/3_accounts/e2e_token_contract/mint/snapshot

This shows 3 snapshots building on each other.

• 3_accounts added 3 accounts.
• e2e_token_contract did some specifics to that test (deployed a token, bad account, etc).
• mint minted some funds, specific to tests that needed minted funds.

You can erase any level of the tree, and the next run will rebuild from that point.

The snapshot function has the following signature.

  public async snapshot<T>(
    name: string,
    apply: (context: SubsystemsContext) => Promise<T>,
    restore: (snapshotData: T, context: SubsystemsContext) => Promise<void> = () => Promise.resolve(),
  );

• name: name of the snapshot, eg 3_accounts.
• apply: A function that actually does the state shift, e.g. deploying the accounts. It should return an object that is JSON serialisable that contains the necessary information to restore the state, e.g. the account addresses.
• restore: A function that takes first argument the data that was returned by apply. You can use this to restore live objects within the test.

Originally I had the concept of "pushing" and "popping" snapshots. But the popping aspect was a footgun, and would force use of the snapshot engine. Now a single test file can build a stack of snapshots, but can't pop. It's a simpler design and encourages creation of a new test file if that test file wants to start from a different state. i.e. you can imagine that a single test file sits at one of the nodes of the snapshot tree.

If you have snapshot state, this gets running the contract tests down from 3m to 2m. However the real win is the turnaround time when you're iterating on a single test, which you can now run in sometimes as little as 7s.

[charlielye]

• feat: e2e token contract can run in 2m with snapshots and test separation. #5526 : 2 dependent PRs (#5521 , #5643 ) 👈
• master

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

Join @charlielye and the rest of your teammates on Graphite

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_successful_decrypting_time_in_ms (8): 801 (+239%)
• note_trial_decrypting_time_in_ms (8): 161 (+369%)
• note_trial_decrypting_time_in_ms (32): 54.7 (+219%)

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	676	676	676
l1_rollup_calldata_gas	6,424 (+1%)	6,412	6,424
l1_rollup_execution_gas	585,757	585,745	585,757
l2_block_processing_time_in_ms	1,301	4,773 (+3%)	9,380 (+6%)
note_successful_decrypting_time_in_ms	⚠️ 801 (+239%)	545 (-10%)	1,003 (+7%)
note_trial_decrypting_time_in_ms	⚠️ 161 (+369%)	⚠️ 54.7 (+219%)	27.1 (-51%)
l2_block_building_time_in_ms	10,493	36,704 (-1%)	73,128 (+1%)
l2_block_rollup_simulation_time_in_ms	10,458	36,589 (-1%)	72,902 (+1%)
l2_block_public_tx_process_time_in_ms	4,915 (-2%)	19,142 (-2%)	38,334

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,534 (+3%)	26,588
note_history_successful_decrypting_time_in_ms	1,217 (-4%)	2,342
note_history_trial_decrypting_time_in_ms	39.0 (-36%)	98.9 (-1%)
node_database_size_in_bytes	18,604,112	35,008,592
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	142 (-1%)	44,377	26,164
private-kernel-inner	152 (-1%)	71,744	26,164
private-kernel-ordering	107 (-1%)	50,830	39,026
base-parity	3,951	128	311
root-parity	1,081 (-1%)	1,244	311
base-rollup	13,457 (+1%)	110,464	861
root-rollup	49.1	4,359	725
public-kernel-app-logic	79.1	47,695	40,661
public-kernel-tail	111 (-1%)	53,372	7,125
merge-rollup	10.3 (+6%)	2,568	861
public-kernel-teardown	76.3 (-1%)	47,695	40,661
public-kernel-setup	75.5 (-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	10.0	16.2 (-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.583	0.500 (-1%)	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.0	71.9	231	448	866	1,727 (+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.471	0.444	0.420	0.418	0.412 (+1%)	0.413 (+1%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	54.1	107 (+1%)	335	670 (+2%)	1,303 (+1%)	2,597 (+2%)	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.478	0.484 (+1%)	0.456	0.460 (+1%)	0.453 (+1%)	0.452 (+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	61.3 (+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.535 (+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,319	895 (-1%)	5,085 (-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	425	296 (-1%)	795 (-1%)	403	1,284 (-1%)	443 (-1%)

[AztecBot]

Docs Preview

Hey there! 👋 You can check your preview at https://6616a2ac11b5e6007941a428--aztec-docs-dev.netlify.app