[x/programs] Refactor SDK storage

[hexfusion]

The current host module map was a POC example of storing data on the host. In order to integrate programs into a VM we need to refactor Program storage. This PR proposes a new host module called state_keys and changes to the SDK to provide clear separation between interactions with module Memory and the hosts State.

• rename State to Program
• propose a new enum based Program state schema which emulates HyperSDK.
• Document how a Program can utilize Memory and State
• New macro state_keys which implements StateKeys for the user and helps to standardize the format.
• Handle errors inline with ETH standards. In general all examples will show halt on error usage.
• Remove Wasi dependencies from example programs
• Add tests

cargo expand for new state_key macro shows its implementation

/// The program state keys.
#[repr(u8)]
enum StateKey {
    /// The total supply of the token.
    TotalSupply,
    /// The name of the token.
    Name,
    /// The symbol of the token.
    Symbol,
    /// The balance of the token by address.
    Balance(Address),
}
#[automatically_derived]
impl ::core::marker::Copy for StateKey {}
#[automatically_derived]
impl ::core::clone::Clone for StateKey {
    #[inline]
    fn clone(&self) -> StateKey {
        let _: ::core::clone::AssertParamIsClone<Address>;
        *self
    }
}
impl StateKey {
    pub fn to_vec(self) -> Vec<u8> {
        match self {
            Self::TotalSupply => {
                <[_]>::into_vec(#[rustc_box] ::alloc::boxed::Box::new([0u8]))
            }
            Self::Name => <[_]>::into_vec(#[rustc_box] ::alloc::boxed::Box::new([1u8])),
            Self::Symbol => <[_]>::into_vec(#[rustc_box] ::alloc::boxed::Box::new([2u8])),
            Self::Balance(a) => std::iter::once(3u8).chain(a.into_iter()).collect(),
        }
    }
}

[exdx]

LGTM just some thoughts

[exdx]

In terms of actual design feedback, I'm not caught up enough to provide a clear opinion. But the proposed design seems reasonable, and importantly, simple to understand. So that's good.

[exdx]

In Stellar they use env as a wrapper around storage. Might be worth considering, the UX is nice. https://soroban.stellar.org/docs/getting-started/storing-data#contract-data-access

[hexfusion]

In Stellar they use env as a wrapper around storage. Might be worth considering, the UX is nice. https://soroban.stellar.org/docs/getting-started/storing-data#contract-data-access

I think we started there and have changed a few times. I think Program makes sense but open to further conversation.

[richardpringle]

@hexfusion... wait a minute, aren't you supposed to do that first 😝

[hexfusion]

@hexfusion... wait a minute, aren't you supposed to do that first 😝

Yeah I realized after the fact that I was making some assumptions in the memory module so added some tests.

[richardpringle]

Looking good! Majority of my comments are more thoughts for the future.

[richardpringle]

🚀

[patrick-ogrady]

Do we need to ensure that the amount written is equal to bytesLen?

[hexfusion]

the runtime implementation handles all this maybe the example is more confusing than helpful.

[patrick-ogrady]

I think we should just be clearer about expectations to safely use. I think the example is nice.

[patrick-ogrady]

Is there some error we should be checking here? (maybe out of scope for readme)

[hexfusion]

yeah just example usage error removed for brevity.

[patrick-ogrady]

nit: non-durable

[patrick-ogrady]

❤️

[patrick-ogrady]

is this considered an optimization or required?

[hexfusion]

panic=abort is the default for the wasm32-unknown-unknown target which is now our default target. So this is just visibility to the default in case we wanted to changed it. I do have a question of how well the memory is cleaned up in this case by the OS.

[hexfusion]

The rust book describes this as well as says "dont panic" :)

Ultimately, panics translate into aborts in wasm32-unknown-unknown anyways, so this gives you the same behavior but without the code bloat.

ref. https://rustwasm.github.io/docs/book/reference/code-size.html?highlight=panic#avoid-panicking