Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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>
- Loading branch information