feat(AztecMacro): Autogenerate Note Type IDs #4519
Assignees
Comments
Merged
LHerskind
changed the title
Thunkar
added a commit
that referenced
this issue
Mar 19, 2024
Partially addresses: #4519 (moved autogeneration to the macro, even if not incremental) Closes: #3011 Added the `#[aztec(note)]` attribute, which automatically implements most of the `NoteInterface` trait in a struct marked as such, plus several utilities. Even if this adds a fair share of "magic" to the note implementation logic, it is structured in a way that it's hopefully easy to follow, including meaningful errors attached to the correct span during the process.  Hey you! Implement the trait!  But only the meat and potatoes though. As long as the user doesn't want to do any custom stuff, `get_header`, `set_header`, `compute_note_content_hash`, `get_note_type_id`, `serialize_content` and `deserialize_content` get automatically implemented. Any combination of them can be overridden by the developer though. A metadata struct is also added, which takes the following form: ```rust struct CardNote { points: FieldSelector, randomness: FieldSelector, owner: FieldSelector, } ``` This is used to implement a `properties()` function, which in turn can be used in conjunction with the `NoteGetterOptions.select` and `.sort` <img width="697" alt="Screenshot 2024-03-18 at 15 27 27" src="https://github.com/AztecProtocol/aztec-packages/assets/5404052/5da531b3-0b7f-4cf9-9908-300ff8d98c6d">
AztecBot
added a commit
to noir-lang/noir
that referenced
this issue
Mar 19, 2024
…ecProtocol/aztec-packages#4508) Partially addresses: AztecProtocol/aztec-packages#4519 (moved autogeneration to the macro, even if not incremental) Closes: AztecProtocol/aztec-packages#3011 Added the `#[aztec(note)]` attribute, which automatically implements most of the `NoteInterface` trait in a struct marked as such, plus several utilities. Even if this adds a fair share of "magic" to the note implementation logic, it is structured in a way that it's hopefully easy to follow, including meaningful errors attached to the correct span during the process.  Hey you! Implement the trait!  But only the meat and potatoes though. As long as the user doesn't want to do any custom stuff, `get_header`, `set_header`, `compute_note_content_hash`, `get_note_type_id`, `serialize_content` and `deserialize_content` get automatically implemented. Any combination of them can be overridden by the developer though. A metadata struct is also added, which takes the following form: ```rust struct CardNote { points: FieldSelector, randomness: FieldSelector, owner: FieldSelector, } ``` This is used to implement a `properties()` function, which in turn can be used in conjunction with the `NoteGetterOptions.select` and `.sort` <img width="697" alt="Screenshot 2024-03-18 at 15 27 27" src="https://github.com/AztecProtocol/aztec-packages/assets/5404052/5da531b3-0b7f-4cf9-9908-300ff8d98c6d">
AztecBot
pushed a commit
to AztecProtocol/aztec-nr
that referenced
this issue
Mar 20, 2024
Partially addresses: AztecProtocol/aztec-packages#4519 (moved autogeneration to the macro, even if not incremental) Closes: AztecProtocol/aztec-packages#3011 Added the `#[aztec(note)]` attribute, which automatically implements most of the `NoteInterface` trait in a struct marked as such, plus several utilities. Even if this adds a fair share of "magic" to the note implementation logic, it is structured in a way that it's hopefully easy to follow, including meaningful errors attached to the correct span during the process.  Hey you! Implement the trait!  But only the meat and potatoes though. As long as the user doesn't want to do any custom stuff, `get_header`, `set_header`, `compute_note_content_hash`, `get_note_type_id`, `serialize_content` and `deserialize_content` get automatically implemented. Any combination of them can be overridden by the developer though. A metadata struct is also added, which takes the following form: ```rust struct CardNote { points: FieldSelector, randomness: FieldSelector, owner: FieldSelector, } ``` This is used to implement a `properties()` function, which in turn can be used in conjunction with the `NoteGetterOptions.select` and `.sort` <img width="697" alt="Screenshot 2024-03-18 at 15 27 27" src="https://github.com/AztecProtocol/aztec-packages/assets/5404052/5da531b3-0b7f-4cf9-9908-300ff8d98c6d">
|
See #5427 as the successor of this issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#4500 introduced Note Type IDs, but they are currently being manually generated. If we instead used macros to autogenerate them, not only would we improve developer experience but we could also reduce the size of this value (very relevant, since it will be published to the Data Availability layer). We expect to easily go down to a single byte at the most.
The idea here is to enumerate all implementations of
NoteInterfacefor a given contract, and then fill in theget_note_type_id()function with a running counter (so the first note type gets assigned id 1, the second one id 2, etc.). The number of different note types will roughly correspond with the number of state variables, which is expected to be relatively small (<50 in the extreme majority of cases).This is not currently doable since the macro hooks currently available are either called before imports are collected (and hence we cannot edit those), or after they have been checked for correctness (which fails because the
implis incomplete). @vezenovm is working on a related feature which lays some of the foundation for what we need here. This is related to thederivemacro feature, which we already want to automatically serialize and deserialize notes.Note that unless #4518 is first resolved, autogenerating these will result in having to produce magic values in tests and guides, as seen here.
The text was updated successfully, but these errors were encountered: