Multi-Asset Fee Payments

[PhilippGackstatter]

The current constraints with fees in the tx kernel are:

• The fee must currently be paid in the designated native asset of the chain (e.g. USDC). We want to enable fee payments in essentially any asset ("multi-asset fee payments").
• The tx kernel is closely coupled to the definition and structure of FungibleAsset. In my mind, this is the main reason we need to have a notion of built-in and (later) custom (non-built-in) assets.
  • We could simplify the tx kernel a lot by treating all assets the same way: No need to validate the structure of fungible or non-fungible assets and no need to merge or split built-in assets differently from custom assets.
  • The tx kernel should not be opinionated how the fee asset is structured and the fee logic would be simpler if all fee assets were treated through the same interface.
• Fees must be calculated after the auth procedure, to include the number of cycles the auth procedure takes in the fee. This is not necessarily a problem, but would be nice to solve.

My assumption for multi-asset fee payments is that as long as we can make the tx kernel return an arbitrary asset, we have achieved that goal. Basically we can make the batch kernel convert this arbitrary asset (the batch producer may only accept a small set of assets) back into the native asset so that at block level, all fees are paid in the native asset. How exactly the batch kernel does this is out of scope for this discussion, but it could essentially facilitate that swap with its own account or by swapping through a service of its choice.

Generally, I believe there are two approaches to try and resolve some of these issues:

• Require users to call an explicit add_fee API that takes an arbitrary asset and uses it as the fee.
  • Main challenge: Since users need to know what amount to pay, transaction dry-runs are necessary to measure the fee.
• Keep the current automatic fee calculation and removal, but abstract the construction of the fee asset away by having a fee script that is invoked automatically by the kernel once the fee is calculated. That script turns an abstract notion of tx kernel "computation units" into a concrete fee asset, e.g. 1 USDC, 0.01 ETH, 1 POL, etc.
  • Main challenge: Fee script runs after fee was calculated and so it must have a cycles limit to avoid arbitrarily complex computations and it must be committed to in some way.

Both of these approaches abstract the construction of the fee asset away from the kernel: The user is responsible for providing an asset that is to be used as the fee, just in different ways. So, both approaches result in decoupling the definition of FungibleAsset from the tx kernel and allow for payments in an asset different from the native asset.

Terminology

I'll use "computation units" to refer to the amount from which the fee's amount is derived. It is based on tx cycles, number of created notes, etc. The current implementation that returns these units is basically ExecutedTransaction::compute_fee.

We can also imagine that we'd have multiple such units based on which the actual fee is calculated, but for the purpose of this discussion, I'd just assume one value from which the fee is derived.

Fee API Approach

One option is changing the architecture we have so far and remove automatic creation of the fee asset in the epilogue and instead require users to provide the fee via an explicit API, e.g. miden::protocol::tx::add_fee. This could be called multiple times from note or tx scripts and the fee assets would be added together (assuming they are the same asset or panic otherwise?).

Assuming the general case where users need to pay for their own local transaction by calling add_fee in the tx script, clients won't know the fee amount to pay upfront. Instead clients need to dry-run the tx to get the computation units in order to derive the fee asset from that .

By my read of the situation, every transaction would have to be executed three times with this approach:

• Once to get the tx summary. This would run with a chosen fee asset of the user but with its minimal value, say amount = 1, just to have "some" asset with which to execute. The tx summary would want to commit to the fee so we can avoid pre-fee/post-fee deltas, but the fee isn't known yet because the auth procedure hasn't run yet and so we can't estimate the fee properly yet.
• Ask user to sign the tx summary from step 1 and run again. Again with fee amount = 1, since we still don't know the actual number of computation units. This time we get past the auth procedure but the transaction aborts with an event like AUTH_UNAUTHORIZED_EVENT but for fees to get the computation units.
• Now we can compute the actual fee required based on the tx cycles. We need to ask the user to sign a second tx summary, this time with the correct fee.
• Finally, re-run the transaction with the second signature and the proper amount of the fee asset and get a successful transaction.

There is some variant of this where we say signature verification is deterministic code and so we can estimate its number of cycles "offline". So we may only need one run to get the number of cycles up to the signature verification, and this may eliminate the second sign step, though I'm not sure how we'd do this in practice as it sounds quite cumbersome.

Benefits:

• Makes the removed fee part of the tx_summary_commitment, meaning no pre-fee and post-fee account delta.
• Fee could be easily put into a dedicated fee note, avoiding the need to output the fee asset via the stack (for discussion on putting fee on stack vs note see also chore: refactor tx kernel from ASSET to ASSET_KEY and ASSET_VALUE #2396 (comment)).
• Would allow for a perfect measure on how many cycles the transaction will take in total (which we can only roughly estimate with the current approach).
• This could be useful for network transactions to make network notes pay part of the fee by calling add_fee, though how to estimate the proper amount may still be a challenge.
  Drawbacks:
• Asking the user for signing the transaction twice would be bad UX.
• Many re-runs of the same tx, although this could perhaps be optimized by doing VM checkpointing (e.g. being able to resume an execution in the VM from a previously successfully reached state). The APIs needed for executing and continuing execution in TransactionExecutor would probably not be very straightforward.

Fee Script Approach

Allow users to provide a "fee script" or "fee procedure".

• In this section:
  • I'll use fee script to refer to an arbitrary user-provided script, like a tx script.
  • I'll use fee procedure to refer to a procedure in the account's code that is added to an account via a "fee account component".
  • These approaches are exclusive: Assume either the fee script exists or the fee procedure, never both.
• The signature of both of these would be: create_fee(computation_units: felt) -> Asset. Its only job is to turn the computation units computed by the transaction kernel into an asset. So, in its simplest form, this could be a few lines of MASM code.
• This script/procedure is called in the epilogue after the computation units were calculated and the returned asset is removed from the native account's vault, like now. This would basically replace the create_native_fee_asset call in the epilogue.
• The main benefit is that it provides an abstraction for the tx kernel: Tx kernel provides computation units and gets back some arbitrary asset. The Tx kernel does not need to access the asset in any way, therefore providing full decoupling from the concrete asset.

The challenges with this are:

• It runs after the auth procedure and therefore anything it would do would not be covered by the user's signature. So, its access must be read-only (the tx must be "sealed" for user space before invoking it - the kernel itself would still mutate the tx aftereward).
• There needs to be a hard max number of cycles that it can take, since the cycles it takes are not included in the fee and therefore not "paid" for from a protocol perspective. We cannot allow attackers to produce huge proofs that put a burden on the batch kernel without paying for them. In other words, we give every transaction a small number of cycles it can use for free, but this should be low enough to not have a meaningful impact or be exploitable. This should also be unproblematic because its access is read-only.
• It must be committed to in some way:
  • The fee procedure (procedure with @fee_script) is part of the account's code and so it is committed to through the account code commitment.
  • The fee script is provided as advice input, like a tx script. The tx script's effects are covered by the TX_SUMMARY and so if a malicious remote prover would swap it for a different tx script, the tx would fail. However, the fee script's effects are not committed to by the TX_SUMMARY, as it runs after the summary is created, and so there needs to be a different way to commit to it. The simplest approach is to include the fee script MAST root in the TX_SUMMARY, which may be good enough. The downside is that the MAST root doesn't provide any form of introspection.

What would it look like to turn computation units into a concrete fee asset (like USDC)? Again, there are some variants:

• The fee script can be arbitrarily constructed at the time the tx is constructed which is a burden on the client, but also provides maximum flexibility: The client can fetch the latest conversion rate from computation units to USDC from a trusted source and construct an appropriate tx script.
  • This might be best done with a static fee script that takes FEE_ARGS as inputs, which are the conversion rate. This means the FEE_ARGS also need to be committed to, which is fine.
• The fee procedure can be used similarly: It is like a static fee script that can take some additional FEE_ARGS as inputs to provide the latest conversion rates at execution time. Again FEE_ARGS must be committed to via TX_SUMMARY.
• A static fee procedure or script could both also use FPI to call out to an oracle in order to fetch the conversion rate. This gets tricky since such an FPI call will incur a lot more cycles than a simple fee construction based on computation units and a conversion rate. If we want to enable this, we'd have to allow a higher number of max cycles this can take. The primary reason this would be useful is that the client would not need to provide any conversion rate or fee script as input.

To summarize the variants:

• Dynamic fee script: Full flexibility, minimal burden on the protocol (minimal number of extra cycles), maximal burden on the client (to create it for every tx).
• Static fee procedure or static fee script + FEE_ARGS: Some burden on the client to provide FEE_ARGS. This is the middle ground.
• Static fee procedure/script: Minimal burden on the client, but incurs higher number of cycles that are not covered by the actual fee, i.e. maximal burden on the protocol.

We don't necessarily have to make a decision for a single variant: For example, both a static fee procedure and optional FEE_ARGS are possible and users can choose one or the other.

Fee script vs procedure:

• Fee script is provided for every tx.
• Fee procedure is provided once at account creation time via a "fee account component".
• Fee script is committed to in every tx summary.
• Fee procedure is committed to in the account code.

Benefits:

• Fairly simple mechanism that ticks the boxes of decoupling tx kernel from assets and allows for multi-asset fee payments.
• A relatively simple extension to the existing automatic fee removal mechanism we have.
• There exists a good default at standards level or a set of good defaults at client or wallet level. The default miden-standards fee script or fee account component could return the native asset of the chain (ideally computation units translate into the native token in some non-variable way -> no conversion rate needed). So if users are fine with paying in the native asset, they are not bothered with that choice.
  Drawbacks:
• We still have pre- and post-fee account delta (like today; aesthetically unpleasing but otherwise unproblematic).
• Outputting fee asset via a note is difficult (see linked discussion above).

Conclusion

Both approaches would allow for paying fees in any asset. Both also eliminate coupling of the tx kernel to a specific asset representation for the fee asset, which is the last functional reason why we need built-in assets.

Out of the two approaches, I think the fee script/procedure is better due to being largely abstracted away from the user (no explicit API call) and no double signing.

As for fee script vs procedure, I can see pros and cons to both. The fee procedure is nicely consistent with the auth procedure and selected once at creation, limiting ongoing UX burden and does not require an ongoing commitment via the tx summary (minus potential fee args).

I'm now mainly curious if this direction is reasonable or if we need something completely different than what was described.

Note: This does not explore the idea of every account having a public purse from which fees can be taken and to which fees can be refunded, which may be an interesting alternative.

[bobbinth]

Thank you for writing this up! The fee procedure/fee approach is along the lines I was thinking of as well, though, I didn't try to generalize things quite as far. Specifically, the approach I was thinking could work like so:

We have a static fee conversion procedure defined in the transaction kernel. This conversion procedure would take the following inputs:

• The fee computed in native units.
• An optional target ASSET_KEY and an exchange rate between this asset and the native units. The asset specified by the asset key would have to be a fungible asset (with or without callbacks).
  • These inputs would be provided by the user at the start of the transaction and would be a part of public inputs (i.e., would be included in the stack inputs of the transaction).

The conversion procedure then would work as follows:

• If the target asset key is not provided, it would just return the native asset units.
• If the target asset key is provided, it would apply the provided conversion rate, and then build the fungible asset from this key.
• Lastly, it would check the number of cycles used to perform the conversion, and if it exceeded some limit (e.g., 1K cycles), it would abort. This last step is to make sure the potential callbacks don't cause trouble.

Your suggestion takes this a step further to make this procedure user-defined. I think this will work and there are some benefits to this - though, whether these benefits are worth the extra complexity, I'm not sure yet. Specifically, I think the benefits are as follows:

• The user gets much more flexibility in how to define such a fee conversion procedure. The counter-argument here is that there unlikely to be more than a few such procedures.
• The user gets the ability to pay fees in non-fungible or custom assets. Here again, I'm not sure if this adds a lot of value.
• Lastly, we get a step closer removing built-in assets from the protocol. This, perhaps, is the most attractive point.

I do think we can progress iteratively here:

1. First implement the static conversion procedure in the kernel - something similar to what I described above.
2. Then, make the procedure user-defined, and put one or two standard implementations for this procedure into the standards library.

We still have pre- and post-fee account delta (like today; aesthetically unpleasing but otherwise unproblematic).

I actually don't think that this is a drawback. I think having two separate account deltas is useful because eventually we'll need to make them structurally different as well. Specifically, the pre-fee delta would be relative and it would be useful for authentication purposes (as it is now), but the delta committed to by the transaction outputs would need to be an "absolute" delta (i.e., describing the final state of assets in the vault).

[PhilippGackstatter]

If the target asset key is provided, it would apply the provided conversion rate, and then build the fungible asset from this key.

That works, but retains some of the tx kernel's dependency on the exact structure of the FungibleAsset. The built-in compose procedure in the kernel does that anyway, so it's not the only place, but it is one more "unclean" corner of the tx kernel. My hope with the approach described in the second half of #2432 (comment) was that we'd only have the compose one 😅.

I think we can progress iteratively, but in the long-run it will be more difficult. My assumptions are:

• We go with your approach now and release mainnet.
• Then, we want to add user-defined fee procedures, but also need to maintain backward compatibility for the existing approach, since existing accounts will not have fee procedures defined.

We will definitely run into these kinds of scenarios with new features we add in other corners of the tx kernel / libraries, but I'd still like to avoid these as much as possible because maintaining two ways to do something is always more complex than just one. So, if we know from the start that we'll need some generalized mechanism, I'd rather spend a bit more time on that, but that's just my view of the situation.

The user gets the ability to pay fees in non-fungible or custom assets. Here again, I'm not sure if this adds a lot of value.

If USDC or some other commonly used asset is implemented as a custom asset, it would be excluded from being used as a fee asset, at least until we have generalized fee procedures.

So, while I think your suggestion can definitely work, I find the generalized approach cleaner and it does not single out FungibleAssets at the protocol level to be more useful than other types of assets. My goal is to make the protocol as permissionless and unrestrictive as possible, and I guess we generally want to get to that point, the question is just in what way.

[bobbinth]

I think we can progress iteratively, but in the long-run it will be more difficult.

So, while I think your suggestion can definitely work, I find the generalized approach cleaner and it does not single out FungibleAssets at the protocol level to be more useful than other types of assets. My goal is to make the protocol as permissionless and unrestrictive as possible, and I guess we generally want to get to that point, the question is just in what way.

Agreed! My thinking was that maybe we'll get to your approach before mainnet. Maybe v0.15 will have the first step (as I described), and v0.16 will go all the way.

[sueun-dev]

This direction makes sense to me, but I would strongly favor an iterative rollout.

If the long-term goal is to decouple the kernel from a special asset model, I would start with the smallest protocol surface that proves the economics and commitment story:

• first, a kernel-owned conversion path for native + selected fungible assets,
• then, only after that is stable, an account-level or user-defined fee procedure.

The part I would be most careful about is not the asset construction itself, but quote commitment and replay/staleness boundaries. If a transaction can pay in a non-native asset using external conversion data, it seems important that the transaction summary commits to at least the fee asset identity, the quote/rate inputs, and some expiry or validity boundary. Otherwise the flexibility is great, but the trust surface becomes harder to reason about.

So my instinct is: keep the first version boring, explicit, and easy to audit, even if it is less general. If that lands well, the user-defined procedure path looks like a strong second step.