feat!: renamings of state var wrappers

[benesjan]

1. Fixes Update naming of state vars wrappers #4735
2. SharedImmutable now enforces that the value was not initialized before by doing a "value at placeholder slot is zero" check.
3. Adds empty context.is_deployment(...) and links the relevant issue in the function.

In hindsight I should have done 2. and 3. in separate PRs but once I realized that it was too much of a pain to separate.

[benesjan]

Current dependencies on/for this PR:

• feat: PublicImmutable impl #4758
• feat!: renamings of state var wrappers #4739 👈
• master

This stack of pull requests is managed by Graphite.

[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 d44d9f11 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	54,212	214,436	855,332
l1_rollup_calldata_gas	259,796	1,019,816	4,060,160
l1_rollup_execution_gas	353,982	1,139,264	4,281,561
l2_block_processing_time_in_ms	1,289 (-2%)	4,823	19,174 (+1%)
note_successful_decrypting_time_in_ms	218 (-2%)	624 (+1%)	2,274 (+5%)
note_trial_decrypting_time_in_ms	26.7 (-24%)	58.7 (+14%)	195 (+8%)
l2_block_building_time_in_ms	21,402	84,794 (-2%)	344,403 (-2%)
l2_block_rollup_simulation_time_in_ms	16,044	63,542 (-2%)	259,608 (-2%)
l2_block_public_tx_process_time_in_ms	5,330	21,168 (-3%)	84,541 (-2%)

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	16,512 (-1%)	31,943
note_history_successful_decrypting_time_in_ms	1,413	2,797 (+2%)
note_history_trial_decrypting_time_in_ms	188 (+7%)	244 (+7%)
node_database_size_in_bytes	18,645,072	35,758,160
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	335 (-1%)	44,664	27,457
private-kernel-ordering	214 (-1%)	45,777	14,627
base-rollup	1,743 (-1%)	175,344	933
root-rollup	83.5	4,192	825
private-kernel-inner	443 (-1%)	73,099	27,457
public-kernel-app-logic	275 (-1%)	32,254	25,379
merge-rollup	7.86 (+1%)	2,712	933

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	10.3 (-1%)	10.8 (-4%)	18.0 (+14%)	17.3 (-2%)	23.3 (+1%)	65.1 (+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.598 (-1%)	0.601 (-4%)	0.759 (+15%)	0.533 (-2%)	0.486	0.447	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	75.7 (-1%)	48.1	245 (-2%)	470	920	3,603
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.467 (-1%)	0.492	0.446 (-2%)	0.439	0.436	0.432
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	105	58.5 (+1%)	356 (-3%)	698	1,387	5,510
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.497	0.509 (+1%)	0.481 (-3%)	0.478	0.477	0.477
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	N/A	65.2	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	N/A	110	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	N/A	0.562	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,388	36,001

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes
tx_pxe_processing_time_ms	574 (-1%)	1,508 (-1%)

Metric	0 public data writes	1 public data writes
tx_sequencer_processing_time_ms	0.0304 (-1%)	656 (-1%)

[LHerskind]

A few small comments, there are some places where the docs have been updated where they likely should not have been.

[LHerskind]

With these, should be update the imports generally to make it nicer, might be fine to do in a separate pr so it don't bloat in here.

[benesjan]

All the occurrences are addressed now other than the one of Storage which for whatever reason fails to compile when trying to use the re-export. I guess it's caused by it being a trait and not struct.

Are you aware of this issue? If not will ask noir people.

[LHerskind]

Why do you want to compute it like this? 👀 It is public information anyway you could just use the value. I guess it is helping a little to make it behave somewhat similar to public state in the layout and macro, but otherwise not seeing a benefit

[benesjan]

Initially did that to get it to compile with the current macros but agree that it should be addressed in a less stupid way. Did that in 165027d

[benesjan]

Re-worked in 5ed77a4

[LHerskind]

This one should also be privateset I believe? Think there might also be issues with the links?

[benesjan]

Fixed in 8a15dfd and 1f2cf42

[LHerskind]

Not sure why this is "better" or much different from the one before? We will likely have the same issue with the slow updates one that have multiple T stored, so we need to figure out a good way to do it anyway.

[benesjan]

The issue with the previous implementation was that it resulted in storage slots not being assigned as 1, 2, 3, ... in the Storage struct but instead the storage slot values were multiples of 2 (e.g. 2, 4, 6...). This resulted in it being more of a magical code and it diverted from how it's done in Solidity. By adding this separator I think it will be much clearer for people to determine the slots if they have the need to do so.

It also resulted in a smaller diff because I didn't need to update like 5 e2e tests which were working with the slots directly (e.g. by adding pending shields).

[LHerskind]

Not sure I'm following why for this one.

[benesjan]

Documented this in 431a755

Is it clear enough now?

[LHerskind]

Ye more clear. Potentially we should look at doing like the hashing you tried before with a bit of hashing just to cover the case where someone actually use the first couple thousands. But seems like a tiny probability for that.

[benesjan]

@LHerskind we could always just make the constant huge and that way you avoid unnecessary hashing. I will increase it to a billion just to be safe.

[LHerskind]

Ye more clear. Potentially we should look at doing like the hashing you tried before with a bit of hashing just to cover the case where someone actually use the first couple thousands. But seems like a tiny probability for that.