Abstract away storage slots? #3198
Assignees
Labels
C-aztec.nr
Component: Aztec smart contract framework
S-needs-discussion
Status: Still needs more discussion before work can start.
T-feedback
Type: recording user feedback
Comments
rahul-kothari
added
S-needs-discussion
Thunkar
added a commit
that referenced
this issue
Feb 2, 2024
Closes: #3198, #2928 ~~Requires #4135, which is blocked by noir-lang/noir#4124 Automatic storage initialization via aztec macro. Full support of public and private state from `dep::aztec::state_vars::*`, including Maps (and nested Maps!) Limited support for custom types (as long as they have a single serializable generic and their constructor is `::new(context, storage_slot`). ~~Pending: better errors, code comments and some cleanup.~~ Hijacking my own [comment](#4200 (comment)) for the explanation: The idea behind this is that in 99% of cases, storage initialization (that is, the `impl` for a given `struct Storage...` is redundant, and the only need for its existence was assigning storage slots...which in turn were necessary because we didn't know how to serialize the data structures that were used in a given contract or how much space they used once serialized (relevant for the public state). After #4135 is merged, both of those things don't have to be explicitly provided since we're using traits, so the aztec macro can infer the implementation of the Storage struct just by taking hints from the definition. An example: ```rust struct Storage { // MyAwesomeStuff implements Serialize<2>, so we assign it slot 1 (and remember that it will take 2 slots due to its size) public_var: PublicState<MyAwesomeSuff>, // Right after the first one, assign it to slot: current_slot + previous_size = 3 another_public_var: PublicState<MyAwesomeSuff>, // Private and Public state don't share slots since they "live" in different trees, but keeping the slot count simplifies implementation. // Notes also implement Serialize<N>, but they only take up 1 slot anyways because of hashing, assign it slot 5 a_singleton: Singleton<ANote>, // Maps derive slots via hashing, so we can assume they only "take" 1 slot. We assign it slot 6 balances: Map<AztecAddress, Singleton<ANote>>, // Slot 7 a_set: Set<ANote>, // Slot 8 imm_singleton: ImmutableSingleton<ANote>, // Slot 9. profiles: Map<AztecAddress, Map<Singleton<ANote>>>, } ``` We have all the info we need in the AST and HIR to build this automatically: ```rust impl Storage { fn init(context: Context) -> Self { Storage { public_var: PublicState::new(context, 1), // No need for serialization methods, taken from the the trait impl another_public_var: PublicState::new(context, 3), a_singleton: Singleton::new(context, 5), // Map init lambda always takes the same form for known storage structs balances: Map::new(context, 6, |context, slot| { Singleton::new(context, slot) }), a_set: Set::new(context, 7), imm_singleton: ImmutableSingleton::new(context, 8), // A map of maps is just nesting lambdas, we can infer this too profiles: Map::new(context, 9, |context, slot| { Map::new(context, slot, |context, slot| { Singleton::new(context, slot) }) }) } } } ``` ...as long as we use "canonical" storage implementations. This means `AStoragePrimitive<SomethingSerializable>` and `Map<SomethingWithToField, AStoragePrimitive<SomethingSerializable>>`. **TLDR:** define the Storage struct, in 99% of cases the macro takes care of the implementation! Implementing custom storage will look just like it does know, the macro will skip automatic generation if it finds one. --------- Co-authored-by: sirasistant <sirasistant@gmail.com>
AztecBot
pushed a commit
to AztecProtocol/aztec-nr
that referenced
this issue
Feb 3, 2024
Closes: AztecProtocol/aztec-packages#3198, AztecProtocol/aztec-packages#2928 ~~Requires AztecProtocol/aztec-packages#4135, which is blocked by noir-lang/noir#4124 Automatic storage initialization via aztec macro. Full support of public and private state from `dep::aztec::state_vars::*`, including Maps (and nested Maps!) Limited support for custom types (as long as they have a single serializable generic and their constructor is `::new(context, storage_slot`). ~~Pending: better errors, code comments and some cleanup.~~ Hijacking my own [comment](AztecProtocol/aztec-packages#4200 (comment)) for the explanation: The idea behind this is that in 99% of cases, storage initialization (that is, the `impl` for a given `struct Storage...` is redundant, and the only need for its existence was assigning storage slots...which in turn were necessary because we didn't know how to serialize the data structures that were used in a given contract or how much space they used once serialized (relevant for the public state). After AztecProtocol/aztec-packages#4135 is merged, both of those things don't have to be explicitly provided since we're using traits, so the aztec macro can infer the implementation of the Storage struct just by taking hints from the definition. An example: ```rust struct Storage { // MyAwesomeStuff implements Serialize<2>, so we assign it slot 1 (and remember that it will take 2 slots due to its size) public_var: PublicState<MyAwesomeSuff>, // Right after the first one, assign it to slot: current_slot + previous_size = 3 another_public_var: PublicState<MyAwesomeSuff>, // Private and Public state don't share slots since they "live" in different trees, but keeping the slot count simplifies implementation. // Notes also implement Serialize<N>, but they only take up 1 slot anyways because of hashing, assign it slot 5 a_singleton: Singleton<ANote>, // Maps derive slots via hashing, so we can assume they only "take" 1 slot. We assign it slot 6 balances: Map<AztecAddress, Singleton<ANote>>, // Slot 7 a_set: Set<ANote>, // Slot 8 imm_singleton: ImmutableSingleton<ANote>, // Slot 9. profiles: Map<AztecAddress, Map<Singleton<ANote>>>, } ``` We have all the info we need in the AST and HIR to build this automatically: ```rust impl Storage { fn init(context: Context) -> Self { Storage { public_var: PublicState::new(context, 1), // No need for serialization methods, taken from the the trait impl another_public_var: PublicState::new(context, 3), a_singleton: Singleton::new(context, 5), // Map init lambda always takes the same form for known storage structs balances: Map::new(context, 6, |context, slot| { Singleton::new(context, slot) }), a_set: Set::new(context, 7), imm_singleton: ImmutableSingleton::new(context, 8), // A map of maps is just nesting lambdas, we can infer this too profiles: Map::new(context, 9, |context, slot| { Map::new(context, slot, |context, slot| { Singleton::new(context, slot) }) }) } } } ``` ...as long as we use "canonical" storage implementations. This means `AStoragePrimitive<SomethingSerializable>` and `Map<SomethingWithToField, AStoragePrimitive<SomethingSerializable>>`. **TLDR:** define the Storage struct, in 99% of cases the macro takes care of the implementation! Implementing custom storage will look just like it does know, the macro will skip automatic generation if it finds one. --------- Co-authored-by: sirasistant <sirasistant@gmail.com>
TomAFrench
pushed a commit
that referenced
this issue
Feb 7, 2024
Closes: #3198, #2928 ~~Requires #4135, which is blocked by noir-lang/noir#4124 Automatic storage initialization via aztec macro. Full support of public and private state from `dep::aztec::state_vars::*`, including Maps (and nested Maps!) Limited support for custom types (as long as they have a single serializable generic and their constructor is `::new(context, storage_slot`). ~~Pending: better errors, code comments and some cleanup.~~ Hijacking my own [comment](#4200 (comment)) for the explanation: The idea behind this is that in 99% of cases, storage initialization (that is, the `impl` for a given `struct Storage...` is redundant, and the only need for its existence was assigning storage slots...which in turn were necessary because we didn't know how to serialize the data structures that were used in a given contract or how much space they used once serialized (relevant for the public state). After #4135 is merged, both of those things don't have to be explicitly provided since we're using traits, so the aztec macro can infer the implementation of the Storage struct just by taking hints from the definition. An example: ```rust struct Storage { // MyAwesomeStuff implements Serialize<2>, so we assign it slot 1 (and remember that it will take 2 slots due to its size) public_var: PublicState<MyAwesomeSuff>, // Right after the first one, assign it to slot: current_slot + previous_size = 3 another_public_var: PublicState<MyAwesomeSuff>, // Private and Public state don't share slots since they "live" in different trees, but keeping the slot count simplifies implementation. // Notes also implement Serialize<N>, but they only take up 1 slot anyways because of hashing, assign it slot 5 a_singleton: Singleton<ANote>, // Maps derive slots via hashing, so we can assume they only "take" 1 slot. We assign it slot 6 balances: Map<AztecAddress, Singleton<ANote>>, // Slot 7 a_set: Set<ANote>, // Slot 8 imm_singleton: ImmutableSingleton<ANote>, // Slot 9. profiles: Map<AztecAddress, Map<Singleton<ANote>>>, } ``` We have all the info we need in the AST and HIR to build this automatically: ```rust impl Storage { fn init(context: Context) -> Self { Storage { public_var: PublicState::new(context, 1), // No need for serialization methods, taken from the the trait impl another_public_var: PublicState::new(context, 3), a_singleton: Singleton::new(context, 5), // Map init lambda always takes the same form for known storage structs balances: Map::new(context, 6, |context, slot| { Singleton::new(context, slot) }), a_set: Set::new(context, 7), imm_singleton: ImmutableSingleton::new(context, 8), // A map of maps is just nesting lambdas, we can infer this too profiles: Map::new(context, 9, |context, slot| { Map::new(context, slot, |context, slot| { Singleton::new(context, slot) }) }) } } } ``` ...as long as we use "canonical" storage implementations. This means `AStoragePrimitive<SomethingSerializable>` and `Map<SomethingWithToField, AStoragePrimitive<SomethingSerializable>>`. **TLDR:** define the Storage struct, in 99% of cases the macro takes care of the implementation! Implementing custom storage will look just like it does know, the macro will skip automatic generation if it finds one. --------- Co-authored-by: sirasistant <sirasistant@gmail.com>
michaelelliot
pushed a commit
to Swoir/noir_rs
that referenced
this issue
Feb 28, 2024
Closes: AztecProtocol#3198, AztecProtocol#2928 ~~Requires AztecProtocol#4135, which is blocked by noir-lang/noir#4124 Automatic storage initialization via aztec macro. Full support of public and private state from `dep::aztec::state_vars::*`, including Maps (and nested Maps!) Limited support for custom types (as long as they have a single serializable generic and their constructor is `::new(context, storage_slot`). ~~Pending: better errors, code comments and some cleanup.~~ Hijacking my own [comment](AztecProtocol#4200 (comment)) for the explanation: The idea behind this is that in 99% of cases, storage initialization (that is, the `impl` for a given `struct Storage...` is redundant, and the only need for its existence was assigning storage slots...which in turn were necessary because we didn't know how to serialize the data structures that were used in a given contract or how much space they used once serialized (relevant for the public state). After AztecProtocol#4135 is merged, both of those things don't have to be explicitly provided since we're using traits, so the aztec macro can infer the implementation of the Storage struct just by taking hints from the definition. An example: ```rust struct Storage { // MyAwesomeStuff implements Serialize<2>, so we assign it slot 1 (and remember that it will take 2 slots due to its size) public_var: PublicState<MyAwesomeSuff>, // Right after the first one, assign it to slot: current_slot + previous_size = 3 another_public_var: PublicState<MyAwesomeSuff>, // Private and Public state don't share slots since they "live" in different trees, but keeping the slot count simplifies implementation. // Notes also implement Serialize<N>, but they only take up 1 slot anyways because of hashing, assign it slot 5 a_singleton: Singleton<ANote>, // Maps derive slots via hashing, so we can assume they only "take" 1 slot. We assign it slot 6 balances: Map<AztecAddress, Singleton<ANote>>, // Slot 7 a_set: Set<ANote>, // Slot 8 imm_singleton: ImmutableSingleton<ANote>, // Slot 9. profiles: Map<AztecAddress, Map<Singleton<ANote>>>, } ``` We have all the info we need in the AST and HIR to build this automatically: ```rust impl Storage { fn init(context: Context) -> Self { Storage { public_var: PublicState::new(context, 1), // No need for serialization methods, taken from the the trait impl another_public_var: PublicState::new(context, 3), a_singleton: Singleton::new(context, 5), // Map init lambda always takes the same form for known storage structs balances: Map::new(context, 6, |context, slot| { Singleton::new(context, slot) }), a_set: Set::new(context, 7), imm_singleton: ImmutableSingleton::new(context, 8), // A map of maps is just nesting lambdas, we can infer this too profiles: Map::new(context, 9, |context, slot| { Map::new(context, slot, |context, slot| { Singleton::new(context, slot) }) }) } } } ``` ...as long as we use "canonical" storage implementations. This means `AStoragePrimitive<SomethingSerializable>` and `Map<SomethingWithToField, AStoragePrimitive<SomethingSerializable>>`. **TLDR:** define the Storage struct, in 99% of cases the macro takes care of the implementation! Implementing custom storage will look just like it does know, the macro will skip automatic generation if it finds one. --------- Co-authored-by: sirasistant <sirasistant@gmail.com>
superstar0402
added a commit
to superstar0402/aztec-nr
that referenced
this issue
Aug 16, 2024
Closes: AztecProtocol/aztec-packages#3198, AztecProtocol/aztec-packages#2928 ~~Requires AztecProtocol/aztec-packages#4135, which is blocked by noir-lang/noir#4124 Automatic storage initialization via aztec macro. Full support of public and private state from `dep::aztec::state_vars::*`, including Maps (and nested Maps!) Limited support for custom types (as long as they have a single serializable generic and their constructor is `::new(context, storage_slot`). ~~Pending: better errors, code comments and some cleanup.~~ Hijacking my own [comment](AztecProtocol/aztec-packages#4200 (comment)) for the explanation: The idea behind this is that in 99% of cases, storage initialization (that is, the `impl` for a given `struct Storage...` is redundant, and the only need for its existence was assigning storage slots...which in turn were necessary because we didn't know how to serialize the data structures that were used in a given contract or how much space they used once serialized (relevant for the public state). After AztecProtocol/aztec-packages#4135 is merged, both of those things don't have to be explicitly provided since we're using traits, so the aztec macro can infer the implementation of the Storage struct just by taking hints from the definition. An example: ```rust struct Storage { // MyAwesomeStuff implements Serialize<2>, so we assign it slot 1 (and remember that it will take 2 slots due to its size) public_var: PublicState<MyAwesomeSuff>, // Right after the first one, assign it to slot: current_slot + previous_size = 3 another_public_var: PublicState<MyAwesomeSuff>, // Private and Public state don't share slots since they "live" in different trees, but keeping the slot count simplifies implementation. // Notes also implement Serialize<N>, but they only take up 1 slot anyways because of hashing, assign it slot 5 a_singleton: Singleton<ANote>, // Maps derive slots via hashing, so we can assume they only "take" 1 slot. We assign it slot 6 balances: Map<AztecAddress, Singleton<ANote>>, // Slot 7 a_set: Set<ANote>, // Slot 8 imm_singleton: ImmutableSingleton<ANote>, // Slot 9. profiles: Map<AztecAddress, Map<Singleton<ANote>>>, } ``` We have all the info we need in the AST and HIR to build this automatically: ```rust impl Storage { fn init(context: Context) -> Self { Storage { public_var: PublicState::new(context, 1), // No need for serialization methods, taken from the the trait impl another_public_var: PublicState::new(context, 3), a_singleton: Singleton::new(context, 5), // Map init lambda always takes the same form for known storage structs balances: Map::new(context, 6, |context, slot| { Singleton::new(context, slot) }), a_set: Set::new(context, 7), imm_singleton: ImmutableSingleton::new(context, 8), // A map of maps is just nesting lambdas, we can infer this too profiles: Map::new(context, 9, |context, slot| { Map::new(context, slot, |context, slot| { Singleton::new(context, slot) }) }) } } } ``` ...as long as we use "canonical" storage implementations. This means `AStoragePrimitive<SomethingSerializable>` and `Map<SomethingWithToField, AStoragePrimitive<SomethingSerializable>>`. **TLDR:** define the Storage struct, in 99% of cases the macro takes care of the implementation! Implementing custom storage will look just like it does know, the macro will skip automatic generation if it finds one. --------- Co-authored-by: sirasistant <sirasistant@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: