feat: Brillig heterogeneous memory cells

[sirasistant]

Since memory in brillig is typed, we can store data in a different way depending on the bit size. This PR makes brillig store memory cells as field only if they are field elements and as BigUints otherwise, avoiding conversions when doing integer operations to improve performance.

[AztecBot]

Benchmark results

Metrics with a significant change:

• circuit_simulation_time_in_ms (private-kernel-inner): 152 (-30%)
• circuit_simulation_time_in_ms (private-kernel-ordering): 109 (-33%)
• circuit_simulation_time_in_ms (public-kernel-app-logic): 79.6 (-35%)
• circuit_simulation_time_in_ms (public-kernel-tail): 112 (-32%)
• circuit_simulation_time_in_ms (public-kernel-teardown): 76.1 (-35%)
• circuit_simulation_time_in_ms (public-kernel-setup): 75.0 (-35%)
• tx_pxe_processing_time_ms (0): 1,317 (-22%)
• tx_pxe_processing_time_ms (1): 904 (-16%)
• tx_sequencer_processing_time_ms (1): 429 (-26%)
• tx_sequencer_processing_time_ms (2): 294 (-26%)
• tx_sequencer_processing_time_ms (3): 794 (-25%)
• tx_sequencer_processing_time_ms (4): 399 (-19%)
• tx_sequencer_processing_time_ms (5): 1,283 (-26%)
• tx_sequencer_processing_time_ms (8): 466 (-20%)
• l2_block_public_tx_process_time_in_ms (8): 4,968 (-19%)
• l2_block_public_tx_process_time_in_ms (32): 19,419 (-19%)
• l2_block_public_tx_process_time_in_ms (64): 39,061 (-19%)

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 aa0d2e4b 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	64 txs
l1_rollup_calldata_size_in_bytes	676	676	676
l1_rollup_calldata_gas	6,424	6,424	6,424
l1_rollup_execution_gas	585,757	585,757	585,757
l2_block_processing_time_in_ms	1,300	4,740 (+1%)	9,231 (-2%)
note_successful_decrypting_time_in_ms	232 (-6%)	612 (+15%)	1,013 (-4%)
note_trial_decrypting_time_in_ms	35.7 (-24%)	20.5 (-53%)	26.6 (-62%)
l2_block_building_time_in_ms	10,361 (-12%)	37,049 (-13%)	74,014 (-12%)
l2_block_rollup_simulation_time_in_ms	10,328 (-12%)	36,928 (-13%)	73,785 (-12%)
l2_block_public_tx_process_time_in_ms	⚠️ 4,968 (-19%)	⚠️ 19,419 (-19%)	⚠️ 39,061 (-19%)

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,038 (-3%)	25,367 (-8%)
note_history_successful_decrypting_time_in_ms	1,301 (-1%)	2,332 (-3%)
note_history_trial_decrypting_time_in_ms	67.2 (+7%)	99.5 (-2%)
node_database_size_in_bytes	18,645,072	35,078,224 (+1%)
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 (-21%)	44,377	26,164
private-kernel-inner	⚠️ 152 (-30%)	71,744	26,164
private-kernel-ordering	⚠️ 109 (-33%)	50,830	39,026
base-parity	3,932 (+3%)	128	311
root-parity	1,088	1,244	311
base-rollup	13,514 (-4%)	110,464	861
root-rollup	51.7 (+5%)	4,359	725
public-kernel-app-logic	⚠️ 79.6 (-35%)	47,695	40,661
public-kernel-tail	⚠️ 112 (-32%)	53,372	7,125
merge-rollup	9.97 (-6%)	2,568	861
public-kernel-teardown	⚠️ 76.1 (-35%)	47,695	40,661
public-kernel-setup	⚠️ 75.0 (-35%)	47,695	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.2 (+2%)	16.2 (+1%)	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.595 (+2%)	0.500 (+1%)	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	45.9	72.1 (-1%)	231	446	873	1,731	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	0.444 (-1%)	0.421	0.416	0.414	0.414	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	54.4	107	335	659	1,311	2,620	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.481	0.482	0.457	0.453	0.454	0.454 (-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	61.1
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.534

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,317 (-22%)	⚠️ 904 (-16%)	5,303 (-1%)

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	⚠️ 429 (-26%)	⚠️ 294 (-26%)	⚠️ 794 (-25%)	⚠️ 399 (-19%)	⚠️ 1,283 (-26%)	⚠️ 466 (-20%)

[TomAFrench]

Looks fine, we're adding quite a few unwraps which I think we can avoid through using if let or let ... else structures though.

I want to check the quotient stuff more carefully however.

[vezenovm]

A few style comments. The main one being I think we can panic inside of extract_integer and extract_field. All of their usage looks to be an immediate unwrap or panic anyway.

[vezenovm]

The main one being I think we can panic inside of extract_integer and extract_field. All of their usage looks to be an immediate unwrap or panic anyway.

Or as per @TomAFrench's comments. You can have the extraction methods return a result and just use ?

[TomAFrench]

I'd like to avoid unwraps/expects wherever possible unless we're enforcing their correctness inside the same function ideally. It's certainly possible that there will be brillig code which reads from memory incorrectly and we shouldn't panic on that.

[vezenovm]

I'd like to avoid unwraps/expects wherever possible unless we're enforcing their correctness inside the same function ideally.

I agree. Yeah I was thinking it would be enforced inside of extract_{field/integer} and we get rid of the unwraps on every call to these extraction methods. But as the methods in which they are called, such as the binary op evaluators, already return Results we should just maintain that flow.

[vezenovm]

Looks good! One nit

[TomAFrench]

Blocking so I can satisfy myself with the brillig quotient changes.

[TomAFrench]

I've removed the branch for brillig_quotient which acted on fields as I would expect this codepath to unconditionally error due to the new typed memory preventing us from doing integer operations on fields.

[sirasistant]

I've removed the branch for brillig_quotient which acted on fields as I would expect this codepath to unconditionally error due to the new typed memory preventing us from doing integer operations on fields.

Previous to this PR, you could do integer operations on memory cells with bit size 254, because there wasn't an assertion preventing that in arithmetic.rs. Since now that is in place, we have the following options:

• Always use the field version, ignoring the bit size passed (but this would never truncate the inputs)
• Emit the two versions depending on the bit size (field version for 254, integer otherwise)
• Emit just one version that casts to an integer and back to field to truncate the inputs if bit_size < 254, that then uses field ops

[TomAFrench]

Ok, I've had a look at the failing test cases and the culprit is truncations of field elements when we're casting them down into a smaller type. I was assuming the euclidean_division_var function was receiving only integer types.

[TomAFrench]

the new typed memory preventing us from doing integer operations on fields.

Got a bit confused on this due to seeing IntegerDiv, ignoring the BinaryFieldOp and thinking we were doing a BinaryIntOp

[TomAFrench]

Emit the two versions depending on the bit size (field version for 254, integer otherwise)
Emit just one version that casts to an integer and back to field to truncate the inputs if bit_size < 254, that then uses field ops

Either of these work for me. The second has the benefit of having (ever so slightly) smaller artifact sizes once we deduplicate brillig bytecode but easiest solution imo is just to revert to your original implementation.

[sirasistant]

Cool thanks! Will babysit this PR for merge

[sirasistant]

Seems like the gates diff is failing but I think it's not related with this PR