fix: Simplify ECCVM prover constructor and add a TODO

[ledwards2225]

Simplify ECCVM prover constructor and clarify the confusion around what we thought was the use of uninitialized polynomials via an issue and a TODO.

Note: I think there may have been a merge mistake or something in Cody's recent PR (which I approved) that left the ECCVM prover constructors in a very weird state. (Also there was a WORKTODO left in code). There is still some weirdness (captured in the TODO) but hopefully this clarifies the situation a bit.

ClientIVCBench/Full/6 22891 ms 17769 ms 1

[AztecBot]

Benchmark results

Metrics with a significant change:

• note_successful_decrypting_time_in_ms (8): 202 (-17%)
• note_trial_decrypting_time_in_ms (8): 102 (+133%)
• note_trial_decrypting_time_in_ms (64): 103 (+243%)

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	6,400	6,412
l1_rollup_execution_gas	585,757	585,733	585,745
l2_block_processing_time_in_ms	1,301 (-2%)	4,753	9,338 (-2%)
note_successful_decrypting_time_in_ms	⚠️ 202 (-17%)	529 (+5%)	886 (-3%)
note_trial_decrypting_time_in_ms	⚠️ 102 (+133%)	39.6 (-65%)	⚠️ 103 (+243%)
l2_block_building_time_in_ms	10,383	37,765 (+1%)	72,198 (-3%)
l2_block_rollup_simulation_time_in_ms	10,269	37,365 (+1%)	71,446 (-3%)
l2_block_public_tx_process_time_in_ms	4,897 (-1%)	19,129 (-1%)	38,014 (-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	14,369 (-1%)	26,755 (-3%)
note_history_successful_decrypting_time_in_ms	1,126 (+1%)	2,204 (-1%)
note_history_trial_decrypting_time_in_ms	41.9 (-4%)	75.7 (-3%)
node_database_size_in_bytes	18,608,208	35,049,552
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	143	44,281	26,164
private-kernel-inner	152	71,648	26,164
private-kernel-ordering	112	50,830	39,026
base-parity	3,944 (+2%)	128	311
root-parity	1,053 (-6%)	1,244	311
base-rollup	13,285 (-1%)	110,464	861
root-rollup	49.4 (-1%)	4,359	725
public-kernel-app-logic	79.2 (-1%)	47,599	40,661
public-kernel-tail	112 (-1%)	53,372	7,125
merge-rollup	10.4 (-3%)	2,568	861
public-kernel-teardown	75.7 (+3%)	47,599	40,661
public-kernel-setup	74.9 (-1%)	47,599	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.0 (-2%)	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.494 (-2%)	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 (-1%)	72.4	232	445	868	1,725 (-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 (-1%)	0.447	0.422	0.416	0.413	0.413	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	54.3 (-1%)	106 (-1%)	335 (-1%)	660	1,310	2,606 (-1%)	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.480 (-1%)	0.480	0.456	0.455	0.453	0.453 (-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	60.9
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.533

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,172 (+2%)	820	4,001 (+4%)

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	419 (-1%)	285 (+4%)	737 (+4%)	367 (+4%)	1,204 (-1%)	429 (+3%)

[lucasxia01]

Nice, looks good to me. Would be curious to see effects on benchmarks though

[lucasxia01]

In ulltra/goblin_ultra, we go the other way: construct a proving_key and then construct a prover_polynomials from that. I supposed its not a big deal if we do it like this although things are inconsistent.

[ledwards2225]

yeah I tried to capture this in the TODO. It used to be the case that the pkey "owned" the polys and prover_polys was just an immutable view into them. That's changed so now one is really just a copy of the other (without the expense due to the shared memory), plus the shifted polys but those don't use additional memory. I think its possible we should do away with one or the other. Maybe pkey just has a prover_polys

[lucasxia01]

what's the impact on client ivc bench for removing these copys?

[ledwards2225]

added to the description. 22.8

[lucasxia01]

seems like none or very little impact?

[lucasxia01]

So since these have already been shared before, this line doesn't do anything correct, as the backing_memory, size, and coeff ptr are the same?

[ledwards2225]

Correct