XCM Fee Payment Runtime API

[PraetorP]

The PR provides API for obtaining:

• the weight required to execute an XCM message,
• a list of acceptable AssetIds for message execution payment,
• the cost of the weight in the specified acceptable AssetId.

It is meant to address an issue where one has to guess how much fee to pay for execution. Also, at the moment, a client has to guess which assets are acceptable for fee execution payment.
See the related issue #690.
With this API, a client is supposed to query the list of the supported asset IDs (in the XCM version format the client understands), weigh the XCM program the client wants to execute and convert the weight into one of the acceptable assets. Note that the client is supposed to know what program will be executed on what chains. However, having a small companion JS library for the pallet-xcm and xtokens should be enough to determine what XCM programs will be executed and where (since these pallets compose a known small set of programs).

pub trait XcmPaymentApi<Call>
	where
		Call: Codec,
	{
		/// Returns a list of acceptable payment assets.
		///
		/// # Arguments
		///
		/// * `xcm_version`: Version.
		fn query_acceptable_payment_assets(xcm_version: Version) -> Result<Vec<VersionedAssetId>, Error>;
		/// Returns a weight needed to execute a XCM.
		///
		/// # Arguments
		///
		/// * `message`: `VersionedXcm`.
		fn query_xcm_weight(message: VersionedXcm<Call>) -> Result<Weight, Error>;
		/// Converts a weight into a fee for the specified `AssetId`.
		///
		/// # Arguments
		///
		/// * `weight`: convertible `Weight`.
		/// * `asset`: `VersionedAssetId`.
		fn query_weight_to_asset_fee(weight: Weight, asset: VersionedAssetId) -> Result<u128, Error>;
		/// Get delivery fees for sending a specific `message` to a `destination`.
		/// These always come in a specific asset, defined by the chain.
		///
		/// # Arguments
		/// * `message`: The message that'll be sent, necessary because most delivery fees are based on the
		///   size of the message.
		/// * `destination`: The destination to send the message to. Different destinations may use
		///   different senders that charge different fees.
		fn query_delivery_fees(destination: VersionedLocation, message: VersionedXcm<()>) -> Result<VersionedAssets, Error>;
	}

An example of a client side code.

[mrshiposha]

Hi @franciscoaguirre, it is the PR we spoke of yesterday :)

[franciscoaguirre]

@mrshiposha Awesome! I'd like to add this comment about how we should also have a way of estimating delivery fees.
To better integrate them, I think a single API call should provide given the XCM program, both the execution and delivery fees.
How that looks like depends, right now delivery fees are only paid in a specific asset (at least per router, like a bridge), while execution fees work as you describe, first weight and then acceptable assets to buy that weight.
Probably something like:

/// Given a message, returns the execution `Weight` and the delivery fees needed to be paid.
/// The execution weight can be converted to fees by using `query_acceptable_payment_assets` and `query_weight_to_asset_fee`.
fn query_xcm_fees(message: VersionedXcm<Call>) -> Result<(Weight, Assets), Error>;

Alternatively, we could have it return just Assets but that removes the ability to pay in a different fee.
Unless we return a vector of options, but that might be too much work for a single API call.

We could also keep this call for execution weight and have a separate API call for delivery fees.
The thing is, everyone would need to use both in order to estimate fees as accurately as possible, so we might as well just make them one call.

What do you think?

Also, I'm adding @xlc and @acatangiu to this conversation.

[mrshiposha]

A reply to #3607 (comment).

We haven't considered the delivery fee thing yet, but yeah, it should be covered somehow.
Give us some time to consider it so we can better understand the trade-offs related to the delivery fee.

We opened the PR in its current state to have a basis for further discussion, including the solution for the delivery fee

[acatangiu]

We opened the PR in its current state to have a basis for further discussion, including the solution for the delivery fee

This is great!

We haven't considered the delivery fee thing yet, but yeah, it should be covered somehow.
Give us some time to consider it so we can better understand the trade-offs related to the delivery fee.

I think the currently proposed XcmPaymentApi runtime api is good, like Cisco says, should also have a fn to expose the configured delivery fee mechanism (e.g. rococo config). IMO it can simply re-expose fn price_for_delivery() trait implementor.

(do ☝️ in this PR)

---

(👇 follow-up/different PR(s))

For the full fees story (like proposed in #690 (comment)), and providing users/builders/dapps with a nice UX, we will probably add specialized query_* runtime APIs for pallets like pallet-xcm and xtokens.
E.g. fn query_fees_for_transfer_assets(assets, dest, beneficiary) which will make use of underlying XcmPaymentApi to provide consolidated fees required, with single call.

[franciscoaguirre]

IMO it can simply re-expose fn price_for_delivery() trait implementor.

I think this is a good first thing to add. But I think we could add an API that given a message, it'll give you the delivery fees needed to execute that message. So it dry-runs it to find all messages that need to be sent and to which destinations, and returns the resulting total fees.

[franciscoaguirre]

Clarifying my previous comment. I think we should start simple. There are many complicated things we could do like the thing I described about dry-running, but those would be slow to review and merge. This API looks perfect for what we need right now, which is exposing runtime functions we don't expose currently. After we merge this we can build on top of it.

Basically what Adrian said 😄

[franciscoaguirre]

I added the new function exposing delivery fees in UniqueNetwork#3

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/parity-tech-update-for-march/7226/1