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.

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

Implement the account storage API #340

Open
greenhat opened this issue Oct 8, 2024 · 3 comments
Open

Implement the account storage API #340

greenhat opened this issue Oct 8, 2024 · 3 comments
Milestone

Comments

@greenhat
Copy link
Contributor

greenhat commented Oct 8, 2024

As discussed in #333
And later on the call with @bobbinth, @bitwalker @igamigo @phklive

For the first iteration, use functions consistent with transaction kernel's:

  • set_storage_item / get_storage_item for getting/setting value slots.
  • set_storage_map_item / get_storage_map_item for reading, updating storage maps.

Also, if we could encapsulate them in a module, that may be slightly better ergonomics. For example, storage::get_item, storage::set_item, storage::get_map_item, storage::set_map_item.

For the second iteration, we go with macros:

#[component]
struct MyComponent {

    #[storage_slot(0)]  
    foo: StorageMap,

    #[storage_slot(1)]  
    pub_key: Value,

    #[storage_slot(2)]  
    misc: StorageMap,
}

Where the Value and StorageMap implement a trait similar to Mapping from https://github.com/r55-eth/r55/blob/main/eth-riscv-runtime/src/types.rs, so that the storage access will look like self.pub_key.read() and self.pub_key.write(value).

The storage metadata in the toml format is described in 0xPolygonMiden/miden-base#1015 needs to be generated and stored in the Miden package compiled artifact. The attribute macros can generate the metadata, and we can "smuggle" it past the rustc via the custom link_section (as wit-bindgen smuggles WIT binary, see generated bindings.rs) into the compiler.

@greenhat
Copy link
Contributor Author

@bobbinth @bitwalker @igamigo @phklive
I updated the description with the design we discussed on today's call.

@bobbinth
Copy link
Contributor

For the first iteration, we implement the generic set_storage_value(slot: usize, value: Word) and get_storage_value(slot: usize) -> Word functions and their map and vec variants.

I would probably use naming a bit more consistent with transaction kernel's.

  • set_storage_item / get_storage_item for getting/setting value slots.
  • set_storage_map_item / get_storage_map_item for reading updating storage maps.

Also, if we could encapsulate them in a module, that may be slightly better ergonomics. For example, storage::get_item, storage::set_item, storage::get_map_item, storage::set_map_item.

#[account_storage]
struct MyAccountStorage {

    #[storage_slot(0)]  
    foo: Mapping<Word>,

    #[storage_slot(1)]  
    pub_key: Mapping<StorageVec>,

    #[storage_slot(2)]  
    misc: Mapping<Word>,
}

I would make some small corrections to the above:

#[component]
struct MyComponent {

    #[storage_slot(0)]  
    foo: StorageMap,

    #[storage_slot(1)]  
    pub_key: Value,

    #[storage_slot(2)]  
    misc: StorageMap,
}

@greenhat
Copy link
Contributor Author

@bobbinth Thank you! I updated the description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants