forked from AztecProtocol/aztec-packages
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat!: compile-time incorrect exec environment errors (AztecProtocol#…
…6442) Closes AztecProtocol#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 AztecProtocol#3123. ## How The implementation is prety much as described in AztecProtocol#5886, except instead of using traits we specialize the type directly for the contexts we know. ```rust 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 AztecProtocol#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. --------- Co-authored-by: esau <152162806+sklppy88@users.noreply.github.com> Co-authored-by: thunkar <gregojquiros@gmail.com>
- Loading branch information
1 parent
ea36bf9
commit 0f75efd
Showing
48 changed files
with
563 additions
and
406 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.