feat: shared mutable storage

[nventuro]

(Large) part of #4761.

This is an initial implementation of SharedMutableStorage, with some limitations. I think those are best worked on in follow-up PRs, once we have the bones working.

The bulk of the SharedMutable pattern is in ScheduledValueChange, a pure Noir struct that has all of the block number related logic. SharedMutable then makes a state variable out of that struct, adding public storage access both in public and private (via historical reads - see #5379), and using the new request_max_block_number function (from #5251).

I made an effort to test as much as I could of these in Noir, with partial success in the case of SharedMutable due to lack of certain features, notably noir-lang/noir#4652. There is also an end-to-end test that goes through two scheuled value changes, showing that scheduled values do not affect the current one.

I added some inline docs but didn't include proper docsite pages yet so that we can discuss the implementation, API, etc., and make e.g. renamings less troublesome.

Notable implementation details

I chose to make the delay a type parameter instead of a value mostly because of two reasons:

• it lets us nicely serialize and deserialize ScheduledValueChange without including this field (which we are not currently interested in storing)
• it lets us declare a state variable of type SharedMutable<T, DELAY> without having to change the signature of the new function, which is automatically injected by the macro.

Overall I think this is fine, especially since we may later make the delay mutable (see below), but still worth noting.

Additionally, I created a simple public_storage module to get slightly nicer API and encapsulation. This highlighted a Noir issue (noir-lang/noir#4633), which currently only affects public historical reads but will also affect current reads once we migrate to using the AVM opcodes.

Future work

• feat(StateVariables): Extend SharedMutable to work with multi-field values #5491
• Storage slot allocation for SharedMutable #5492 (this takes care of padding during storage slot allocation)
• Make the SharedMutable block of change configurable #5501
• feat(StateVariables): Make SharedMutable's delay mutable #5493

[nventuro]

There's some seemingly redundant type declarations (e.g. let scheduled_value: ScheduledValueChange<T, DELAY> = ScheduledValueChange::deserialize(raw_fields);) - these are required because of noir-lang/noir#4653.

[AztecBot]

Benchmark results

Metrics with a significant change:

• circuit_simulation_time_in_ms (private-kernel-init): 194 (+36%)
• circuit_simulation_time_in_ms (private-kernel-inner): 371 (+139%)
• circuit_simulation_time_in_ms (private-kernel-ordering): 161 (+50%)
• circuit_simulation_time_in_ms (base-rollup): 15,525 (+16%)
• circuit_simulation_time_in_ms (public-kernel-app-logic): 239 (+199%)
• circuit_input_size_in_bytes (base-rollup): 136,795 (+24%)
• circuit_output_size_in_bytes (private-kernel-ordering): 26,992 (-31%)
• circuit_output_size_in_bytes (public-kernel-tail): 17,323 (+143%)
• tx_pxe_processing_time_ms (0): 1,710 (+46%)
• tx_pxe_processing_time_ms (1): 1,253 (+52%)
• tx_size_in_bytes (0): 31,315 (-22%)
• tx_sequencer_processing_time_ms (1): 786 (+87%)
• l2_block_building_time_in_ms (8): 13,830 (+33%)
• l2_block_building_time_in_ms (32): 50,919 (+37%)
• l2_block_building_time_in_ms (64): 100,995 (+38%)
• l2_block_public_tx_process_time_in_ms (8): 7,102 (+45%)
• l2_block_public_tx_process_time_in_ms (32): 27,973 (+46%)
• l2_block_public_tx_process_time_in_ms (64): 56,028 (+46%)
• note_successful_decrypting_time_in_ms (8): 221 (-22%)

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,412	6,400	6,418
l1_rollup_execution_gas	585,745	585,733	585,751
l2_block_processing_time_in_ms	1,304 (-1%)	4,691 (-1%)	9,368 (+1%)
note_successful_decrypting_time_in_ms	⚠️ 221 (-22%)	553 (+3%)	982 (+3%)
note_trial_decrypting_time_in_ms	72.0 (+21%)	67.0 (+44%)	55.8 (-26%)
l2_block_building_time_in_ms	⚠️ 13,830 (+33%)	⚠️ 50,919 (+37%)	⚠️ 100,995 (+38%)
l2_block_rollup_simulation_time_in_ms	9,119 (-11%)	32,328 (-12%)	63,882 (-12%)
l2_block_public_tx_process_time_in_ms	⚠️ 7,102 (+45%)	⚠️ 27,973 (+46%)	⚠️ 56,028 (+46%)

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,352 (-2%)	26,631 (-1%)
note_history_successful_decrypting_time_in_ms	1,239 (+9%)	2,365 (+7%)
note_history_trial_decrypting_time_in_ms	58.0 (+69%)	135 (+72%)
node_database_size_in_bytes	18,634,832	34,975,824
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	⚠️ 194 (+36%)	44,377	27,161 (+4%)
private-kernel-inner	⚠️ 371 (+139%)	72,722 (+1%)	27,142 (+4%)
private-kernel-ordering	⚠️ 161 (+50%)	51,827 (+2%)	⚠️ 26,992 (-31%)
base-parity	4,149 (+8%)	128	311
root-parity	1,256 (+13%)	1,244	311
base-rollup	⚠️ 15,525 (+16%)	⚠️ 136,795 (+24%)	861
root-rollup	50.0 (+2%)	4,359	725
public-kernel-app-logic	⚠️ 239 (+199%)	41,542 (-13%)	34,508 (-15%)
public-kernel-tail	142 (+26%)	47,355 (-11%)	⚠️ 17,323 (+143%)
merge-rollup	9.65 (-11%)	2,568	861
public-kernel-teardown	76.5	47,695	40,661
public-kernel-setup	75.2 (-1%)	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.0 (-1%)	16.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.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.584 (-1%)	0.495	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	71.9	232	446	868	1,720 (-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.472	0.444	0.423 (+1%)	0.417	0.413	0.411 (-1%)	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	54.2	107	334 (-1%)	662	1,308	2,612 (-1%)	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	104 (-1%)	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.481	0.456 (-1%)	0.456	0.454	0.454	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.4 (+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.537 (+1%)

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	⚠️ 31,315 (-22%)	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,710 (+46%)	⚠️ 1,253 (+52%)	4,012 (+1%)

Metric	0 public data writes	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	10.9	⚠️ 786 (+87%)	282 (+1%)	735 (+1%)	368 (+1%)	1,200 (-1%)	435 (+1%)

[LHerskind]

The noir tests looks sweet 😎 Added a few minor comments but this is great work

[LHerskind]

Something feels weird here, that if I read really far back, the "pre" might not be the actual value.

Like. At block 10 value might be (a,b,c) and then later it becomes (b,d,e) but If I then say read at 10, I would read the pre as b.

It makes sense, was just from the naming that it is what sprung to mind.

[nventuro]

I'm not sure I follow your example, could you provide concrete values for c and e?

But yes, values do move from post to pre when a new change is scheduled. Clients that have not seen the new scheduled change will read post, while clients that have seen the change will read pre. The important thing is that these values will be the same, and all reads will be valid (as long as max_block_number is properly constrained).

This is what the assert_block_horizon_invariants helper function tests: current_value returns the same value at the historical block number and at the block horizon, even if a new change is scheduled as early as possible (i.e. in the block following the historical block).

[LHerskind]

Just thinking about the -1. So we are having the -1 to make sure that the block horizon ends before the change occurs.

But probably be nicce to have some better clarity on why it is not needed for the historical_block_number + DELAY.

Like, If I m just thinking of an execution where you havae

get_block_horizon(current_block_number) <-- horizon would be current + delay
schedule_change(new, current_block_number) <-- block_of_change would be current + delay

Which sounds weird?

But as we are constraining the functions in the shared_mutable to only use the get_block_horizon in private, you cannot really get this case, as the current cannot be used.

---

Rambly rambler

[nventuro]

why it is not needed for the historical_block_number + DELAY.

This is what the comments and the diagram above try to convey: the earliest a new block of change could be is historical + 1 + DELAY, so the missing -1 is because it cancels out the +1.

Re. get_block_horizon, yes, its meant to be a value consumed in private with some historical block number. If you pass the current block in public then you'll get an invalid horizon, because as you point out you could immediately schedule a new change in the same block.

I'll add some comments and do some light renamings to make it clearer that get_current_at() can be called in both private and public, while get_block_horizon() should be private only (unless you know what you're doing).

Regardless, this is ultimately a helper data structure that would likely only be used by SharedMutable and not an end user, so I'm not too worried.

[LHerskind]

Would likely be nice to test a case with larger structs for the pre and post to ensure working as expected, looks mainly to be single fields here?

It might be too disgusting to get working before we can do N*2+1 as the size of the serialization though.

[nventuro]

Yeah ScheduledValueChange by itself would be fine since it doesn't use T for anything, the problem will be accesing storage due to incomplete support for numeric generics in Noir, as mentioned in #5492.

[benesjan]

Great work. It's lovely that we can do this now without capsules and popping pills (@LHerskind 🤪). Just added some nits and typo fixes. Feel free to merge once addressed.

[benesjan]

A bit off-topic but and for another PR but I think that request_max_block_number does not communicate well enough what it does and I had to look around codebase to figure it out since I was not aware of your work on it. Based on the name I would expect it to be some kind of getter.

I would rename it to set_max_tx_inclusion_block_number. I know it's a bit too verbose but I think it's ok in this case.

WDYT?

[nventuro]

Ah agreed, yes. I like your suggestion, thanks!