feat: add oracle for slow updates

[LHerskind]

Experimental, very much in progress.

Fixes #2852, building on top of #2732.

For the experimentation here needed a name for my "data-stack" as it could practically hold whatever you want to throw at it. Was listening to https://www.youtube.com/watch?v=DTrNwbemNK0 while building so its the pez dispenser. The PEZ dispenser is essentially a stack managed by the PXE that hold mints (PEZ Dispenser = "PfeffErminZ"/peppermint dispenser). A mint is Fr[] which can hold whatever data really, here just used to feed membership proofs and update proofs into the slow updates map.

Checklist:

Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

• If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
• I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
• Every change is related to the PR description.
• I have linked this pull request to relevant issues (if any exist).

[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 6c20b459 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,444	179,588	716,132
l1_rollup_calldata_gas	222,780	868,088	3,449,396
l1_rollup_execution_gas	841,867	3,595,196	22,204,765
l2_block_processing_time_in_ms	1,961 (-3%)	7,535 (+1%)	29,444
note_successful_decrypting_time_in_ms	296 (-1%)	873 (+2%)	3,182 (+1%)
note_trial_decrypting_time_in_ms	99.0 (-3%)	81.0 (+19%)	134
l2_block_building_time_in_ms	13,110	52,222	208,383
l2_block_rollup_simulation_time_in_ms	11,779	46,911	187,250
l2_block_public_tx_process_time_in_ms	1,290 (+2%)	5,179 (+2%)	20,641 (+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	21,363 (-1%)	42,366
note_history_successful_decrypting_time_in_ms	1,999	4,078 (+4%)
note_history_trial_decrypting_time_in_ms	121 (-1%)	144
node_database_size_in_bytes	1,628,545	1,097,189
pxe_database_size_in_bytes	27,188	54,187

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	72.1	61,697	18,841
private-kernel-ordering	43.4 (-1%)	24,233	8,089
base-rollup	1,773	656,309	811
root-rollup	78.1	4,072	1,097
private-kernel-inner	53.3 (+1%)	81,504	18,841
public-kernel-private-input	41.4	41,455	18,841
public-kernel-non-first-iteration	26.3	41,497	18,841
merge-rollup	0.978 (+11%)	2,592	873

Miscellaneous

Transaction sizes based on how many contracts are deployed in the tx.

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	8,723	27,240

[LHerskind]

Thinking about changing read_at() to include the key, e.g., read_at(key), to make it a little more clear, and then checking that index matches the proof 🤔 mainly for being more easily to follow. Would probably do similar change for the update_at as well.

On this note, reconsidering whether stack is desirable.

Pros:

• Support both read and write for same key in same tx
• Can be used without any inputs, so might fit for other tasks as well

Con:

• A bit more complex/annoying to use.

[Maddiaa0]

*dabs