feat: Hook up secondary calldata column in dsl

[ledwards2225]

Previously we could use a single calldata and return_data from noir with support from the bberg backend. With this PR, noir has an interface for multiple calldata entities. The backend has support for two calldata columns (calldata and secondary_calldata). This work hooks up a second calldata column in dsl.

The main limitation of this work is that there is no way to distinguish between the two calldata columns in dsl. This is OK for the operations within a single circuit because in that context there is no important distinction between the two calldata columns (calldata, secondary_calldata). It does cause a problem however in the mechanism for linking two circuits via the databus. This is because we need to know which calldata corresponds to app data and which corresponds to previous kernel data in order to prove that the connection was made faithfully. The ideal solution is probably to treat secondary_calldata (possibly rename to app_calldata?) as a unique entity in noir (similar to how calldata and return_data are treated as different entities), rather than allowing arbitrarily many individual calldata entities. I made an issue here.

[AztecBot]

Benchmark results

Metrics with a significant change:

• protocol_circuit_simulation_time_in_ms (private-kernel-tail-to-public): 2,829 (+20%)
• avm_simulation_time_ms (AuthRegistry:set_authorized): 9.40 (+30%)
• avm_simulation_time_ms (Token:_increase_public_balance): 78.3 (+281%)
• avm_simulation_time_ms (FPC:pay_refund_with_shielded_rebate): 69.7 (-46%)
• protocol_circuit_proving_time_in_ms (base-parity): 1,802 (+65%)
• protocol_circuit_proving_time_in_ms (public-kernel-setup): 17,702 (+16%)
• protocol_circuit_proving_time_in_ms (public-kernel-app-logic): 10,309 (+17%)
• protocol_circuit_proving_time_in_ms (public-kernel-teardown): 19,107 (+17%)
• protocol_circuit_proving_time_in_ms (public-kernel-tail): 108,021 (+16%)

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,706	1,541	698 (-1%)	774 (+5%)	758 (-2%)
proof_construction_time_sha256_30_ms	11,716	3,139	1,407 (+1%)	1,438	1,475
proof_construction_time_sha256_100_ms	43,559 (-1%)	12,391 (+1%)	5,633	5,569	5,475
proof_construction_time_poseidon_hash_ms	78.0	34.0 (-28%)	34.0	58.0 (-2%)	88.0
proof_construction_time_poseidon_hash_30_ms	1,518	416	200	222 (-2%)	271 (+1%)
proof_construction_time_poseidon_hash_100_ms	5,586 (-1%)	1,507 (-1%)	671	736 (+2%)	741 (-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,714	6,704
l1_rollup_execution_gas	611,971	612,132	612,273
l2_block_processing_time_in_ms	243 (+3%)	447 (+2%)	807 (+2%)
l2_block_building_time_in_ms	9,549 (+1%)	18,674 (+1%)	37,000 (+1%)
l2_block_rollup_simulation_time_in_ms	9,549 (+1%)	18,673 (+1%)	37,000 (+1%)
l2_block_public_tx_process_time_in_ms	7,929 (+1%)	16,834 (+1%)	35,123 (+1%)

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,713 (-1%)	3,743 (+4%)
node_database_size_in_bytes	12,697,680	16,949,328
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	101 (+5%)	390 (-4%)	21,846	44,858	N/A	N/A	N/A	N/A
private-kernel-inner	167 (-4%)	689 (-5%)	72,545	45,005	N/A	N/A	N/A	N/A
private-kernel-tail	679	815 (-6%)	53,216	50,574	N/A	N/A	N/A	N/A
base-parity	5.85 (-1%)	305 (+3%)	160	96.0	⚠️ 1,802 (+65%)	13,188	19.0	65,536
root-parity	109	125 (+12%)	69,084	96.0	31,584 (+14%)	13,188	19.0	4,194,304
base-rollup	2,988 (+1%)	5,267 (-4%)	182,736	664	98,672 (+14%)	14,020	45.0	16,777,216
root-rollup	96.1 (-1%)	120 (+15%)	54,525	716	28,870 (+15%)	13,988	44.0	4,194,304
public-kernel-setup	90.5 (-1%)	2,842 (+4%)	103,513	70,710	⚠️ 17,702 (+16%)	128,708	3,629	2,097,152
public-kernel-app-logic	105 (+1%)	4,172 (+1%)	103,513	70,710	⚠️ 10,309 (+17%)	128,708	3,629	1,048,576
public-kernel-tail	575	28,343 (+8%)	403,238	11,326	⚠️ 108,021 (+16%)	27,204	457	16,777,216
private-kernel-reset-tiny	184 (-4%)	893 (+2%)	68,621	44,750	N/A	N/A	N/A	N/A
private-kernel-tail-to-public	⚠️ 2,829 (+20%)	1,552 (-5%)	942,862	1,697	N/A	N/A	N/A	N/A
public-kernel-teardown	86.0 (-1%)	4,152	103,513	70,710	⚠️ 19,107 (+17%)	128,708	3,629	2,097,152
merge-rollup	60.8 (+2%)	N/A	35,742	664	N/A	N/A	N/A	N/A
undefined	N/A	N/A	N/A	N/A	69,815 (+4%)	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	339 (-1%)	N/A	N/A
ContractInstanceDeployer:deploy	1,408	11,731	18.1 (-1%)	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	11,731	472 (-1%)	N/A	N/A
GasToken:deploy	1,376	11,731	387 (-2%)	N/A	N/A
SchnorrAccount:constructor	1,312	11,731	174 (-3%)	N/A	N/A
SchnorrAccount:entrypoint	2,304	11,731	539	N/A	N/A
Token:privately_mint_private_note	1,280	11,731	228 (+2%)	N/A	N/A
FPC:fee_entrypoint_public	1,344	11,731	29.1 (-11%)	N/A	N/A
Token:transfer	1,312	11,731	478 (-3%)	N/A	N/A
AuthRegistry:set_authorized (avm)	18,491	N/A	N/A	147,456	2,502
FPC:prepare_fee (avm)	22,958	N/A	N/A	147,520	3,232 (-3%)
Token:transfer_public (avm)	61,614	N/A	N/A	147,520	18,282 (+3%)
AuthRegistry:consume (avm)	41,719	N/A	N/A	147,488	7,619 (+1%)
FPC:pay_refund (avm)	26,227	N/A	N/A	147,488	8,004 (+7%)
Benchmarking:create_note	1,344	11,731	170 (+1%)	N/A	N/A
SchnorrAccount:verify_private_authwit	1,280	11,731	27.3 (-1%)	N/A	N/A
Token:unshield	1,376	11,731	730 (-1%)	N/A	N/A
FPC:fee_entrypoint_private	1,376	11,731	960 (-2%)	N/A	N/A

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
GasToken:_increase_public_balance	93.7 (-2%)	8,139
GasToken:set_portal	10.3 (+4%)	2,362
Token:constructor	119 (+1%)	31,107
FPC:constructor	94.4	24,011
GasToken:mint_public	78.3 (-1%)	6,150
Token:mint_public	84.5	11,720
Token:assert_minter_and_mint	97.4 (+9%)	8,028
AuthRegistry:set_authorized	⚠️ 9.40 (+30%)	4,537
FPC:prepare_fee	286 (-3%)	8,812
Token:transfer_public	28.3 (+10%)	47,374
FPC:pay_refund	72.8 (+13%)	12,114
Benchmarking:increment_balance	1,013 (+1%)	7,450
Token:_increase_public_balance	⚠️ 78.3 (+281%)	8,960
FPC:pay_refund_with_shielded_rebate	⚠️ 69.7 (-46%)	12,663

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.158 (+1%)

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 (+1%)	3.82	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	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	10.9 (-1%)	18.0 (-1%)	30.8 (+3%)	60.8 (+3%)	113 (+1%)
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 (-1%)	0.105 (-1%)	0.100 (+2%)	0.105 (+2%)	0.101 (+1%)
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	14.1 (-1%)	25.3 (+1%)	43.4 (+2%)	84.1 (+5%)	161 (+1%)
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.107 (-1%)	0.103 (+1%)	0.106 (+1%)	0.104 (+4%)	0.103 (+2%)
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	16.6	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	133	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	0.106	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,010

Transaction size based on fee payment method

| Metric | |
| - | |

[AztecBot]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'C++ Benchmark'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.05.

Benchmark suite	Current: 8b22148	Previous: fe9fdd6	Ratio
wasmconstruct_proof_ultrahonk_power_of_2/20	15496.691596 ms/iter	14515.097461999998 ms/iter	1.07
Goblin::merge(t)	223771473 ns/iter	207802562 ns/iter	1.08

This comment was automatically generated by workflow using github-action-benchmark.

CC: @ludamad @codygunton

[sirasistant]

Would it be enough if we modified the calldata type in Block to contain the user provided calldata id? that way the protocol circuits code could say that calldata 0 is always previous circuit return data and calldata 1 is always app return data, and clientIVC could assume that convention

[ledwards2225]

Would it be enough if we modified the calldata type in Block to contain the user provided calldata id? that way the protocol circuits code could say that calldata 0 is always previous circuit return data and calldata 1 is always app return data, and clientIVC could assume that convention

Yeah if you think that’s a better pattern for noir that would work too. My thought was that it was misleading to allow noir to produce arbitrarily many call data columns when bberg can only handle two but not the end of the world

[sirasistant]

Yeah but that way it's not tied to BB and the specifics of client IVC having two calldatas

[sirasistant]

I can try passing through databus ids from noir code in a nother PR!