feat!: compile-time incorrect exec environment errors

[nventuro]

Closes #5886.

This removes the Context struct and makes all state variables generic over a new Context type parameter, with each state variable providing implementations for PrivateContext, PublicContext or () (used to marked unconstarined - more on this later).

The end result is that we get compile-time errors when calling functions that are unavailable in the current context, reduced wrapping and unwrapping, and no obscure explicit trap hit in brilling 'self._is_some' runtime errors, such as in #3123.

How

The implementation is prety much as described in #5886, except instead of using traits we specialize the type directly for the contexts we know.

struct MyStateVar<Context> { context: Context }

impl MyStateVar<&mut PrivateContext> { fn private_read() { } }

This works because there's only a couple of them, and users are not expected to extend them.

The macros were altered so that instead of wrapping the context object in Context and then passing that, we simply pass the raw object to the Storage::init function. This means that Storage itself is now also generic, resulting in some unfortunate new boilerplate in the struct declaration.

All instances of self.context.private.unwrap() and friends were removed: each function is now available under the corresponding impl block that is specialized for the corresponding context. We could even rename some since read_public and read_private is no longer required: both impls can have read functions since they are effectively methods for different types, so the shared name is a non-issue.

Oddities

This change revelead a number of small bugs in the codebase, in the form of uncallable functions. These were undetected since no test called them. I'll do a pass over the entire PR and leave comments where relevant.

Top-level unconstrained

This PR continues the formalization of what I've been calling 'top-level unconstrained' (i.e. an unconstrained contract function) as a fundamental Aztec.nr concept and third execution environment, alongside private and public execution. So far we've been accessing oracles in these unconstrained functions without much care (sometimes for perfomance reasons - see #5911), but the new stricter compile-time checks force us to be a bit more careful.

In my mind, we are arriving at the following model:

• public execution: done by the sequencer, can be simulated locally with old data, not unlike the evm
• private execution: able to produce valid private kernel proofs with side effects collected in the context
• top-level unconstrained execution: local computation using both private and old public data, with certain restrictions from private exec lifted (e.g. unbounded loops), unable to produce any kind of proofs or reason about state changes. only useful for computing values doing arbitrary computation over both private and public state, with zero validation and guarantees of correctness

Private execution requires a context object a it needs to collect side effects, but public notably does not - it simply calls oracles and gets them to do things. In this sense, the PublicContext type is acting as a marker of the current execution environment in order to prevent developers from accidentally doing things that are invalid in public, which would otherwise result in either transpilation error or inability to create public kernel proofs.

This means that we may want a third UnconstrainedContext to act as a similar marker for this third type (where we can e.g. call view_notes, read old public state, etc.). It currently doesn't exist: we simply have Context::none(), and it is defined as the absense of one of the other contexts. Because of this, I chose to temporarily use the unit type (()) to mark this environment.

Note that in some cases the different execution environments share code paths: view_notes is simply get_notes without any constraints, and public storage reads are performed by calling the same oracles in both public and unconstrained. I imagine small differences will arise in the future, specially as work on the AVM continues.

[nventuro]

Marking as a draft since some parts of the docsite likely need updating (e.g. examples), and I haven't thoroughly reviewed that yet.

[nventuro]

This was entirely unnecessary - all these do is call the init function with the correct type. I made init generic and replaced all of the private and public calls with init.

[nventuro]

This is simply a copy of the PublicContext impl. I added a note in #5818 so that we don't forget to remove it once the transition is complete.

[nventuro]

This might seem odd out of context, see my comment here.

[LHerskind]

Something seems wrong with this link for me, if I click, it just refreshes the page, and I don't get to another comment 🤔

[nventuro]

This was wrong: we can't call get_note from unconstrained since it requires a private context to store side-effects in! This function always fails when called, but no test called it so we never noticed this.

The fix is straightforward, though it did force me to implement the Serialize trait for CardNote now that we return it from a private function.

[nventuro]

I updated the docs, including some additional notes on execution modes and the Context parameter.

[nventuro]

This section didn't really seem to add anything here: the concepts are barely mentioned, whereas we have both high and low level explanations in other places. I think we can just remove this part and rely on the other sections to cover this in detail. I added links to help users find those.

[sklppy88]

Really cool work. I love the changes. Having this catch at comp time is great. Contexts being added everywhere is weird but I think the added benefit is worth it. Thanks for the clear comments also.

[nventuro]

Commit 6b4e6da fixed the doc links, and the previous run passed CI, so we're force-merging skipping CI checks to not block other tasks.

[AztecBot]

Docs Preview

Hey there! 👋 You can check your preview at https://664cdbb7ea6b9a1e7ee99580--aztec-docs-dev.netlify.app

[AztecBot]

Benchmark results

No base data found for comparison.

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.

Proof generation

Each column represents the number of threads used in proof generation.

Metric	1 threads	4 threads	16 threads	32 threads	64 threads
proof_construction_time_sha256	5,612	1,547	707	763	767

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	772	772	772
l1_rollup_calldata_gas	6,832	6,844	6,868
l1_rollup_execution_gas	587,372	587,384	587,408
l2_block_processing_time_in_ms	1,356	5,094	10,092
l2_block_building_time_in_ms	33,448	131,669	262,571
l2_block_rollup_simulation_time_in_ms	33,267	131,027	261,300
l2_block_public_tx_process_time_in_ms	20,525	82,617	164,931

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,369	28,512
node_database_size_in_bytes	21,397,584	38,281,296
pxe_database_size_in_bytes	29,868	59,425

Circuits stats

Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit	protocol_circuit_simulation_time_in_ms	protocol_circuit_witness_generation_time_in_ms	protocol_circuit_proving_time_in_ms	protocol_circuit_input_size_in_bytes	protocol_circuit_output_size_in_bytes	protocol_circuit_proof_size_in_bytes	protocol_circuit_num_public_inputs	protocol_circuit_size_in_gates
private-kernel-init	159	3,652	22,895	19,985	61,999	86,720	2,643	1,048,576
private-kernel-inner	608	5,117	40,644	89,053	61,999	86,720	2,643	2,097,152
private-kernel-reset-small	576	2,400	23,183	117,961	61,999	86,720	2,643	1,048,576
private-kernel-tail	531	3,929	37,802	86,849	79,454	10,688	267	2,097,152
base-parity	7.58	1,786	3,543	128	64.0	2,208	2.00	131,072
root-parity	49.8	125	39,919	27,064	64.0	2,720	18.0	2,097,152
base-rollup	801	2,763	43,485	111,158	957	3,136	31.0	2,097,152
root-rollup	93.8	111	8,352	11,518	821	3,456	41.0	524,288
public-kernel-app-logic	245	1,960	756	96,978	85,095	116,448	3,572	4,096
public-kernel-tail	874	810	1,106	388,207	7,755	10,176	251	512
public-kernel-setup	230	274	907	138,309	85,095	116,448	3,572	4,096
public-kernel-teardown	234	323	943	143,320	85,095	116,448	3,572	4,096
merge-rollup	6.55	91.8	1,624	2,760	957	3,136	31.0	65,536
private-kernel-tail-to-public	N/A	9,539	73,158	N/A	N/A	116,960	3,588	4,194,304

Stats on running time collected for app circuits

Function	app_circuit_proof_size_in_bytes	app_circuit_proving_time_in_ms	app_circuit_size_in_gates	app_circuit_num_public_inputs
SchnorrAccount:entrypoint	16,128	47,683	2,097,152	437
Test:emit_nullifier	16,128	1,823	65,536	437
FPC:fee_entrypoint_public	16,128	9,401	524,288	437
FPC:fee_entrypoint_private	16,128	8,948	524,288	437
Token:unshield	16,128	50,262	2,097,152	437
SchnorrAccount:spend_private_authwit	16,128	2,694	131,072	437
Token:transfer	16,128	35,030	2,097,152	437

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	11.3	19.4	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.7	31.8	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.660	0.595	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	52.3	81.2	263	505	993	1,958	N/A
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	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.535	0.500	0.478	0.472	0.470	0.469	N/A
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	62.7	120	378	744	1,478	2,935	N/A
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	106	208	692	1,363	2,707	5,395	N/A
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.545	0.537	0.512	0.510	0.511	0.511	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	67.9
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	108
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.594

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	84,741	673,219

Transaction size based on fee payment method

| Metric | |
| - | |

Transaction processing duration by data writes.

Metric	0 new note hashes	1 new note hashes	2 new note hashes
tx_pxe_processing_time_ms	29,890	4,277	100,777

Metric	0 public data writes	1 public data writes	2 public data writes	4 public data writes	8 public data writes
tx_sequencer_processing_time_ms	1,408	2,665	2,065	3,378	2,005