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 | | |
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.