How do network accounts handle fee payment?

[mmagician]

TL;DR: Network accounts must pay fees when consuming notes, either subtracted from their own vault, or carried by the consumed note.

Background

We currently have a very basic fee mechanism in Miden, where the originating account pays the fee.
The number of cycles is estimated towards the end of the transaction, in the epilogue, and then multiplied by the base fee to obtain the total fee that the account must pay.
This applies to all accounts, regardless of their storage mode (Private vs. Public vs. Network).

The issue is that currently anyone can send notes targeted to a Network Account, and, assuming that the note in actually consumable (e.g. it doesn't call any invalid procedures on the account interface), the network account builder will automatically try to consume the note against that network account.

This can result in a similar griefing attack as the issue described in the P2IDS standard proposal re: auto-consumption of P2ID notes in the wallet. But, it can just as well result from honest behavior, for example in the case of the AggLayerBridge, where GER updates are supposed to be processed by the network account. If the UPDATE_GER is purely a "data note", i.e. it carries no asset (specifically, no native asset), then the network account has to be pre-funded, and the owner/operator of such account must ensure there are always enough assets in the vault to cover the fees*.

Proposal A

Adopt the P2IDS-ish (and other "-S(ponsored)", e.g. MINT-S, UPDATE_GER-S) note standard as the default (for all? for network accounts?), and within each publicly exposed account procedure ensure that the originating note is a sponsored note.
E.g. this could look like:

pub proc distribute
    exec.is_owner
    # => [is_owner, amount, tag, aux, note_type, execution_hint, RECIPIENT, pad(7)]

    assert.err=ERR_ONLY_OWNER_CAN_MINT
    # => [amount, tag, aux, note_type, execution_hint, RECIPIENT, pad(7)]

    exec.active_note::assert_sponsored # <--------------- we add this to miden-lib

    exec.faucets::distribute
    # => [pad(16)]
end

Then, it would become the responsibility of the developer to either:

• decide if they want to pre-fund the vault and have 3rd party users transact for free, or
• within each procedure, require the note is sponsored by the 3rd party caller (the note originator)

Proposal B

Same as A regarding adopting the "-S(ponsored)" standard, but instead of encoding the "assert is sponsored" logic within each account procedure, the network account would specify which note script MAST roots they're willing to automatically consume (IIRC there was some work/discussion on this but couldn't find the thread), and reject any other notes.

It would still be the responsibility of the developer to specify which notes their account can/wants to consume, but with the following trade-offs:

• no need to hardcode this check into each account procedure. It would be done once per account ✅
• the list of note scripts would need to be hardcoded, resulting in a rigid way of how users can interact with this account 🔴

Proposal C?

Footnotes

*which, funnily enough, circles back to the same question of auto-consuming notes: how does the owner pre-fund the account, if the network account has no fee to consume the P2ID note in the first place? (hint: see the P2IDS standard)