FRAME: Syntax for marking calls "feeless"

[liamaharon]

Moving an internal FRAME team discussion to a Github issue.

Motivation

@gavofyork suggested a new syntax which can be used before a call and have it mean that it can skip all normal transaction fee and account existence requirements.

#[pallet::feeless_if(|origin: &OriginFor<T>, ticket: &Ticket| -> bool {
	let account = ensure_signed(origin.clone())?;
	some_conditions_here(&account, &ticket)
})]

@gupnik volunteered to work on it.

Solution

@gupnik suggested a solution and requested feedback:

1. Pallet Call enum can optionally have a feeless conditional.
2. Construct Runtime creates a RuntimeSignedExtension that takes OnChargeTransaction.
3. In post_dispatch, we check if the current call has a feeless conditional. If so, the fee is never charged (bypassing the requirement the caller has any balance).

A couple of questions

1. How can RuntimeSignedExtension know the amount that was charged originally?
2. Is there a way to test the entire flow using a unit test? Any references that I could use?

Other questions

• @KiChjang suggested rather than an attribute macro this could be implemented in a way more 'rustic'.
• @liamaharon considered rather than the method returning a bool, it returning a Balance which could be used to modify the fee in more than a single way way.

[bkchr]

• Pallet Call enum can optionally have a feeless conditional.

• Construct Runtime creates a RuntimeSignedExtension that takes OnChargeTransaction.

• In post_dispatch, we check if the current call has a feeless conditional. If so and the condition returns true, the fee is refunded.

All this is already supported by returning Pays::No.

[liamaharon]

• Pallet Call enum can optionally have a feeless conditional.
• Construct Runtime creates a RuntimeSignedExtension that takes OnChargeTransaction.
• In post_dispatch, we check if the current call has a feeless conditional. If so and the condition returns true, the fee is refunded.

All this is already supported by returning Pays::No.

Ah cool. I like this solution better than the one proposed because it doesn't require duplicating params.

I'll wait for confirmation from @gavofyork that this satisfies his requirements before closing the issue.

[liamaharon]

This implementation first takes the fee from the user then refunds it at the end, requiring the account exists.

I wonder if it can be amended so this is not the case?

[kianenigma]

I would take this as an opportunity and rethink how much we leak the concept of transaction payment into pallets.

At the moment, we seem to have one foot in, by allowing pallets to return Pays::No, while we have one foot outside by not enforcing any pallet-transaction-payment to exist in the runtime. If I am not mistaken, if no pallet-transaction-payment (or similar) exists, then Pays::_ is a noop and is totally ignored. I think this is not a great design and is somewhat difficult to explain to others.

I am not sure if something cleaner can be conceptualized, but my gut feeling is that we can do better.

@gupnik do you have a clearer idea of how this is going to work?

[liamaharon]

Moreover, @Ank4n correctly pointed out that Pays::No requires the caller has funds to make the call, and it is refunded at the end so it does not fit the requirements.

Given how the existing syntax is also potentially treacherous based on your comment @kianenigma, perhaps the Pays syntax can be deprecated in favour of this new API. I feel it could be confusing to have both APIs given they both do very similar things.

[bkchr]

Moreover, @Ank4n correctly pointed out that Pays::No requires the caller has funds to make the call, and it is refunded at the end so it does not fit the requirements.

3. In post_dispatch, we check if the current call has a feeless conditional. If so and the condition returns true, the fee is refunded.

You described exactly the same in the OP. If you return it in post_dispatch, it requires that users pay the fees first.

If you want to make a transaction completely fee-less, you can also pass Pays::No to the pre-dispatch weight. However, this is a huge footgun and you will need some custom SignedExtension. I know that you probably want to replace this custom SignedExtension with feeless_if. However, we will then need to document this really good as otherwise you have a nice DOS.

At the moment, we seem to have one foot in, by allowing pallets to return Pays::No, while we have one foot outside by not enforcing any pallet-transaction-payment to exist in the runtime. If I am not mistaken, if no pallet-transaction-payment (or similar) exists, then Pays::_ is a noop and is totally ignored. I think this is not a great design and is somewhat difficult to explain to others.

I mean giving the programmer the possibility to make the transaction pay back the fees, sounds not that unreasonable. I mean we could probably support this from the runtime level. Shouldn't be that hard. But in general the concept of paying fees isn't such a weird concept in blockchains, that we could not have this included "deep in the system". That the logic higher in the stack then decides on the actual payment also sounds reasonable to me.

[xlc]

Can we have some use cases? It is hard to make helpful comments without a context.
I really don't like this syntax. It is not IDE friendly.
We can already achieve this with existing constructs, so this is just a syntax sugar. Again, what are the expected usages to justify the work and the new syntax overhead?

[gupnik]

If you want to make a transaction completely fee-less, you can also pass Pays::No to the pre-dispatch weight. However, this is a huge footgun and you will need some custom SignedExtension. I know that you probably want to replace this custom SignedExtension with feeless_if. However, we will then need to document this really good as otherwise you have a nice DOS.

Thanks, this provides a bit more clarity, but I am still trying to understand how this will play with the existing signed extensions like ChargeTransactionPayment or ChargeAssetTxPayment.

One way could be to actually start using Pays::No in pre-dispatch weight (as you suggested) so that these extensions do not try to deduct any fees. In that case, the new signed extension would entirely be responsible for deducting the fees if the conditions are not met. IIUC, this is why you mentioned that this can be a huge footgun.

The second would be to modify these extensions themselves or make the new one as a wrapper that first validates the conditions and chooses to delegate to these extensions if needed. This seems to add more coupling though, which might not be desirable.

@gupnik do you have a clearer idea of how this is going to work?

I am still trying out a few approaches, but unable to nail it down yet. Please let me know if you have some thoughts on the two mentioned above.

We can already achieve this with existing constructs, so this is just a syntax sugar.

If my understanding as stated above is correct, the current constructs would need to be modified and duplicated heavily if someone wants to achieve this. Is there an easier way that I am missing out?

[kianenigma]

I mean giving the programmer the possibility to make the transaction pay back the fees, sounds not that unreasonable. I mean we could probably support this from the runtime level. Shouldn't be that hard. But in general the concept of paying fees isn't such a weird concept in blockchains, that we could not have this included "deep in the system". That the logic higher in the stack then decides on the actual payment also sounds reasonable to me.

The direction that I am thinking is that things like Pays and PostDispatchInfo should not be random types that you use and hope someone higher in the stack uses them, but instead should be done through, for example, type TransactionPayment: TransactionPayment that is coming from system. trait TransactionPayment would standardize what operations you can do with respect to payment, such as Pays etc. If type TransactionPayment = () all of this is set to noop.

This is functionally the same as what we have now, but I find a better grounding to then build more things on top of.

[xlc]

I would just use unsigned transactions, which doesn’t pay fees. But I need more context to known if this is the right solution. Otherwise we could modify transaction payment pallet to skip deduct fees for some calls as well.

[bkchr]

The direction that I am thinking is that things like Pays and PostDispatchInfo should not be random types that you use and hope someone higher in the stack uses them, but instead should be done through, for example, type TransactionPayment: TransactionPayment that is coming from system. ``

I don't really get what you want to achieve here. As @xlc said, could you please provide a proper example on what you want to have this look like.