feat: enable honk_recursion through acir

[lucasxia01]

We want to be able to verify honk proofs without adding a new opcode. The workaround that this PR introduces is adding a flag that determines whether to create a plonk vs a honk recursion constraint based on which proof system we're using to prove. If we are using ultra honk, we will generate a honk recursion constraint and the same for plonk.

This will need to be reverted after the offsite: AztecProtocol/barretenberg#1013.

Please read contributing guidelines and remove this line.

[AztecBot]

Benchmark results

Metrics with a significant change:

• protocol_circuit_proving_time_in_ms (private-kernel-inner): 46,189 (+17%)
• protocol_circuit_proving_time_in_ms (private-kernel-tail-to-public): 105,503 (+16%)
• protocol_circuit_proving_time_in_ms (private-kernel-tail): 44,755 (+22%)
• protocol_circuit_proving_time_in_ms (public-kernel-tail): 181,862 (+18%)

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,725	1,548	700	765 (-2%)	776
proof_construction_time_sha256_30_ms	11,733	3,110 (-1%)	1,403	1,419 (-2%)	1,465
proof_construction_time_sha256_100_ms	44,501 (+1%)	11,667 (-1%)	5,415	5,366	5,335
proof_construction_time_poseidon_hash_ms	79.0	34.0	34.0 (-3%)	57.0 (-2%)	86.0
proof_construction_time_poseidon_hash_30_ms	1,480 (-3%)	419	202	223 (-3%)	264 (-1%)
proof_construction_time_poseidon_hash_100_ms	5,735	1,563	726	787 (-2%)	796

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	1,412	1,412	1,412
l1_rollup_calldata_gas	9,464	9,476	9,452
l1_rollup_execution_gas	616,105	616,117	616,093
l2_block_processing_time_in_ms	1,289 (-4%)	4,835	9,601
l2_block_building_time_in_ms	45,805	181,372 (-1%)	362,818
l2_block_rollup_simulation_time_in_ms	45,633	180,728 (-1%)	361,548
l2_block_public_tx_process_time_in_ms	25,307 (+1%)	102,919 (-1%)	210,648

L2 chain processing

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

Metric	3 blocks	5 blocks
node_history_sync_time_in_ms	9,496	14,631 (+1%)
node_database_size_in_bytes	14,467,152	21,368,912
pxe_database_size_in_bytes	18,071	29,868

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	proving_time_in_ms	input_size_in_bytes	output_size_in_bytes	proof_size_in_bytes	num_public_inputs	size_in_gates
private-kernel-init	136 (+1%)	477 (-3%)	12,691 (+2%)	20,630	64,614	89,536	2,731	524,288
private-kernel-inner	405	940 (-6%)	⚠️ 46,189 (+17%)	92,318	64,614	89,536	2,731	2,097,152
private-kernel-tail	583 (+1%)	2,703 (-14%)	⚠️ 44,755 (+22%)	96,541	77,732	11,648	297	2,097,152
base-parity	6.46 (-2%)	1,239 (-2%)	2,858 (-1%)	128	64.0	2,208	2.00	131,072
root-parity	48.9 (-2%)	60.2	50,972 (+14%)	27,084	64.0	2,720	18.0	2,097,152
base-rollup	753 (+4%)	2,417 (+5%)	86,565 (+15%)	119,734	756	3,648	47.0	4,194,304
root-rollup	110 (-2%)	75.8 (+18%)	22,678 (+15%)	25,297	620	3,456	41.0	1,048,576
public-kernel-app-logic	537	3,215 (+4%)	54,352 (+13%)	105,253	86,550	116,768	3,582	2,097,152
public-kernel-tail	1,119 (-1%)	24,605 (+10%)	⚠️ 181,862 (+18%)	401,002	7,646	11,648	297	8,388,608
private-kernel-reset-small	589	1,973 (-7%)	50,806 (+10%)	120,733	64,614	89,536	2,731	2,097,152
merge-rollup	28.5 (-2%)	N/A	N/A	16,534	756	N/A	N/A	N/A
public-kernel-setup	640	N/A	N/A	105,253	86,550	N/A	N/A	N/A
public-kernel-teardown	541	N/A	N/A	105,253	86,550	N/A	N/A	N/A
private-kernel-tail-to-public	N/A	8,196 (-4%)	⚠️ 105,503 (+16%)	N/A	N/A	116,768	3,582	4,194,304

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	size_in_gates	num_public_inputs
ContractClassRegisterer:register	1,344	9,944	462 (-1%)	N/A	N/A	N/A	N/A
ContractInstanceDeployer:deploy	1,408	9,944	41.2 (-2%)	N/A	N/A	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	9,944	1,679 (-2%)	N/A	N/A	N/A	N/A
SchnorrAccount:constructor	1,312	9,944	1,428 (-3%)	N/A	N/A	N/A	N/A
SchnorrAccount:entrypoint	2,304	9,944	2,608 (-1%)	16,768	53,286 (+8%)	2,097,152	457
Token:privately_mint_private_note	1,280	9,944	1,566 (-5%)	N/A	N/A	N/A	N/A
Token:transfer	1,376	9,944	4,915 (-2%)	16,768	52,667 (+11%)	2,097,152	457
Benchmarking:create_note	1,344	9,944	1,403	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_public	1,344	9,944	227	N/A	N/A	N/A	N/A
SchnorrAccount:spend_private_authwit	1,280	9,944	77.8 (+1%)	N/A	N/A	N/A	N/A
Token:unshield	1,376	9,944	3,803 (+2%)	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_private	1,376	9,944	4,654 (+2%)	N/A	N/A	N/A	N/A

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.5 (-1%)	17.0	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.606 (-1%)	0.520	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	48.5 (-1%)	76.2 (-1%)	246 (-1%)	477	931 (-1%)	1,832 (-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.495 (-1%)	0.470 (-1%)	0.446 (-1%)	0.445	0.440 (-1%)	0.438 (-1%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	58.0 (-1%)	113	356 (-1%)	703	1,389	2,758 (-1%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	106	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.502 (-1%)	0.505	0.483 (-1%)	0.482	0.480	0.479 (-1%)	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	62.7
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	107
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.555

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	84,050	665,267

Transaction size based on fee payment method

| Metric | |
| - | |

[vezenovm]

Let's just make an issue for having a better strategy to distinguish between recursive verifiers now that we have proofs of varying size. We will need some kind of circuit constant as it needs to be part of the circuit definition. We could probably add some constant recursion separator to the recursive aggregation opcode.

[vezenovm]

Suggested change

	# Construct and verify a MegaHonk proof on one non-recursive program using the new witness stack workflow
	# Construct and verify a UltraHonk proof on one non-recursive program using the new witness stack workflow

?

[lucasxia01]

oops forgot to fix this. Oh well

[vezenovm]

Any reason this one is pedersen and the other is sha256?
We should add a TODO for bringing back a double_verify_nested_proof

[lucasxia01]

nah, I was just picking different ones to increase variability. We should be able to bring this back in other PR which adds the verify_honk_proof test program.