feat: Run block-proving jobs in parallel by forking world-state

[spalladino]

Goal

We want to be able to kick off more than one prove(blocknumber) job in the prover-node at the same time.

We currently cannot do it because the prover-node has a single world-state, and building a proof modifies world-state. In particular, preparing the inputs for base rollups modifies state trees, and finalising the block modifies the archive tree.

Why?

This'll be needed for the proving integration contest, in case we generate blocks faster than the time it takes to prove them.

It may still be useful once we move to epoch proving and sequencer-prover coordination, since the same prover could be picked for generating proofs for two consecutive epochs.

How?

The easy way

Easiest approach is to keep everything as-is today, and clone the world state before kicking off a job. Eventually, once we implement Phil's world-state, we can use the writeable world-state snapshots for this. This is what we're doing on this PR.

The not-so-easy way

Another approach is to decouple input-generation from proving. Today the prover-orchestrator is responsible for computing all inputs, but this is not strictly needed. We can have one component that generates all inputs, modifies world-state, and outputs a graph of proving jobs (as Mitch commented here). And then another component that orchestrates the execution of proving jobs exclusively based on their dependencies.

Note that this new component would be a good fit for generating a block in the sequencer, which today runs an orchestrator without proving enabled to get to a block header.

It's unclear whether this component should run everything serially (like the old block builder did), or it makes more sense to fan out circuit simulation jobs to workers (like the proving orchestrator can do now).

[AztecBot]

Benchmark results

Metrics with a significant change:

• avm_simulation_time_ms (AuthRegistry:set_authorized): 6.20 (-32%)
• avm_simulation_time_ms (Token:transfer_public): 32.4 (-30%)
• avm_simulation_time_ms (Token:_increase_public_balance): 9.74 (-88%)
• avm_simulation_time_ms (FPC:pay_refund_with_shielded_rebate): 141 (+92%)
• protocol_circuit_proving_time_in_ms (base-parity): 1,120 (-35%)

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.

Proof generation

Each column represents the number of threads used in proof generation.

Metric	1 threads	4 threads	16 threads	32 threads	64 threads
proof_construction_time_sha256_ms	5,880 (+3%)	1,581 (+2%)	713 (+1%)	779 (+4%)	773 (+1%)
proof_construction_time_sha256_30_ms	12,164 (+3%)	3,211 (+3%)	1,417 (+1%)	1,439 (+1%)	1,486 (+1%)
proof_construction_time_sha256_100_ms	44,838 (+2%)	12,672 (+2%)	5,716 (+1%)	5,605 (+1%)	5,592 (+2%)
proof_construction_time_poseidon_hash_ms	80.0 (+3%)	34.0	34.0	59.0 (-2%)	89.0 (+1%)
proof_construction_time_poseidon_hash_30_ms	1,557 (+3%)	426 (+3%)	204 (+2%)	228 (+3%)	275 (+5%)
proof_construction_time_poseidon_hash_100_ms	5,760 (+3%)	1,552 (+3%)	679	732 (+2%)	755 (+1%)

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	4 txs	8 txs	16 txs
l1_rollup_calldata_size_in_bytes	740	740	740
l1_rollup_calldata_gas	6,704	6,722	6,716
l1_rollup_execution_gas	611,971	612,140	612,285
l2_block_processing_time_in_ms	248 (+3%)	451 (+1%)	829 (+5%)
l2_block_building_time_in_ms	9,657 (-1%)	18,625	37,641 (+2%)
l2_block_rollup_simulation_time_in_ms	9,656 (-1%)	18,625	37,640 (+2%)
l2_block_public_tx_process_time_in_ms	8,021 (-2%)	16,811	35,713 (+2%)

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric	3 blocks	5 blocks
node_history_sync_time_in_ms	2,766	3,716 (+2%)
node_database_size_in_bytes	12,734,544	16,859,216
pxe_database_size_in_bytes	16,254	26,813

Circuits stats

Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit	simulation_time_in_ms	witness_generation_time_in_ms	input_size_in_bytes	output_size_in_bytes	proving_time_in_ms	proof_size_in_bytes	num_public_inputs	size_in_gates
private-kernel-init	96.3	421 (+7%)	21,846	44,858	N/A	N/A	N/A	N/A
private-kernel-inner	175	709 (+1%)	72,545	45,005	N/A	N/A	N/A	N/A
private-kernel-tail	677 (-1%)	816 (+1%)	53,216	50,574	N/A	N/A	N/A	N/A
base-parity	5.79 (-1%)	583 (-4%)	160	96.0	⚠️ 1,120 (-35%)	13,188	19.0	65,536
root-parity	110	127 (-1%)	69,084	96.0	31,843 (+3%)	13,188	19.0	4,194,304
base-rollup	2,950 (-1%)	5,360 (+3%)	182,736	664	97,099 (+1%)	14,020	45.0	16,777,216
root-rollup	97.0 (-1%)	115 (-5%)	54,525	716	28,514	13,988	44.0	4,194,304
public-kernel-setup	90.6 (-3%)	2,819	103,513	70,710	17,826 (-3%)	128,708	3,629	2,097,152
public-kernel-app-logic	105	4,230 (+3%)	103,513	70,710	10,264	128,708	3,629	1,048,576
public-kernel-tail	573 (-1%)	31,042 (+1%)	403,238	11,326	101,296 (-6%)	27,204	457	16,777,216
private-kernel-reset-tiny	184	841 (+2%)	68,621	44,750	N/A	N/A	N/A	N/A
private-kernel-tail-to-public	3,416 (+1%)	1,569	942,862	1,697	N/A	N/A	N/A	N/A
public-kernel-teardown	86.6 (-1%)	4,184 (+3%)	103,513	70,710	19,190 (+2%)	128,708	3,629	2,097,152
merge-rollup	60.1	N/A	35,742	664	N/A	N/A	N/A	N/A
undefined	N/A	N/A	N/A	N/A	69,587 (-1%)	N/A	N/A	N/A

Stats on running time collected for app circuits

Function	input_size_in_bytes	output_size_in_bytes	witness_generation_time_in_ms	proof_size_in_bytes	proving_time_in_ms
ContractClassRegisterer:register	1,344	11,731	338 (-1%)	N/A	N/A
ContractInstanceDeployer:deploy	1,408	11,731	18.1	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	11,731	473 (-1%)	N/A	N/A
FeeJuice:deploy	1,376	11,731	380 (-2%)	N/A	N/A
SchnorrAccount:constructor	1,312	11,731	176 (-1%)	N/A	N/A
SchnorrAccount:entrypoint	2,304	11,731	539 (-1%)	N/A	N/A
Token:privately_mint_private_note	1,280	11,731	219 (-1%)	N/A	N/A
FPC:fee_entrypoint_public	1,344	11,731	33.7 (+7%)	N/A	N/A
Token:transfer	1,312	11,731	452 (-8%)	N/A	N/A
AuthRegistry:set_authorized (avm)	18,491	N/A	N/A	147,456	2,457
FPC:prepare_fee (avm)	22,958	N/A	N/A	147,520	3,109 (-1%)
Token:transfer_public (avm)	61,614	N/A	N/A	147,520	18,154 (+5%)
AuthRegistry:consume (avm)	41,719	N/A	N/A	147,488	7,490 (+2%)
FPC:pay_refund (avm)	26,227	N/A	N/A	147,488	7,346 (+1%)
Benchmarking:create_note	1,344	11,731	167	N/A	N/A
SchnorrAccount:verify_private_authwit	1,280	11,731	27.5 (-3%)	N/A	N/A
Token:unshield	1,376	11,731	735 (-3%)	N/A	N/A
FPC:fee_entrypoint_private	1,376	11,731	1,027 (-6%)	N/A	N/A

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
FeeJuice:_increase_public_balance	95.6 (-1%)	8,139
FeeJuice:set_portal	9.77 (-3%)	2,362
Token:constructor	120 (-1%)	31,107
FPC:constructor	104 (+7%)	22,380
FeeJuice:mint_public	77.5 (-2%)	6,150
Token:mint_public	92.0 (+10%)	11,720
Token:assert_minter_and_mint	79.0 (-12%)	8,028
AuthRegistry:set_authorized	⚠️ 6.20 (-32%)	4,537
FPC:prepare_fee	281 (-9%)	8,812
Token:transfer_public	⚠️ 32.4 (-30%)	47,374
FPC:pay_refund	61.1 (-11%)	12,114
Benchmarking:increment_balance	1,013	7,450
Token:_increase_public_balance	⚠️ 9.74 (-88%)	8,960
FPC:pay_refund_with_shielded_rebate	⚠️ 141 (+92%)	12,663

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.158 (-5%)

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	256 leaves	512 leaves	1024 leaves
batch_insert_into_append_only_tree_16_depth_ms	2.15	3.85 (-1%)	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.8	31.7	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.111 (-1%)	0.108 (-1%)	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	11.0 (-1%)	17.5 (-3%)	31.2 (+2%)	62.3 (+6%)	117 (+5%)
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	159	287	543	1,055
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.104 (-2%)	0.102 (-3%)	0.101 (+2%)	0.107 (+6%)	0.105 (+4%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	14.0 (-2%)	26.1 (+2%)	43.9 (+2%)	82.7 (+2%)	164 (+3%)
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	109	207	355	691	1,363
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.106 (-1%)	0.105 (+2%)	0.107 (+2%)	0.102 (+2%)	0.104 (+1%)
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	16.5	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	132	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	0.105	N/A	N/A	N/A	N/A

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	63,593	665,008

Transaction size based on fee payment method

| Metric | |
| - | |

[spalladino]

Many of the changes on this PR are just moving interfaces and types around just so we can reference MerkleTreeOperations from here in circuit-types/interfaces.

[alexghr]

IIUC this is only public for testing reasons? Otherwise an instance that proves automatically could start an auto proof at the same time since this doesn't block work

[spalladino]

The idea is exposing both prove and startProof on the public API, one of them blocking until proof is submitted and the other not. To be honest I'm not sure which one we'll end up using for prover-sequencer coordination, but I wanted to keep both for the time being.

[alexghr]

Ohhhh, all prover can share a single queue (and implicitly, the same prover agents) since all the data is generated by the orchestrators 🤯. This is awesome!

[PhilWindle]

Just a couple of things.

[PhilWindle]

Instead of these paused/resume semantics, could we just syncImmediate and then put a request to fork on the job queue?

The job queue is there to give us that kind of atomicity.

[spalladino]

But can't we run into a situation where the loop in the runningPromise runs again (eg while we await for l2BlockDownloader.pollImmediate) and enqueues a collectAndProcessBlocks without a targetBlock before we manage do so?

[PhilWindle]

Is the issue that we rely on forking at a specific block and the world state can't be allowed to move past that block before we fork? Presumably this is always a problem if we are just slow to call syncImmediateAndFork?

If that's the case then yes, we need to stop the main loop performing it's own sync process like you say.

[spalladino]

Yep, exactly. I expect this issue to go away once we implement the forkable world-state, but for now we need to stop the main sync.

[PhilWindle]

This will all get cleaned up when we move to the new world state model I think.

[spalladino]

Yep, that's why I didn't worry too much about it