feat!: Updates singleton usage

[LHerskind]

Fixes #4174 by making the singletons leaky.

• Updates the docs
• Adds more tests to the singleton e2e.

[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 6dac6504 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,632	866,452	3,448,144
l1_rollup_execution_gas	314,051	984,124	3,667,733
l2_block_processing_time_in_ms	1,421 (+2%)	5,289 (-2%)	20,952 (+1%)
note_successful_decrypting_time_in_ms	298 (+3%)	876 (-1%)	3,157 (-2%)
note_trial_decrypting_time_in_ms	107 (+7%)	153 (+37%)	150 (+1%)
l2_block_building_time_in_ms	16,126	63,867	256,349
l2_block_rollup_simulation_time_in_ms	11,745 (-1%)	46,490 (-1%)	187,106
l2_block_public_tx_process_time_in_ms	4,343	17,291	68,912

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,958 (-7%)	30,809 (-1%)
note_history_successful_decrypting_time_in_ms	1,979 (-2%)	3,914 (+1%)
note_history_trial_decrypting_time_in_ms	147 (-14%)	376 (+61%)
node_database_size_in_bytes	3,520,094	3,557,950
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	213 (-1%)	44,681	25,561
private-kernel-ordering	166	43,753	14,809
base-rollup	1,200	128,338	881
root-rollup	79.9 (+1%)	4,088	677
private-kernel-inner	292	71,208	25,561
public-kernel-private-input	206	31,863	25,561
public-kernel-non-first-iteration	203	31,905	25,561
merge-rollup	7.63	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.1 (-1%)	19.1 (-6%)	15.0 (+11%)	19.7	25.2	67.0 (+2%)	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.622	0.635 (-8%)	0.608 (+11%)	0.546 (-1%)	0.482 (-1%)	0.444 (+1%)	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	83.1 (-4%)	51.9 (+1%)	248 (-2%)	480 (-1%)	916 (-1%)	3,576
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.477 (-2%)	0.499	0.438 (-2%)	0.437 (-1%)	0.430	0.427
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	N/A	N/A	N/A	118 (-1%)	62.6 (+1%)	381 (+2%)	770 (-4%)	1,449 (-2%)	5,656 (+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.505 (-1%)	0.505	0.485	0.484 (-4%)	0.478 (-1%)	0.473
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	N/A	67.9	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.596 (-1%)	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,222

Transaction processing duration by data writes.

Metric	0 new commitments	1 new commitments
tx_pxe_processing_time_ms	376 (+1%)	1,086

Metric	1 public data writes
tx_sequencer_processing_time_ms	536

[iAmMichaelConnor]

Consider reverting back to naming Singleton and ImmutableSingleton (removing Leaky) and instead naming the leaky methods. Namely compute_leaky_initialization_nullifier() and leaky_initialization_nullifier.

[benesjan]

Looks good to me but please explain why it's called leaky.

[benesjan]

Suggested change

A `LeakySingleton` may point to _one_ note at a time. ("One", hence "Singleton"). But since it's not "immutable", the note that it points to may be [replaced](#replace) by functions of the contract, over time. The "current value" of a `LEakySingleton` is interpreted as the one note which has not-yet been nullified. The act of 'replacing' a LeakySingleton's note is how a `LeakySingleton` state may be modified by functions.

A `LeakySingleton` may point to _one_ note at a time. ("One", hence "Singleton"). But since it's not "immutable", the note that it points to may be [replaced](#replace) by functions of the contract, over time. The "current value" of a `LeakySingleton` is interpreted as the one note which has not-yet been nullified. The act of 'replacing' a LeakySingleton's note is how a `LeakySingleton` state may be modified by functions.

[benesjan]

Suggested change

	As part of the initialization of the `LeakyStorage` struct, the `LeakySingleton` is created as follows, here at the specified storage slot and with the `NoteInterface` for `CardNote`.
	As part of the initialization of the `Storage` struct, the `LeakySingleton` is created as follows, here at the specified storage slot and with the `NoteInterface` for `CardNote`.

[iAmMichaelConnor]

Suggested change

	// The following computation is leaky - the storage slot can easily be "guessed" by an adversary
	// by looking at the nullifier in the transaction data.
	// This is especially dangerous for `maps` because the storage slot is often also identifies the
	// actor that is executing the transaction. e.g, `map.at(msg.sender)` will leak `msg.sender`.
	// The following computation is leaky, in that it doesn't hide the storage slot that has been initialized, nor does it hide the contract address of this contract. When this initialization nullifier is emitted, an observer could do a dictionary or rainbow attack to learn the preimage of this nullifier to deduce the storage slot and contract address.
	// For some applications, leaking the details that a particular state variable of a particular contract has been initialized will be unacceptable, and so under such circumstances, such application developers might wish to _not_ use this state variable type.
	// This is especially dangerous for initial assignment to elements of a `Map<AztecAddress, ImmutableSingleton>` type (for example), because the storage slot often also identifies the
	// actor that is executing the transaction. e.g. the initial assignment to `my_map.at(msg.sender)` will leak: `msg.sender`, the fact that an element of `my_map` was assigned-to for the first time, and the contract_address.

[iAmMichaelConnor]

As above, but also add a note like:

Note: subsequent nullification of this state variable, via the `replace` method will not be leaky, if the `compute_nullifier()` method of the underlying note is designed to ensure privacy. For example, if the `compute_nullifier()` method injects the secret key of a note owner into the computed nullifier's preimage.