Network account fees

[Mirko-von-Leipzig]

For full context, see the protocols tracking issue 0xMiden/protocol#3264 which will implement option C from 0xMiden/protocol#2968 (comment).

Note

This is blocked until the protocol work is further along.

Approach Summary

The chosen approach is roughly as follows (finer details will depend on the protocol work).

1. Accounts providing some service will have a standard function which returns a fee estimate for a given user input note.
2. Users wishing to use this service will invoke this function to obtain a fee estimate.
3. Users submit their note, and an additional SponsorshipNote containing the fee for the service.
4. The sponsor note is linked to the user note directly, and can only be consumed if the user note is executed as well.
5. Service account consumes both, user note is executed, fee is claimed.

This applies to network accounts, and therefore network transactions need to support this flow.

Wrinkles

• Sponsorship notes do not have to originate from the same transaction as the user note.
  • Some third party might sponsor the note, or
  • user may post it some time later/earlier
• Multiple sponsorship notes may exist for a given note
  • This also means multiple asset types can exist, though perhaps we can simplify initially so we don't need a price oracle.
• I imagine sponsorship notes can be reclaimable by the sender.
• Price fluctuations and decisions on when a sponsorship note is insufficient.
  • Probably fair to just say one pass is good enough i.e. if it fails once then its dropped.
• Network account may itself depend on other third party services i.e. fee estimates can fan out.
  • In general, fee estimations will require FPI.
  • This also means users will invoke FPI much more regularly, and perhaps we should consider some dedicated caching here for network accounts in the node.

[bobbinth]

I think from the node's standpoint, the heuristic could be fairly simple:

When NTX-builder includes network note X into a transaction, we need to:

• Find all network sponsorship notes for X. This probably warrants having some kind of a lookup table.
• Based on the number of notes found, make some decisions:
  • If not notes found, X cannot be included in a transaction.
  • If too many notes found, pick some subset of them (e.g., random 3 notes?).
• Once a set of the sponsorship notes has been identified, include them in a transaction and execute (same logic as we have now).

One thing that would be nice is to detect if execution fails for X because of insufficient fees. This may need to be handled via some event that is defined in the protocol and a specialized error type that is returned from the note consumption checker.