feat: replace single bit range constraints with basic bool gates

[TomAFrench]

This PR pulls the optimisation made in noir-lang/noir#3234 across into the backend.

I've added this to the circuit builder to ensure this change gets made in the most instances of a range constraint being added, if this is undesirable then I can move it up to the dsl folder so we just deserialise a boolean range constraint into a normal constraint.

[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.

Values are compared against data from master at commit 14d39edb 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,740	3,446,956
l1_rollup_execution_gas	314,087	984,412	3,666,545
l2_block_processing_time_in_ms	1,580 (-1%)	5,531 (+5%)	21,173 (+2%)
note_successful_decrypting_time_in_ms	312 (+2%)	957 (+4%)	3,602 (+2%)
note_trial_decrypting_time_in_ms	26.8 (+26%)	82.0 (+65%)	152 (+3%)
l2_block_building_time_in_ms	16,259 (+1%)	64,857 (+2%)	259,408 (+1%)
l2_block_rollup_simulation_time_in_ms	11,819 (+1%)	47,260 (+2%)	189,186 (+1%)
l2_block_public_tx_process_time_in_ms	4,404 (+1%)	17,506 (+1%)	69,928 (+1%)

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	15,777 (-4%)	30,325 (-4%)
note_history_successful_decrypting_time_in_ms	2,135 (-5%)	4,214 (-9%)
note_history_trial_decrypting_time_in_ms	109 (-62%)	166 (-32%)
node_database_size_in_bytes	3,514,065	3,556,681
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	214	44,681	25,561
private-kernel-ordering	166	43,753	14,809
base-rollup	1,203	128,338	881
root-rollup	79.1	4,088	677
private-kernel-inner	294 (+1%)	71,208	25,561
public-kernel-private-input	207	31,863	25,561
public-kernel-non-first-iteration	205	31,905	25,561
merge-rollup	7.66	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.2	18.7 (+4%)	14.2 (-4%)	19.3 (-3%)	25.8	68.7 (-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.621	0.667 (+8%)	0.570 (-5%)	0.542 (-1%)	0.487	0.445	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.6 (+1%)	52.4 (+1%)	250	476 (-2%)	919 (+1%)	3,589 (+1%)
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.473 (+1%)	0.500	0.439	0.436	0.430	0.428
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	116 (-3%)	63.0	372 (+1%)	762 (-4%)	1,643 (+14%)	5,702 (+1%)
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.500	0.505	0.479	0.485 (-1%)	0.519 (+10%)	0.476
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	67.7 (-2%)	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.598	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,219

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	375	1,089

Metric	1 public data writes
tx_sequencer_processing_time_ms	539

[ledwards2225]

This seems ok to me but I'd like to have a bit more context since this is fairly sensitive code. Are we expecting this to be triggered "unknowingly"? I.e. is this a situation where we're adding a bunch of range constraints and some of them happen to be on single bits? If that's the case then maybe this is the best solution. Otherwise, why not simply create bool gates directly?

[TomAFrench]

is this a situation where we're adding a bunch of range constraints and some of them happen to be on single bits?

Yes, in Noir we generate range opcodes which can end up with boolean range constraints in a number of situations (enforcing types on program inputs, euclidean divisions used to extract the sign in signed arithmetic, etc.) We do this as range opcodes have the benefit of being more expressive in terms of its intent compared to a bool gate - this makes it easier for us to perform optimisations such as removing duplicate range constraints on the same witness.

However this means that we then need to perform a separate optimisation pass over the generated ACIR as a final step to replace all of these single bit range opcodes with bool gates. The reasoning behind this PR is that this can be delegated to backends so that they can implement a range constraint in whichever way they deem optimal rather than that being a choice made by the ACVM.

[ledwards2225]

LG. Thanks for the clarification