Support different assets for delivery fees

[franciscoaguirre]

Separated the PR in two: #5130 and #5131

Context

Fees can already be paid in other assets locally thanks to the Trader implementations we have.
This doesn't work when sending messages because delivery fees go through a different mechanism alltogether.
The idea is to fix this leveraging the AssetExchanger config item that's able to turn the asset the user wants to pay fees in into the asset the router expects for delivery fees.

Main addition

An adapter for AssetExchanger to work with pallet-asset-conversion was added to xcm-builder: FungiblesPoolAdapter.
This was set as AssetExchanger in the XCM configuration of both asset-hub-rococo and asset-hub-westend.

The XCM executor was modified to use this exchanger to swap assets to pay for delivery fees.

How it works

In order to pay delivery fees with different assets, you need to add some type as the AssetExchanger in your XCM executor.
The new adapter, FungiblesPoolAdapter, allows an easy interface to connect with anything that implements the SwapCredit and QuoteExchangePrice traits. Currently, they are implemented by pallet-asset-conversion.

Limitations

We can only pay for delivery fees in different assets in intermediate hops. We can't pay in different assets locally. The first hop will always need the native token of the chain (or whatever is specified in the XcmRouter).
This is a byproduct of using the BuyExecution instruction to know which asset should be used for fee payment.
Since this instruction is not present when executing an XCM locally, we are left with this limitation.
To illustrate this limitation, I'll show two scenarios, all chains have pools.

Scenario 1

Parachain A --> Parachain B

Here, parachain A can use any asset in a pool with its native asset to pay for local execution fees.
However, as of now we can't use those for local delivery fees.
This means transfers from A to B need some amount of A's native token to pay for delivery fees.

Scenario 2

Parachain A --> Parachain C --> Parachain B

Here, Parachain C's remote delivery fees can be paid with any asset in a pool with its native asset.
This allows a reserve asset transfer between A and B with C as the reserve to only need A's native token at the starting hop.
After that, it could all be pool assets.

Future work

The fact that delivery fees go through a totally different mechanism results in a lot of bugs and pain points.
Unfortunately, this is not so easy to solve in a backwards compatible manner.
Delivery fees will be integrated into the language in future XCM versions, following this RFC.

Dear reviewer

• Most of the changes are in the XCM executor: polkadot/xcm/xcm-executor/src/lib.rs.
• The new adapter is in polkadot/xcm/xcm-builder/src/asset_exchange.rs.
• The asset hub runtimes have been updated with a new PoolAssetsExchanger type:
  • Westend: cumulus/parachains/runtimes/assets/asset-hub-westend/src/xcm_config.rs
  • Rococo: cumulus/parachains/runtimes/assets/asset-hub-rococo/src/xcm_config.rs
• The tests live in cumulus/parachains/integration-tests/emulated/tests/assets/asset-hub-westend/src/tests/reserve_transfer.rs

[Polkadot-Forum]

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

https://forum.polkadot.network/t/xcm-user-and-developer-experience-improvements/4511/21

[command-bot]

Here's a link to docs

[muharem]

What if we disable the FeeManager for our runtime setups and try to account a transport weights in Weigher. Even if we cannot do it properly, may be some reasonable constants would be enough.
For local execution the transport fee will be included in extrinsics' weights, and for the remote execution a user will pay with BuyExecution for transport fee as well.
To avoid a double payment with jit_withdraw fee mode, we will need to disable it via config (here we also can provide some info for dependent teams).

After reading the weights payment model in the xcm pallet and the executor, I do not see a good way to make it work with various assets through the FeeManager without breaking the APIs. With the new xcm version we can have a better solution.

[yrong]

@franciscoaguirre Cool, thanks for the effort!

One question for the use case transfering WETH from AH back to Ethereum(AH --> BH --> Ethereum), currently the delivery fee is configured on AH here in native token(i.e. DOT).

So with this PR is that possible to config it in WETH while still allow end user to pay in DOT?

We can only pay for delivery fees in different assets in intermediate hops

Does your comment above means it's not possible?

[franciscoaguirre]

@yrong Given how the bridge works, BridgeHub doesn't charge the delivery fee, AssetHub does. This means it wouldn't work because of the limitation unfortunately

[yrong]

Given how the bridge works, BridgeHub doesn't charge the delivery fee, AssetHub does. This means it wouldn't work because of the limitation unfortunately

No worry. In our new design won't need a static delivery fee config anymore, as Adrian suggested we will use the low level pallet-xcm::execute for a custom xcm(e.g. including the ExchangeAsset for the internal swap).

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable 1/3
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6765227

[franciscoaguirre]

Closing in favor of #5130 and #5131