feat(AztecMacro): Extend artifact with storage layout #5079
Assignees
Comments
Open
|
#4200 added automatic storage slot allocation, #4500 introduced note type ids (soon to be autogenerated). These values are not currently available outside of the contract, but there's multiple applications that might require them. This is not unique to Aztec: as an example, Solidity exposes the storage layout to ease smart contract upgrades. In our case, both of these values are required when manually adding notes to PXE, since these values are neede to call compute_note_hash_and_nullifier. Our guides (and tests) are currently forced to include these magic values, and this is only going to get worse once note type ids are autogenerated and become more obscure. Since we typically care about note type ids in the context of the underlying note that corresponds to each state variable, a reasonable way to do it might be to expose the different state variable along with their storage slot and note type id. I don't think we'll care very much about which id corresponds to which note type, only the state variables. |
This was referenced Mar 26, 2024
Thunkar
added a commit
that referenced
this issue
Apr 4, 2024
# 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:  ...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]>
AztecBot
added a commit
to noir-lang/noir
that referenced
this issue
Apr 4, 2024
# 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:  ...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]>
Thunkar
added a commit
that referenced
this issue
Apr 8, 2024
Requires #5386 Closes #5079 Leveraging the new `#[abi(tag)]` export attribute, the `#[aztec(storage]` and `#[aztec(note)]` decorators are now used by the aztec macros to generate exportable global structs that include storage and notes info. These are then interpreted by `noir-compiler` in the ts codegen and exposed through the contract classes. ```typescript MyContractClass.storage.my_storage_variable.slot: Fr; MyContractClass.notes.MyNote.id: Fr; ``` In the process I realized we didn't really need the `process_def_collector` pass, which has been removed (one less thing to worry about before moving to metaprogramming!) in favor of using `#[aztec(note)]` to identify notes that need to get included in the autogenerated `compute_note_hash_and_nullifier` implementation. --------- Co-authored-by: esau <[email protected]>
AztecBot
added a commit
to noir-lang/noir
that referenced
this issue
Apr 8, 2024
…ckages#5387) Requires AztecProtocol/aztec-packages#5386 Closes AztecProtocol/aztec-packages#5079 Leveraging the new `#[abi(tag)]` export attribute, the `#[aztec(storage]` and `#[aztec(note)]` decorators are now used by the aztec macros to generate exportable global structs that include storage and notes info. These are then interpreted by `noir-compiler` in the ts codegen and exposed through the contract classes. ```typescript MyContractClass.storage.my_storage_variable.slot: Fr; MyContractClass.notes.MyNote.id: Fr; ``` In the process I realized we didn't really need the `process_def_collector` pass, which has been removed (one less thing to worry about before moving to metaprogramming!) in favor of using `#[aztec(note)]` to identify notes that need to get included in the autogenerated `compute_note_hash_and_nullifier` implementation. --------- Co-authored-by: esau <[email protected]>
AztecBot
added a commit
to noir-lang/noir
that referenced
this issue
Apr 8, 2024
…ckages#5387) Requires AztecProtocol/aztec-packages#5386 Closes AztecProtocol/aztec-packages#5079 Leveraging the new `#[abi(tag)]` export attribute, the `#[aztec(storage]` and `#[aztec(note)]` decorators are now used by the aztec macros to generate exportable global structs that include storage and notes info. These are then interpreted by `noir-compiler` in the ts codegen and exposed through the contract classes. ```typescript MyContractClass.storage.my_storage_variable.slot: Fr; MyContractClass.notes.MyNote.id: Fr; ``` In the process I realized we didn't really need the `process_def_collector` pass, which has been removed (one less thing to worry about before moving to metaprogramming!) in favor of using `#[aztec(note)]` to identify notes that need to get included in the autogenerated `compute_note_hash_and_nullifier` implementation. --------- Co-authored-by: esau <[email protected]>
AztecBot
pushed a commit
to AztecProtocol/aztec-nr
that referenced
this issue
Apr 9, 2024
Requires AztecProtocol/aztec-packages#5386 Closes AztecProtocol/aztec-packages#5079 Leveraging the new `#[abi(tag)]` export attribute, the `#[aztec(storage]` and `#[aztec(note)]` decorators are now used by the aztec macros to generate exportable global structs that include storage and notes info. These are then interpreted by `noir-compiler` in the ts codegen and exposed through the contract classes. ```typescript MyContractClass.storage.my_storage_variable.slot: Fr; MyContractClass.notes.MyNote.id: Fr; ``` In the process I realized we didn't really need the `process_def_collector` pass, which has been removed (one less thing to worry about before moving to metaprogramming!) in favor of using `#[aztec(note)]` to identify notes that need to get included in the autogenerated `compute_note_hash_and_nullifier` implementation. --------- Co-authored-by: esau <[email protected]>
superstar0402
added a commit
to superstar0402/aztec-nr
that referenced
this issue
Aug 16, 2024
Requires AztecProtocol/aztec-packages#5386 Closes AztecProtocol/aztec-packages#5079 Leveraging the new `#[abi(tag)]` export attribute, the `#[aztec(storage]` and `#[aztec(note)]` decorators are now used by the aztec macros to generate exportable global structs that include storage and notes info. These are then interpreted by `noir-compiler` in the ts codegen and exposed through the contract classes. ```typescript MyContractClass.storage.my_storage_variable.slot: Fr; MyContractClass.notes.MyNote.id: Fr; ``` In the process I realized we didn't really need the `process_def_collector` pass, which has been removed (one less thing to worry about before moving to metaprogramming!) in favor of using `#[aztec(note)]` to identify notes that need to get included in the autogenerated `compute_note_hash_and_nullifier` implementation. --------- Co-authored-by: esau <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should export the storage layout to the artifacts to allow easier reading of notes from outside contracts.
Currently, adding a note can be quite cumbersome as the storage slot and type id is required. Simultaneously, it can be fairly cumbersome to read from storage unless unconstrained/query (#5057) functions have been provided, but if we have a storage layout defined, it should be possible to more easily read and understand the raw storage without having to go through any simulators.
The text was updated successfully, but these errors were encountered: