Network account component for detection and note script enforcement

[PhilippGackstatter]

One way to make network accounts more secure is by letting them specify a set of note script roots that they are willing to consume. Any other note script would be rejected. This can be defined as an account auth component, i.e. it has an auth procedure that enforces that only the configured set of note scripts is consumed.

Somewhat related, think we should remove AccountStorageMode::Network and instead define a network account by whether it has a NetworkAccount component or not. This simplifies the protocol by not having to deal with any network account related things.

Based on this, I can think of two ways to go about this:

• Create only a dummy NetworkAccount component for network account identification that occupies a single storage slot, conceptually containing just a bool flag is_network_account = true. This would not have to be an auth component. The main advantage is that network account creators have the full flexibility of defining their own auth procedure.
  • The actual enforcement for note script roots would be one additional account auth component, say NetworkAccountNoteScriptsAuth. In this approach, to create a network account with note script enforcement, add the NetworkAccount and NetworkAccountNoteScriptsAuth components to the account in the AccountBuilder.
• Enforce note script roots in NetworkAccount and also use it for network account detection (specifically by checking for the presence of a named storage slot). Since auth procedures of network accounts will surely have to be customized, we would likely need "auth templating" (Templating of auth procedures #1956), here which conceptually means making it extensible as NetworkAccount<MyCustomAuth>. We'd then have the option of enabling or disabling the note script root check, so users can also fully customize the account authentication, if desired.

I think most network accounts will want to consume only a specific set of notes, and so the second option, making this check part of NetworkAccount seems reasonable to me. However, the downside of templating is that we may not be able to reconstruct the NetworkAccount component in Rust from an AccountInterface, and while I'm not sure if this is needed, I would prefer keeping this separate. If we end up having other network account configuration parameters, then the NetworkAccount component would become more useful as well. So while I think both options are fine, I'd probably go with option 1.

Since I already sketched it, here is the second option.

pub struct NetworkAccount<AUTH: Into<AccountComponent>> {
    auth_extension: AUTH,
    notes: NetworkAccountNotes,
}

pub enum NetworkAccountNotes {
    AllowAll,
    // Maybe this should be a stronger type than Word.
    Allow(BTreeSet<Word>),
}

// Usage could be:
fn create_network_account() -> Account {
    // Network account that can consume P2ID and SWAP notes and has no custom auth extension.
    let notes = NetworkAccountNotes::Allow(
        [WellKnownNote::P2ID.script().root(), WellKnownNote::SWAP.script().root()].into(),
    );
    let network_account_component = NetworkAccount::<()>::new(notes);
    AccountBuilder::new([0; 32])
        .with_auth_component(network_account_component)
        .with_component(BasicWallet)
        .build()
        .expect("TODO")
}

In the auth procedure, it enforces that all note script roots of input notes are in the map:

const NOTE_SCRIPT_ROOTS_SLOT = word("miden::standards::network_account::note_script_roots")

pub proc auth_network_account(auth_args: BeWord)
    # pseudo logic
    for note_idx in 0..miden::protocol::tx::get_num_input_notes {
        let script_root = miden::protocol::input_note::get_script_root(note_idx);
        let map_value = miden::protocol::account::get_map_item(
          NOTE_SCRIPT_ROOTS_SLOT.slot_id(),
          script_root,
        );
        if map_value[3] == Felt::ZERO {
            panic!("disallowed note script root")
        }
    }
end

Some Context: #2219 (comment)

cc @Mirko-von-Leipzig @sergerad

[bobbinth]

I think there are two separate things here, and I'd potentially tackle them separately.

First, the node needs to figure out how to identify a network account and which notes it should try to execute against it. I think for this we need a component that manages the miden::standards::network_account::note_script_roots slot - i.e., keeps a list and also maybe provides functionality to add/remove scripts from this slot (though, not sure yet how we'd figure out who can perform such actions).

From the node's standpoint, any account that has miden::standards::network_account::note_script_roots would be a network account, and data in this storage slot would also let the node filter out potentially irrelevant notes sent to this account.

Second, we want to have an auth procedure which would also perform this check at the account level. This procedure would probably be bundles into an authentication component that also allows management of the storage slot as I mentioned above.

So, overall, we could implement this in two steps:

1. Implement something like NetworkAccount component which consists of a note script root map and a procedure to read the data from this map. This will provide enough functionality to update network account handling in the node.
2. Transform this component into an authentication component - similar to what you've sketched out above.

[Mirko-von-Leipzig]

Somewhat related, think we should remove AccountStorageMode::Network and instead define a network account by whether it has a NetworkAccount component or not. This simplifies the protocol by not having to deal with any network account related things.

iiuc its possible to change account code and therefore the node has to support accounts that change between normal and network accounts? If so, that would really.. be a pain.

I think for this we need a component that manages the miden::standards::network_account::note_script_roots slot - i.e., keeps a list and also maybe provides functionality to add/remove scripts from this slot (though, not sure yet how we'd figure out who can perform such actions).

This could be done via a specialized network note type(s) I think - e.g. add_script, remove_script, and the account could write its own authentication rules for who gets to submit those notes?

---

I think what's unclear to me is just how mutable a network account can be. Is the account code mutable? Currently this doesn't matter because only the operator can touch the account directly, but I'm unsure what this means in the long run.

Simplest would be that a network account is immutable once deployed, and one can only interact with it via notes. But once its just a normal account with a specific network component, then this becomes a problem.

[PhilippGackstatter]

So, overall, we could implement this in two steps

I agree the two steps are a better approach than what I described, specifically, a component specifying only the note script roots.

iiuc its possible to change account code and therefore the node has to support accounts that change between normal and network accounts? If so, that would really.. be a pain.

I think it makes sense for the network account decision to be permanent, so what we would want to enforce is that once the slot miden::standards::network_account::note_script_roots is added, it cannot be removed.

Whether this is even a problem depends on what we decide with code and storage upgrades (one proposal is in #2183 (comment)). In short, this proposes to have a generic native_account::upgrade tx kernel API that can update code and storage in arbitrary ways (i.e. remove and add procedures and slots). This would technically allow mutating a network account to remove that slot.

To prevent this, we'd have to make sure that this slot isn't removed, e.g. by checking in the auth procedure the account delta never contains StorageSlotDelta::Remove("miden::standards::network_account::note_script_roots").
Or, if network accounts should be truly completely immutable, require that native_account::upgrade was never called (via native_account::was_procedure_called).

Unified component

If we want to enforce this for network accounts, we'd really have to make this immutability part of the NetworkAccount component, meaning it would again be an auth component, with three procedures:

• add_script: Allows adding a note script root to the set.
• remove_script: Allows removing a note script root from the set.
• auth_network_account: Enforces immutability.

Separate components

Another approach is to leave NetworkAccount a regular account component like Bobbin described, i.e. for managing the set of note scripts. Separately, we have a ImmutableNetworkAccount auth component that enforces that the slot miden::standards::network_account::note_script_roots isn't removed. The node would basically only consider accounts network accounts if it had both components (which does seem like potential for confusion).

Multiple auth components

Both of these have a similar outcome: Users will want to customize the auth procedure behavior. Instead of templating, I think a better approach here is to allow multiple auth components in the AccountBuilder which would merge them into a single auth procedure. I think we don't need templating here because enforcing immutability, that input notes are in the allowed set and whatever the custom auth procedure does are independent, so they can be executed sequentially rather than nested in each other.

I'd go with the single NetworkAccount component and then allow multiple auth components like this:

fn create_network_account() -> Account {
    // Network account that can consume P2ID and SWAP notes.
    let network_account_component = NetworkAccount::new(
      BTreeSet::from_iter([
        WellKnownNote::P2ID.script().root(),
        WellKnownNote::SWAP.script().root()
      ])
    );
    let network_account_script_auth = todo!(
        "component enforcing only notes with configured script roots are consumed"
    );
    let my_custom_auth = todo!();
    AccountBuilder::new([0; 32])
        .with_auth_component(network_account_component)
        .with_auth_component(network_account_script_auth)
        .with_auth_component(my_custom_auth)
        .with_component(BasicWallet)
        .build()
        .expect("TODO")
}

This would create an account with a single auth procedure that is simply:

pub proc auth_tx(auth_args: BeWord)
    # pad stack
    call.network_account::authenticate(auth_args)
    # truncate stack
    
    # pad stack
    call.network_account_script_auth::authenticate(auth_args)
    # truncate stack

    # pad stack
    call.my_custom_auth::authenticate(auth_args)
    # truncate stack
end