Skip to content
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.

Sign up for GitHub

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

Jump to bottom

feat(AztecMacro): Extend artifact with storage layout #5079

Closed
Tracked by #5077
LHerskind opened this issue Mar 8, 2024 · 1 comment · Fixed by #5387
Closed
Tracked by #5077

feat(AztecMacro): Extend artifact with storage layout #5079

LHerskind opened this issue Mar 8, 2024 · 1 comment · Fixed by #5387
Assignees
@Thunkar

Comments

@LHerskind
Copy link
Contributor

LHerskind commented Mar 8, 2024 •
edited
Loading

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.
@LHerskind LHerskind mentioned this issue Mar 8, 2024
Open
@LHerskind
Copy link
Contributor Author

Original issue from #4518 by @nventuro.

#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 8, 2024
Closed
Open
Open
@Thunkar Thunkar self-assigned this Mar 15, 2024
@nventuro nventuro mentioned this issue Mar 18, 2024
Open
This was referenced Mar 26, 2024
Merged
Merged
Thunkar added a commit that referenced this issue Apr 4, 2024
@Thunkar @sklppy88 @TomAFrench
feat!: contract_abi-exports (#5386)
745d522 
# 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]>
AztecBot added a commit to noir-lang/noir that referenced this issue Apr 4, 2024
@AztecBot @sklppy88 @TomAFrench
feat!: contract_abi-exports (AztecProtocol/aztec-packages#5386)
0322464 
# 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]>
Thunkar added a commit that referenced this issue Apr 8, 2024
@Thunkar @sklppy88
feat!: storage_layout and #[aztec(storage)] (#5387)
2c1d795 
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
@AztecBot @sklppy88
feat!: storage_layout and #[aztec(storage)] (AztecProtocol/aztec-pa…
09df836 
…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
@AztecBot @sklppy88
feat!: storage_layout and #[aztec(storage)] (AztecProtocol/aztec-pa…
2857ef9 
…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
@Thunkar @sklppy88 @AztecBot
feat!: storage_layout and #[aztec(storage)] (#5387)
0baacb8 
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
@superstar0402 @sklppy88
feat!: storage_layout and #[aztec(storage)] (#5387)
469f0c7 
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
Assignees

@Thunkar Thunkar

Labels
None yet
Projects
A3
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat!: storage_layout and #[aztec(storage)] AztecProtocol/aztec-packages
2 participants
@Thunkar @LHerskind