feat: databus allows arbitrarily many reads per index

[ledwards2225]

TLDR: Up until now we were limited to only 1 read per entry of a databus column (see explanation of why below). This PR removes this limitation so that we can read from any row arbitrarily many times at the cost of adding one polynomial/commitment per databus column.

Note: this PR also cleans up some of the handling of ecc op wires and databus polys in various places by making better use of Flavor style getters.

Explanation: The log derivative lookup relation involves a polynomial that contains inverses, i.e. I_i = (read_term_i*write_term_i)^{-1}. These inverses only need to be computed when the relation is "active", i.e. when the row in question either contains a databus read gate or data that is being read. At all other rows, we simply set the value of the inverse polynomial to 0. This allows a subrelation of the form:

read_term * write_term * inverses - inverse_exists

Where inverse_exists is a polynomial that takes 1 if the relation is active (or equivalently, if the inverse has been computed) and 0 otherwise. Therefore, if the inverse has been computed, we check that it is indeed equal to the inverse of read_term * write_term, otherwise, the subrelation contribution is trivially 0. If we only allow a single read from each row of a bus column, the term inverse_exists can be computed as an algebraic OR of the form:

is_read_gate + read_counts - (is_read_gate * read_counts)

since both is_read_gate and read_counts are both boolean. If read_counts is no longer boolean, no such algebraic expression exists. The solution is to introduce a dedicated boolean polynomial read_tag whose values are given by min(1, read_counts), i.e. 1 if one or more reads have been performed at that row, and 0 otherwise.

Closes AztecProtocol/barretenberg#937

[AztecBot]

Benchmark results

No metrics with a significant change found.

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	5,719 (-2%)	1,552 (-1%)	713 (-1%)	781 (-1%)	771 (-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	64 txs
l1_rollup_calldata_size_in_bytes	1,412	1,412	1,412
l1_rollup_calldata_gas	9,464	9,452	9,476
l1_rollup_execution_gas	616,105	616,093	616,117
l2_block_processing_time_in_ms	1,297	4,847 (+1%)	9,650
l2_block_building_time_in_ms	44,808	176,978	353,782
l2_block_rollup_simulation_time_in_ms	44,634	176,351	352,542
l2_block_public_tx_process_time_in_ms	24,078	100,146	205,240

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,536 (+1%)	14,592 (+1%)
node_database_size_in_bytes	14,475,344	21,356,624
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	161 (+1%)	3,742	22,327 (+2%)	20,630	64,614	89,536	2,731	1,048,576
private-kernel-inner	625 (+1%)	4,550 (+6%)	42,458 (-8%)	92,318	64,614	89,536	2,731	2,097,152
private-kernel-tail	566	3,081 (+4%)	36,737 (+2%)	96,541	77,498	10,656	266	2,097,152
base-parity	6.65 (+1%)	1,247 (+9%)	2,922	128	64.0	2,208	2.00	131,072
root-parity	49.8 (-1%)	61.4 (+26%)	44,604 (+2%)	27,084	64.0	2,720	18.0	2,097,152
base-rollup	732 (-2%)	2,248 (-1%)	74,665 (+1%)	119,610	756	3,648	47.0	4,194,304
root-rollup	112	63.9 (-2%)	20,008 (+2%)	25,297	620	3,456	41.0	1,048,576
public-kernel-app-logic	521	3,006 (+1%)	47,180 (-1%)	104,941	86,302	114,784	3,520	2,097,152
public-kernel-tail	1,080	22,549 (-1%)	154,648	395,386	7,522	10,656	266	8,388,608
private-kernel-reset-small	590	2,079 (-4%)	45,432 (+1%)	120,733	64,614	89,536	2,731	2,097,152
merge-rollup	29.1	N/A	N/A	16,534	756	N/A	N/A	N/A
public-kernel-setup	632 (+1%)	N/A	N/A	104,941	86,302	N/A	N/A	N/A
public-kernel-teardown	530	N/A	N/A	104,941	86,302	N/A	N/A	N/A
private-kernel-tail-to-public	N/A	8,613 (-2%)	91,890 (-1%)	N/A	N/A	114,784	3,520	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	466	N/A	N/A	N/A	N/A
ContractInstanceDeployer:deploy	1,408	9,944	42.1 (+1%)	N/A	N/A	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	9,944	1,448 (+1%)	N/A	N/A	N/A	N/A
SchnorrAccount:constructor	1,312	9,944	994	N/A	N/A	N/A	N/A
SchnorrAccount:entrypoint	2,304	9,944	2,096	16,768	55,022 (+8%)	2,097,152	457
Token:privately_mint_private_note	1,280	9,944	1,139	N/A	N/A	N/A	N/A
Token:transfer	1,376	9,944	4,060 (-1%)	16,768	45,651 (-14%)	2,097,152	457
Benchmarking:create_note	1,312	9,944	952 (+1%)	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_public	1,344	9,944	220	N/A	N/A	N/A	N/A
SchnorrAccount:spend_private_authwit	1,280	9,944	77.3	N/A	N/A	N/A	N/A
Token:unshield	1,376	9,944	3,244	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_private	1,376	9,944	4,024	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.608 (-1%)	0.521	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	49.0 (+1%)	76.5	248	475	938 (+1%)	1,856	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.500	0.471	0.450	0.443	0.444 (+1%)	0.442	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	58.7	113 (+1%)	359 (+1%)	699	1,396 (+1%)	2,773	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.508	0.505	0.484 (+1%)	0.480	0.481	0.480	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	83,794	665,117

Transaction size based on fee payment method

| Metric | |
| - | |

[ledwards2225]

The failure seems to be related to one or more of the read_tag polynomials having a commitment equal to that of lagrange_first. The bug is minimally reproduced here where I simply add a poly to the UG flavor and set it to be equal to lagrange_first. The failure shows up in Ultra arith of the UGH recursive verifier so suggests some issue with having repeated points in the in-circuit batch_mul.

[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: fcbd510	Previous: 4ae9944	Ratio
nativeconstruct_proof_ultrahonk_power_of_2/20	4855.257489999985 ms/iter	4369.659419999991 ms/iter	1.11

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

CC: @ludamad @codygunton

[codygunton]

Replacing a value that was boolean with the boolean old value was at least 1 ✅

[codygunton]

Typo: "expected"

[codygunton]

As an illustration of the functionality this could be a tad more explicit; will update.