Typed note inputs DX

[greenhat]

With the introduction of the #[note_script] attribute macro and the P2ID note script looks like:

compiler/examples/p2id-note/src/lib.rs

Lines 25 to 37 in 41926fa

	#[note_script]
	fn run(_arg: Word) {
	let inputs = note::get_inputs();
	let target_account_id_prefix = inputs[0];
	let target_account_id_suffix = inputs[1];
	let account_id = account::get_id();
	assert_eq(account_id.prefix, target_account_id_prefix);
	assert_eq(account_id.suffix, target_account_id_suffix);
	let assets = note::get_assets();
	for asset in assets {
	receive_asset(asset);
	}
	}

The next step up is the typed note inputs. Instead of Vec<Felt> we could return the note inputs as T given the deserialization from Vec<Felt> is implemented for T.

#[derive(Deserialize)]
struct MyNote {
    account_id: AccountId,
}


#[note_script]
fn run(_arg: Word) {
    let my_note = note::get_inputs_as::<MyNote>();
    ... or 
    let my_note: MyNote = note::get_inputs_as();
    ...
    // access my_note.account_id
    ...
}

Where AccountId implements the deserialization from Vec<Felt>. We could implement the deserialization for the Miden SDK types, but for custom types the deserialization is expected to be implemented by the user.

@bitwalker @otrho @bobbinth

[bobbinth]

Thank you @greenhat! I think this will simplify working with notes quite a bit.

As the end goal (not for next iteration but maybe for one after that), I wonder if we can hide even more boilerplate behind proc macros. It would be awesome if we could get to something that looks like this:

#[note]
struct MyNote {
    recipient: AccountId,
}

#[note]
impl MyNote {

    #[entrypoint]
    pub fn run(&self, _args: Word) {
        let account_id = account::get_id(); 
        assert_eq!(self.recipient, account.id());

        ...
    }   
}

And in an even longer run, to something like this:

#[note]
struct MyNote {
    recipient: AccountId,
}

#[note]
impl MyNote {

    #[entrypoint]
    pub fn run(&self, account: &BasicWallet, _args: Word) {
        assert_eq!(self.recipient, account.id());

        ...
    }   
}

Not sure though if there are some practical limitations of proc macros which would make this difficult (or maybe impossible).

Also, cc @mmagician, @Dominik1999, and @partylikeits1983 for visibility.

[greenhat]

I think we can skip my idea and jump straight on to yours since it's not much harder to implement. For it to work the #[note] macros need to generate the following function (real entrypoint):

__entripoint(args: Word) {
    let note_inputs: Vec<Felt> = note::get_inputs();
    let note_instance: MyNote = MyNote::deserialize_from_felts(note_inputs);
    note_instance.run(args); // call `#[entrypoint]` method
}

#[note] attribute will derive the deserialization for MyNote. Deserialization should be smart since typically we'd want to do mem::transmute, like treat the slice [Felt, Felt] as AssetId, etc.
I also omitted the note script WIT machinery for simplicity.

The passing BasicWallet instance as a parameter in the #[entrypoint] function is the major challenge because we don't have access to the BasicWallet Rust type defined in the account crate. In the P2ID note script crate we don't have the account crate in the dependencies and use only its WIT interface to generate the Rust bindings with wit-bindgen that look like:

pub mod basic_wallet {
    pub fn receive_asset(asset: Asset) -> () {
        ...
    }
    pub fn move_asset_to_note(asset: Asset, note_idx: NoteIdx) -> () {
        ...
    }
}

It's a bunch of functions in a module.

[bobbinth]

The passing BasicWallet instance as a parameter in the #[entrypoint] function is the major challenge because we don't have access to the BasicWallet Rust type defined in the account crate. In the P2ID note script crate we don't have the account crate in the dependencies and use only its WIT interface to generate the Rust bindings with wit-bindgen

Yes, I intentionally skipped how BasicWallet would be defined because I assumed that's not a simple thing. I am wondering if we could "auto-generate" the struct somehow based on the interface. For example, could we have something like this:

struct BasicWallet;

impl BasicWallet {

    /// Every basic wallet is an account, and so we should have account-specific methods exposed.
    /// This is kind of like "inheriting" account functionality in the basic wallet.
    pub fn account_id(&self) -> AccountId {
        miden::account::get_id()
    }

    pub fn receive_asset(&mut self, asset: Asset) {
        miden::contracts::basic_wallet::receive_asset(asset);
    }

    pub fn move_asset_to_note(&mut self, asset: Asset, note_idx: NoteIndex) {
        miden::contracts::basic_wallet::move_asset_to_note(asset, note_idx);
    }
}

The above code would be hidden from there user - for them, the'll just interact with the BasicWallet struct which they'd import from miden namespace (or something similar).

How the struct is generated, I'm not sure. Maybe it could be done with proc macros, maybe there will be an extra processing step at code generation time of the BasicWallet component.

A separate (and even more difficult) question is how to deal with "composite" accounts - i.e., where an account could implement multiple components and the note needs to assume that both components are present on the account. But I think this deserves a separate issue.

[partylikeits1983]

Super cool! Just wondering what would need to be done such that it is possible to pass an object to NoteInputs?

Suppose you have the following struct:

struct NoteInputs {
    recipient: AccountId,
    is_reclaimable: bool,
    timelock_height: u32,
}

let inputs = NoteInputs {
    recipient,
    is_reclaimable: false,
    timelock_height: 100,
};

// What needs to be implemented (e.g., serialization) so that
// we can pass `inputs` to `NoteInputs::new`?
let note_inputs = NoteInputs::new(inputs).unwrap(); // `NoteInputs` defined in miden-objects

---

On a slightly different topic, but since its related to the code snippets above:

If #702 is implemented, this:

let account_id = account::get_id(); 
assert_eq(account_id.prefix, target_account_id_prefix); 
assert_eq(account_id.suffix, target_account_id_suffix);

could be expressed like this:

let account_id = account::get_id();
let target_account = AccountId::from(target_account_id_prefix, target_account_id_suffix);
assert_eq(account_id, target_account);

[mmagician]

#[note]
impl MyNote {

    #[entrypoint]
    pub fn run(&self, _args: Word)

@bobbinth do you suggest this frontend (impl MyNote -> pub fn run) to be more Rust-like?

I was thinking that for the lowest amount of boilerplate, we could have:

#[note]
struct MyNote {
    recipient: AccountId,
}

#[note_script]
fn run(self, _arg: Word) {
    let target_account = self.recipient;
    let current_account = account::get_id();
    assert_eq!(current_account, target_account);

    let assets = note::get_assets();
    for asset in assets {
        receive_asset(asset);
    }
}

whereas if we're looking for high Rust-likeness, then probably we should go with what you suggested. One variation that occurred to me would be to use a trait instead of defining #[entrypoint]:

...
#[note]
struct MyNote {
    recipient: AccountId,
}

impl NoteScript for MyNote { // <---- trait name TBD

    pub fn run(&self, _args: Word) {...}
}

[bobbinth]

I was thinking that for the lowest amount of boilerplate, we could have:

#[note]
struct MyNote {
    recipient: AccountId,
}

#[note_script]
fn run(self, _arg: Word) {
    let target_account = self.recipient;
    let current_account = account::get_id();
    assert_eq!(current_account, target_account);

    let assets = note::get_assets();
    for asset in assets {
        receive_asset(asset);
    }
}

This could work - the only thing is that we won't be able to use self as a parameter to run(). It would have to be something like:

#[note_script]
fn run(note: MyNote, _arg: Word) {
    ...
}

A I do think using self is a bit more intuitive.

One variation that occurred to me would be to use a trait instead of defining #[entrypoint]

Yes, if we can make this approach work, I think it will be better.

[greenhat]

The passing BasicWallet instance as a parameter in the #[entrypoint] function is the major challenge because we don't have access to the BasicWallet Rust type defined in the account crate. In the P2ID note script crate we don't have the account crate in the dependencies and use only its WIT interface to generate the Rust bindings with wit-bindgen

Yes, I intentionally skipped how BasicWallet would be defined because I assumed that's not a simple thing. I am wondering if we could "auto-generate" the struct somehow based on the interface. For example, could we have something like this:

struct BasicWallet;

impl BasicWallet {

/// Every basic wallet is an account, and so we should have account-specific methods exposed.
/// This is kind of like "inheriting" account functionality in the basic wallet.
pub fn account_id(&self) -> AccountId {
    miden::account::get_id()
}

pub fn receive_asset(&mut self, asset: Asset) {
    miden::contracts::basic_wallet::receive_asset(asset);
}

pub fn move_asset_to_note(&mut self, asset: Asset, note_idx: NoteIndex) {
    miden::contracts::basic_wallet::move_asset_to_note(asset, note_idx);
}

}
The above code would be hidden from there user - for them, the'll just interact with the BasicWallet struct which they'd import from miden namespace (or something similar).

How the struct is generated, I'm not sure. Maybe it could be done with proc macros, maybe there will be an extra processing step at code generation time of the BasicWallet component.

I see two options to get there:

1. Fork the wit-bindgen. There is currently no way to customize how wit-bindgen generates basic_wallet::receive_asset, etc. functions from the WIT interface. We could fork it and generate the bindings however we want. This'd be costly, since wit-bindgen is one of the pillars of the Wasm CM ecosystem and maintaining it would be challenging. Besides that, deviating from the wit-bindgen kind of bindings we might end up forking other parts of the Wasm CM ecosystem.

2. Use WIT resource to represent an account. I believe it would end up as struct in Rust bindings with self, etc. Last time I tried it the missing call_indirect support was a roadblock. Besides that we'd need context management support from the VM. Further experiments are needed to determine if it's a good fit for an account.

[Dominik1999]

I was thinking that for the lowest amount of boilerplate, we could have:

#[note]
struct MyNote {
    recipient: AccountId,
}

#[note_script]
fn run(self, _arg: Word) {
    let target_account = self.recipient;
    let current_account = account::get_id();
    assert_eq!(current_account, target_account);

    let assets = note::get_assets();
    for asset in assets {
        receive_asset(asset);
    }
}

This could work - the only thing is that we won't be able to use self as a parameter to run(). It would have to be something like:

#[note_script]
fn run(note: MyNote, _arg: Word) {
    ...
}

This already looks very good and intuitive.

The only thing I would change is the notion of note::get_assets() and receive_assets(). At least to me, it is a bit confusing - semantically. So the first functions let me get the assets. So, I would assume that I now have to transfer_assets_to_account(assets). Basically, receive here would mean the same as get, but I already have them.

[bobbinth]

I see two options to get there:

1. Fork the wit-bindgen. There is currently no way to customize how wit-bindgen generates basic_wallet::receive_asset, etc. functions from the WIT interface. We could fork it and generate the bindings however we want. This'd be costly, since wit-bindgen is one of the pillars of the Wasm CM ecosystem and maintaining it would be challenging. Besides that, deviating from the wit-bindgen kind of bindings we might end up forking other parts of the Wasm CM ecosystem.
2. Use WIT resource to represent an account. I believe it would end up as struct in Rust bindings with self, etc. Last time I tried it the missing call_indirect support was a roadblock. Besides that we'd need context management support from the VM. Further experiments are needed to determine if it's a good fit for an account.

Could there be a 3rd option of generating this code "on the fly" - e.g., via a proc macro? For example:

#[account(miden::contracts::basic_wallet)]
struct BasicWallet;

And this would generate the code:

impl BasicWallet {

    /// This is added by default by the `account` macro.
    pub fn account_id(&self) -> AccountId {
        miden::account::get_id()
    }

    /// This is constructed by the macro from the info in the `miden::contracts::basic_wallet` module
    pub fn receive_asset(&mut self, asset: Asset) {
        miden::contracts::basic_wallet::receive_asset(asset);
    }

    /// This is constructed by the macro from the info in the `miden::contracts::basic_wallet` module
    pub fn move_asset_to_note(&mut self, asset: Asset, note_idx: NoteIndex) {
        miden::contracts::basic_wallet::move_asset_to_note(asset, note_idx);
    }
}

Not sure how feasible it is (i.e., do proc macros have enough capabilities to do something like this?) - but if it is, we could use this to combine multiple components - e.g., something like:

#[account(foo_component, bar_component)]
struct FooBarAccount;

[greenhat]

I see two options to get there:

1. Fork the wit-bindgen. There is currently no way to customize how wit-bindgen generates basic_wallet::receive_asset, etc. functions from the WIT interface. We could fork it and generate the bindings however we want. This'd be costly, since wit-bindgen is one of the pillars of the Wasm CM ecosystem and maintaining it would be challenging. Besides that, deviating from the wit-bindgen kind of bindings we might end up forking other parts of the Wasm CM ecosystem.
2. Use WIT resource to represent an account. I believe it would end up as struct in Rust bindings with self, etc. Last time I tried it the missing call_indirect support was a roadblock. Besides that we'd need context management support from the VM. Further experiments are needed to determine if it's a good fit for an account.

Could there be a 3rd option of generating this code "on the fly" - e.g., via a proc macro? For example:

#[account(miden::contracts::basic_wallet)]
struct BasicWallet;
And this would generate the code:

impl BasicWallet {

/// This is added by default by the `account` macro.
pub fn account_id(&self) -> AccountId {
    miden::account::get_id()
}

/// This is constructed by the macro from the info in the `miden::contracts::basic_wallet` module
pub fn receive_asset(&mut self, asset: Asset) {
    miden::contracts::basic_wallet::receive_asset(asset);
}

/// This is constructed by the macro from the info in the `miden::contracts::basic_wallet` module
pub fn move_asset_to_note(&mut self, asset: Asset, note_idx: NoteIndex) {
    miden::contracts::basic_wallet::move_asset_to_note(asset, note_idx);
}

}
Not sure how feasible it is (i.e., do proc macros have enough capabilities to do something like this?) - but if it is, we could use this to combine multiple components - e.g., something like:

We could probably parse the TokenStream produced by the wit-bindgen and recognize the functions. We would need the user to specify the miden::contracts::basic_wallet path which is not an optimal DX. The path is derived from the namespace:package/interface defined in the account. I wonder if we could get it automatically from the miden package dependency.

#[account(foo_component, bar_component)]
struct FooBarAccount;

The first thing that comes to mind is the name clashing. We would need to handle the case of the functions with the same name in those components. I'm not sure how to handle it except by throwing an error.

As a side note, I made #720 to explore the WIT generation from the Rust code in the account. I believe it is the most significant improvement to the overall DX. Eliminating the need to write WIT by hand would lower the bar significantly for the newcomers so I would start there.