-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: introduce UnconstrainedContext #6752
Conversation
Docs PreviewHey there! 👋 You can check your preview at https://665df39c24f4511bafadfbf3--aztec-docs-dev.netlify.app |
Benchmark resultsNo metrics with a significant change found. Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Proof generationEach column represents the number of threads used in proof generation.
L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.
Stats on running time collected for app circuits
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method | Metric | | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
Continuing the work from #6442, this PR further formalizes the notion of a top-level unconstrained execution context by introducing a struct that represents it (instead of relying on the unit type). Not only is this less cryptic, it also provides access to data previously unavailable such as the current block number and contract address, which we'll need for some unconstrained getters like `SharedMutable`'s. The macro functions could potentially be refactored somewhat now that private, public and unconstrained are more similar, but I'm not sure we want to invest much effort there so I made the change as small as possible.
Continuing the work from #6442, this PR further formalizes the notion of a top-level unconstrained execution context by introducing a struct that represents it (instead of relying on the unit type). Not only is this less cryptic, it also provides access to data previously unavailable such as the current block number and contract address, which we'll need for some unconstrained getters like `SharedMutable`'s. The macro functions could potentially be refactored somewhat now that private, public and unconstrained are more similar, but I'm not sure we want to invest much effort there so I made the change as small as possible.
Continuing the work from #6442, this PR further formalizes the notion of a top-level unconstrained execution context by introducing a struct that represents it (instead of relying on the unit type). Not only is this less cryptic, it also provides access to data previously unavailable such as the current block number and contract address, which we'll need for some unconstrained getters like
SharedMutable
's.The macro functions could potentially be refactored somewhat now that private, public and unconstrained are more similar, but I'm not sure we want to invest much effort there so I made the change as small as possible.