feat: recursive folding and decider verifier for Protogalaxy

[maramihali]

Implements the recursive folding verifier and recursive decider verifier resembling the native ones as closely as possible. Tests follow the example of the other recursive honk verifiers and native protogalaxy tests.

Additionally, I introduced a function that sequentially computes polynomials in coefficient form in the ProtoGalaxyRecursiveVerifier to avoid having to instantiate the entire Polynomial class on stdlib::bn254.

Closes AztecProtocol/barretenberg#789.
Closes AztecProtocol/barretenberg#834.

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_history_trial_decrypting_time_in_ms (10): 445 (+90%)

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 6dac6504 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,412	179,524	716,068
l1_rollup_calldata_gas	221,668	866,968	3,448,588
l1_rollup_execution_gas	314,087	984,640	3,668,177
l2_block_processing_time_in_ms	1,417 (+1%)	5,240 (-3%)	20,736
note_successful_decrypting_time_in_ms	290	969 (+9%)	3,154 (-2%)
note_trial_decrypting_time_in_ms	99.8	94.8 (-15%)	139 (-6%)
l2_block_building_time_in_ms	16,100 (-1%)	63,636 (-1%)	255,821
l2_block_rollup_simulation_time_in_ms	11,716 (-1%)	46,309 (-1%)	186,579
l2_block_public_tx_process_time_in_ms	4,350	17,238	68,886

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,315 (-5%)	31,505 (+2%)
note_history_successful_decrypting_time_in_ms	2,036 (+1%)	4,044 (+5%)
note_history_trial_decrypting_time_in_ms	171	⚠️ 445 (+90%)
node_database_size_in_bytes	3,516,446	3,551,931
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	213 (-1%)	44,681	25,561
private-kernel-ordering	165 (-1%)	43,753	14,809
base-rollup	1,196	128,338	881
root-rollup	79.3	4,088	677
private-kernel-inner	292	71,208	25,561
public-kernel-private-input	206	31,863	25,561
public-kernel-non-first-iteration	203	31,905	25,561
merge-rollup	7.64	2,608	881

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	12.1	19.7 (-3%)	15.2 (+13%)	19.7	24.4 (-4%)	66.3 (+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.625	0.637 (-7%)	0.615 (+13%)	0.545 (-1%)	0.482 (-1%)	0.441	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	82.7 (-4%)	52.3 (+2%)	253	486	921	3,570
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.471 (-4%)	0.501 (+1%)	0.438 (-2%)	0.438 (-1%)	0.435 (+1%)	0.428
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	118 (-1%)	62.9 (+1%)	375	804	1,420 (-4%)	5,619
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.498 (-2%)	0.505	0.477 (-2%)	0.490 (-3%)	0.473 (-2%)	0.472
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	68.4 (+1%)	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.599	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	15,455	32,223

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	398 (+7%)	1,085

Metric	1 public data writes
tx_sequencer_processing_time_ms	536

[ledwards2225]

Overall LGTM. My biggest complaint is probably the scarcity of documentation in the recursive verifiers. I went to the native versions hoping to find more documentation there but nope :). (Also, I can hardly blame you for the duplication across the native/stdlib verifiers since this is a pattern I started but this really highlights the need for something better!)

[ledwards2225]

Lmk if I missed something or am misunderstanding but it seems like the only place the folding recursive verifier is tested is implicitly through calls to this function. Seems worthwhile to have at least one independent test for the FoldingRecursiveVerifier. (The easiest thing would be just a single call to this function isolated in its own test but there might be a way to do it that's a bit more clear to the reader if you want to do a little more work)

[ledwards2225]

(I see now that there's a standalone failure test but I don't see a standalone success test)

[maramihali]

So the reason why we don't have a standalone folding verifier test (we used to when the decider wasn't implemented) is because we don't have certainty that what we've done is meaningfully correct until we ran the decider. What I mean is that I can give you a garbage accumulator produced from just random scalars and points, I make sure that I set the target sum to be correct, and you can fold a valid circuit on top of it, folding will succeed but that doesn't mean your result is the sandwich of several valid circuits. But only the decider can establish that the sandwich is not valid.

[ledwards2225]

I agree that we don't know that the two instances were valid until we "decide" but I don't think this means we shouldn't have a standalone test. The same could be said for an GUH recursive verifier but surely we want independent tests for that. The recursive folding verifier is an independent circuit - to me it makes sense to confirm that we can construct and verify a proof over that circuit. Anyway, you already have a standalone failure test, why not just repurpose that for a "success" test?

[ledwards2225]

LGTM (pending the standalone PG verifier test). Thanks for making updates!