feat(standards): add NetworkAccount auth component

[partylikeits1983]

Resolves: #2814

Summary

Adds a new auth component intended for network-owned accounts (AggLayer bridge, AggLayer faucet). Replaces the NoAuth pattern which lets any transaction emit output notes authored by the account and thus forge bridge-authored MINT notes (see #2797).

The auth procedure enforces two invariants:

1. Rejects the transaction if a tx script was executed, using tx::get_script_root from the kernel (added in feat(kernel): expose tx script root via public kernel procedure #2816).
2. Rejects the transaction if any consumed input note's script root is not present in the component's whitelist.

If both checks pass, the nonce is incremented when the account state changed or the account is new, matching the NoAuth / SingleSig behavior.

Changes

• asm/account_components/auth/network_account.masm — new auth procedure auth_tx_network_account.
• src/account/auth/network_account.rs — NetworkAccount Rust struct with From<NetworkAccount> for AccountComponent and unit tests.
• src/account/components/mod.rs — registers NETWORK_ACCOUNT_LIBRARY, adds network_account_library(), extends StandardAccountComponent with AuthNetworkAccount.
• src/account/interface/component.rs, extension.rs — extend AccountComponentInterface with AuthNetworkAccount (maps to AuthMethod::NoAuth for now; a distinct AuthMethod variant can be added later if needed).
• tests/auth/network_account.rs — integration tests covering: tx-script rejection, non-whitelisted-note rejection, and the happy path.

Storage layout

• Single map slot at miden::standards::auth::network_account::whitelist.
• Keys: note script roots (Word). Values: sentinel [1, 0, 0, 0] marking presence.
• Fixed at account creation (mutable whitelist is a possible future improvement).

Stacking

This PR is stacked on #2816 (PR 1 of the #2797 fix chain). It is the second PR of three; the AggLayer wire-up in #2815 will land on top.

Closes #2814. Related to #2797.

[PhilippGackstatter]

Looks good! I took a high level look.

As mentioned in #2797 (comment), I would suggest renaming this from the more general NetworkAccount to something like NoteScriptAllowlistAuth.

Also, I suggest renaming whitelist to allowlist.

[bobbinth]

As mentioned in #2797 (comment), I would suggest renaming this from the more general NetworkAccount to something like NoteScriptAllowlistAuth.

I don't mind generalizing this, but then I don't think NoteScriptAllowlistAuth would be an auth component as checking whether a note belongs to the allowed set of notes would be done as a part of another auth component (e.g., a component that also checks a signature). I think there are a couple of ways to go about this:

Approach 1

We could move most of the logic into a module somewhere in the standards library (e.g., under miden::standards::auth namespace). The logic could be split across two procedures - something like:

#! Inputs:  []
#! Outputs: []
pub proc assert_no_tx_script
    ...
end

#! Inputs:  [allowed_note_scripts_slot_id_prefix, allowed_note_scripts_slot_id_suffix]
#! Outputs: []
pub proc assert_all_input_notes_allowed
    ...
end

Then, these procedures could be used from the AuthNetworkAccount auth component and also from future components that would be used by non-network accounts to limit a set of notes that can be executed against them.

Approach 2

Put the logic of the into a separate component NoteScriptAllowlist (or something similar), and then also create an AuthNetworkAccount that would depend on this component.

---

Between these two approaches, I have a slight preference towards the first approach - mostly because I think it is a bit simpler and doesn't require us to think too much about how this functionality will be used outside of network components in the future.

Also, I suggest renaming whitelist to allowlist.

If we go with approach 1 above, I'd actually name the storage slot something like:

miden::standards::auth::network_account::allowed_note_scripts

[PhilippGackstatter]

I don't mind generalizing this, but then I don't think NoteScriptAllowlistAuth would be an auth component as checking whether a note belongs to the allowed set of notes would be done as a part of another auth component (e.g., a component that also checks a signature). I think there are a couple of ways to go about this:

Do you mean that the logic in assert_no_tx_script and assert_all_input_notes_allowed is general enough to be used by multiple auth components?

If so, I agree on the assert_no_tx_script part - it only relies on the newly introduced kernel procedure but has no dependency on storage, so it is indeed very generic.

The assert_all_input_notes_allowed procedure requires a well-defined storage layout in an account's storage. So, I would support this with an AllowedNoteScripts type that is essentially a standardized storage slot, a bit like the (soon to be removed) TokenMetadata:

protocol/crates/miden-standards/src/account/faucets/token_metadata.rs

Lines 197 to 201 in f2c6625

	impl From<TokenMetadata> for StorageSlot {
	fn from(metadata: TokenMetadata) -> Self {
	StorageSlot::with_value(TokenMetadata::metadata_slot().clone(), metadata.into())
	}
	}

This type defines the storage layout conversion and the slot name (miden::standards::auth::network_account::allowed_note_scripts).

So, I agree with approach 1 and would scope this functionality under:

• miden::standards::auth::network_account::assert_no_tx_script
• miden::standards::auth::network_account::assert_all_input_notes_allowed

And support this with the AllowedNoteScripts type.

The only open question is how a network account would easily add this auth functionality in a "one-liner", and for this I think we need an auth component like NoteScriptAllowlistAuth.

[bobbinth]

The assert_all_input_notes_allowed procedure requires a well-defined storage layout in an account's storage.

I was thinking that this procedure would take the storage slot name as a parameter (see the signature in my comment). This way, different auth components could have their own storage slots to hold the set of allowed notes.

[mmagician]

I was thinking that this procedure would take the storage slot name as a parameter (see the signature in my comment). This way, different auth components could have their own storage slots to hold the set of allowed notes.

Agreed with approach 1 and with passing the storage slot name as parameter. We already handle this very similarly with the double-word array, which is just a module and then other components (e.g. the bridge_out component) can import it and pass to it their own slot.

---

As to whether allowlist is the right approach, or perhaps a flag that would prevent accounts from producing output notes unless called via an account procedure (IIUC) as was suggest by @bobbinth: for the specific use case that @partylikeis1983 is solving for - AggLayer - I think it makes sense to restrict the type of notes that an account can consume. We only want canonical notes to be processed by the bridge account.

One "downside" to this approach is that if the canonical note script ever changes for whatever reason (I wouldn't discard that it will, due to bugs or optimizations), we need to be able to update the allow list. So we would additionally need a helper allowlist setter only writeable by the owner, and a network note to trigger the update (CONFIG_ALLOWLIST_NOTE).

Note: since issuing updates to the allowlist is done via (CONFIG_ALLOWLIST_NOTE), its script must be allowed by default (otherwise we brick the ability to update the allowlist)

---

Separately, the feature suggested by Bobbin is of independent interest, which we might want to pursue independently. We could open an issue, but unless a concrete use case for it arises, I'd defer tackling it to post-launch.

[partylikeits1983]

Implemented the suggestions above:

• Renamed to NoteScriptAllowlistAuth
• whitelist → allowlist, slot now miden::standards::auth::note_script_allowlist::allowed_note_scripts
• Split out assert_no_tx_script and assert_all_input_notes_allowed(slot_id_suffix, slot_id_prefix) into a reusable miden::standards::auth::note_script_allowlist module per Bobbin's approach 1
• Drop auth args explicitly at entry of auth component
• Renamed test helper to build_allowlist_account

[bobbinth]

Looks good! Thank you! I left some comments about naming - but the code itself looks great!

[bobbinth]

Looks good! Thank you! I left just two more minor comments inline.

[bobbinth]

All looks good! Thank you!