feat: Implement recursive verification in the parity circuits

[PhilWindle]

This PR introduces recusive verification to the parity circuits. The base parity circuits are verified in the root parity circuit and the root parity circuit is verified by the root rollup.

[github-actions]

Changes to circuit sizes

Generated at commit: b6bb9044ff1ad99158a1e2075e215bffde3afeae, compared to commit: 405bdf6a297b81e0c3fda303cf2b1480eaea69f1

🧾 Summary (100% most significant diffs)

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
parity_root	+1,795 ❌	+520.29%	+987,776 ❌	+1237.64%
rollup_root	+565 ❌	+68.82%	+221,488 ❌	+284.33%
parity_base	+2 ❌	+0.58%	0 ➖	0.00%

---

Full diff report 👇

Program	ACIR opcodes (+/-)	%	Circuit size (+/-)	%
parity_root	2,140 (+1,795)	+520.29%	1,067,587 (+987,776)	+1237.64%
rollup_root	1,386 (+565)	+68.82%	299,386 (+221,488)	+284.33%
parity_base	347 (+2)	+0.58%	79,811 (0)	0.00%

[alexghr]

Looks there are two classes the same name RootParityInput. There's this one and then there's the one in yarn-project/circuits.js/src/structs/parity/root_parity_input.ts.
Should this be renamed to match its noir counterpart RootRollupParityInput?

[PhilWindle]

Good spot, I have deleted this one, it's not used

[alexghr]

🙇

[alexghr]

Are keys generated on demand?

Later edit: yep, see getVerificationKeyDataForCircuit that fills up the promise cache

[PhilWindle]

Yeah, verification keys are now written out whenever we generate a proof. This is a bit inefficient as we re-create the same vk everytime we run the circuit. But creating them at startup is also inefficient as most of the work in creating a vk is first creating the proving key, which we are doing anyway when we generate the proof.

The ultimate solution will be determined by the characteristics of Honk and what that looks like in terms of it's keys and proof generation times. It might be that we run a long running process, or maybe we can read the proving keys in from file or something. All of this key caching stuff is subject to change.

[alexghr]

I think it's worth reading the two files in parallel here.

Suggested change

	const rawFields = await fs.readFile(`${filePath}/${VK_FIELDS_FILENAME}`, { encoding: 'utf-8' });
	const rawBinary = await fs.readFile(`${filePath}/${VK_FILENAME}`);
	const [rawFields, rawBinary] = await Promise.all([
	fs.readFile(`${filePath}/${VK_FIELDS_FILENAME}`, { encoding: 'utf-8' }),
	fs.readFile(`${filePath}/${VK_FILENAME}`)
	]);

[PhilWindle]

Done

[alexghr]

Does the rawBinary not need the slice as the fields version of the vk?

[PhilWindle]

No, the raw data is in the precise format for later consumption by a verifier. We don't want to modify this.

[alexghr]

hm, do we have to await this call? I think it would be safe to let this run async because the cache is updated sync and every call to verifyProof awaits the promise read from the cache

[PhilWindle]

Yeah, we have to await it. It reads files from a directory that we delete a couple of lines further down.

[alexghr]

There are instances where acvm returns a single value instead of a a="b" formatted string? Would it be worth using a TOML parser?

[PhilWindle]

No, this is left from some debugging. Have removed.

[AztecBot]

Benchmark results

Metrics with a significant change:

• circuit_simulation_time_in_ms (root-parity): 101 (+54%)
• circuit_input_size_in_bytes (root-parity): 27,064 (+2076%)
• circuit_input_size_in_bytes (root-rollup): 11,518 (+153%)
• circuit_output_size_in_bytes (base-parity): 64.0 (-76%)
• circuit_output_size_in_bytes (root-parity): 64.0 (-76%)
• note_history_trial_decrypting_time_in_ms (5): 99.6 (+196%)
• note_successful_decrypting_time_in_ms (8): 200 (-19%)
• note_trial_decrypting_time_in_ms (8): 94.3 (+151%)
• note_trial_decrypting_time_in_ms (32): 74.2 (+95%)

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	772	772	772
l1_rollup_calldata_gas	6,820	6,808	6,832
l1_rollup_execution_gas	587,301	587,289	587,313
l2_block_processing_time_in_ms	1,528 (-3%)	5,458 (-4%)	10,248 (-1%)
note_successful_decrypting_time_in_ms	⚠️ 200 (-19%)	673 (+5%)	1,117 (-1%)
note_trial_decrypting_time_in_ms	⚠️ 94.3 (+151%)	⚠️ 74.2 (+95%)	74.0 (-37%)
l2_block_building_time_in_ms	19,356 (+2%)	75,439 (+2%)	149,769 (+2%)
l2_block_rollup_simulation_time_in_ms	19,145 (+2%)	74,677 (+2%)	148,293 (+2%)
l2_block_public_tx_process_time_in_ms	8,785 (+1%)	34,489 (+2%)	68,493 (+2%)

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	16,482	30,274 (+1%)
note_history_successful_decrypting_time_in_ms	1,407 (+3%)	2,754 (+7%)
note_history_trial_decrypting_time_in_ms	⚠️ 99.6 (+196%)	102 (+51%)
node_database_size_in_bytes	20,734,032	37,642,320 (+1%)
pxe_database_size_in_bytes	29,868	59,425

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	163 (+4%)	47,763	31,978
private-kernel-inner	187 (+6%)	80,794	31,978
private-kernel-ordering	175 (+29%)	57,732	49,313
base-parity	9.11 (-1%)	128	⚠️ 64.0 (-76%)
root-parity	⚠️ 101 (+54%)	⚠️ 27,064 (+2076%)	⚠️ 64.0 (-76%)
base-rollup	12,150 (+2%)	110,926	957
root-rollup	60.3 (+21%)	⚠️ 11,518 (+153%)	821
public-kernel-app-logic	1,593 (+3%)	62,017	26,202
public-kernel-tail	4,419 (+7%)	168,566	3,812
merge-rollup	3,134 (-2%)	2,760	957
public-kernel-teardown	127 (+7%)	62,017	34,711
public-kernel-setup	136 (+5%)	62,017	34,711

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	11.0	17.7 (-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.7	31.8	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.643 (+1%)	0.546 (-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	51.5	80.1 (-1%)	260 (-1%)	503	985	1,935 (-1%)	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	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.528	0.495 (-1%)	0.474 (-1%)	0.469	0.467	0.464	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	60.8 (-1%)	120 (-1%)	374 (-1%)	740	1,470	2,902 (-1%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	105	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.535 (-1%)	0.539 (-1%)	0.510	0.509	0.508	0.507	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	66.8 (-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	108
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.588 (-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	51,411	536,920

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	897	1,145	1,345

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,288 (+4%)	928 (+8%)	3,515

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	880 (+5%)	783 (+3%)	1,399 (+4%)	922 (+3%)	2,148 (+3%)	1,104 (+2%)

[sirasistant]

Noir side looking good, only some nits on simplifying serialization/deserialization

[sirasistant]

Suggested change

	let mut fields = [0; RECURSIVE_PROOF_LENGTH];
	for i in 0..RECURSIVE_PROOF_LENGTH {
	fields[i] = self.fields[i];
	}
	fields
	self.fields

you can directly return it!

[sirasistant]

Suggested change

	let mut proof = RecursiveProof::empty();
	for i in 0..RECURSIVE_PROOF_LENGTH {
	proof.fields[i] = fields[i];
	}
	proof
	RecursiveProof { fields }

Same here!

[sirasistant]

Same for this struct

[sirasistant]

and this one :D