-
Notifications
You must be signed in to change notification settings - Fork 295
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(Simulate): Allow calling view
on constrained functions
#2665
Comments
There are some moving parts for this:
|
weird question but what is the difference between |
@spalladino why would you need to duplicate code? A constrained method can call an unconstrained currently (like a normal fn call) right? |
The way I see it, it's because you want a constrain on the returned results, which you don't get when calling an unconstrained function. So if you have an app contract that, as part of a tx, calls an unconstrained getter in another contract, the sender can craft a proof where that getter returns pretty much anything. |
This is indeed being quite confusing to me as a new user - I expected to be able to call Instead I can apparently only call |
view
on constrained functionsview
on constrained functions
view
on constrained functionsview
on constrained functions
# Goal This PR aims to expose arbitrary types and values resulting from contract compilation in the resulting JSON artifact, in a way that is not tied to aztec-specific features or even smart contracts at all. # Problem Up until now, Noir compiled crates that used the `contract` keyword with a specific flow, which also added additional structs and metadata to the output such as whatever structs were marked with the `#[event]` attribute. This coupled Noir to smart contract specific constructs, which were propagated through the compiler (from the parser to the actual compilation output). For #5079 and several other tasks that aim to reduce the mental load and improve the general devex of our users, we ***need*** to expose several other structs that are even more specific to aztec, which would only compromise the generality of the compiler further. # Proposed solution The introduction of a new attribute `#[abi(tag)]` that can be applied to both `structs` and `global` top-level statements, and export types (with the current `ABIType` format) and values (with the new `ABIValue` format) in a way that can be interpreted by components further downstream (for example, our typescript codegen). This way, the noir compiler doesn't know (or care) about whatever gets included in the artifact. The `events` contract artifact key gets replaced by: ```typescript outputs: { structs: Record<string, ABIType[]>; globals: Record<string, ABIValue[]>; }; ``` # What this approach allows - Removing the smart contract specific attribute `#[event]`, replacing it by a more general `#[abi(events)]`. - Substantial devex improvements, such as exposing storage layout, note ids: ![image](https://github.com/AztecProtocol/aztec-packages/assets/5404052/dba1d6ca-1286-4d4d-912e-f222d3414f32) ...or even private function return values prior to macro processing for decoding `.view` calls #2665 --------- Co-authored-by: esau <[email protected]> Co-authored-by: Tom French <[email protected]>
# Goal This PR aims to expose arbitrary types and values resulting from contract compilation in the resulting JSON artifact, in a way that is not tied to aztec-specific features or even smart contracts at all. # Problem Up until now, Noir compiled crates that used the `contract` keyword with a specific flow, which also added additional structs and metadata to the output such as whatever structs were marked with the `#[event]` attribute. This coupled Noir to smart contract specific constructs, which were propagated through the compiler (from the parser to the actual compilation output). For AztecProtocol/aztec-packages#5079 and several other tasks that aim to reduce the mental load and improve the general devex of our users, we ***need*** to expose several other structs that are even more specific to aztec, which would only compromise the generality of the compiler further. # Proposed solution The introduction of a new attribute `#[abi(tag)]` that can be applied to both `structs` and `global` top-level statements, and export types (with the current `ABIType` format) and values (with the new `ABIValue` format) in a way that can be interpreted by components further downstream (for example, our typescript codegen). This way, the noir compiler doesn't know (or care) about whatever gets included in the artifact. The `events` contract artifact key gets replaced by: ```typescript outputs: { structs: Record<string, ABIType[]>; globals: Record<string, ABIValue[]>; }; ``` # What this approach allows - Removing the smart contract specific attribute `#[event]`, replacing it by a more general `#[abi(events)]`. - Substantial devex improvements, such as exposing storage layout, note ids: ![image](https://github.com/AztecProtocol/aztec-packages/assets/5404052/dba1d6ca-1286-4d4d-912e-f222d3414f32) ...or even private function return values prior to macro processing for decoding `.view` calls AztecProtocol/aztec-packages#2665 --------- Co-authored-by: esau <[email protected]> Co-authored-by: Tom French <[email protected]>
With #5762 we can now use `simulate()` to directly get values out of contract calls (i.e. #2665). This PR refactors some e2e tests that relied on events to get values out and replaces those with proper `simulate()` calls. Co-authored-by: ludamad <[email protected]>
Because why not?
This lets an app developer expose a constrained private getter that can be used both for querying state from other contracts and for querying from off-chain by the app, rather than requiring two versions of the same function.
However, implementing this is not as easy as removing the client check. If the function called modifies state, we need to do so in a transient copy of the state, so we can discard it as soon as the call finishes.
The text was updated successfully, but these errors were encountered: