Support different assets for delivery fees

[franciscoaguirre]

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 can only be paid in one asset. The idea is to fix this by providing an AssetConverter that's able to turn the asset the user wants to pay fees in into the asset the router expects for delivery fees.

Paying delivery fees in USDT instead of WND on Westend Asset Hub (uses min_balance ratio since it's sufficient):

Main addition

A new xcm executor config item is introduced: AssetConverter, that can convert balances from one asset to another. It's used for paying delivery fees in different assets other than the native one (the one specified in the XcmRouter).

How it works

In order to pay delivery fees with different assets, you need to add some type as the AssetConverter in your XCM executor. Right now, the AssetConverter approach will only work for delivery fees, for execution fees, you need to copy the same logic onto a Trader. The logic is mostly the same, only the interface changes. The Trader has to do a little bit more work. This duplicated logic is planned to be removed in v5, when we have the same mechanism for both execution and delivery fees.

The following asset hub westend integration tests show scenarios where this is used:

• [x] Sufficient trust backed assets
  • [x] Reserve asset transfer from system para to para
  • [x] Reserve asset transfer from para to para through system para
• [ ] Sufficient foreign assets
  • [x] Reserve asset transfer from system para to para
  • [ ] Reserve asset transfer from para to para through system para
• [ ] Pool assets
  • [ ] Reserve asset transfer from system para to para
  • [ ] Reserve asset transfer from para to para through system para

Breaking changes

This PR breaks the following things:

• New AssetConverter needs to be set in the executor config, even if it's just ().
• XcmExecutor::charge_fees signature changed.
• Pending changes to the executor to allow setting the desired asset to pay for fees.

Dear reviewer

TODO

[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[bot]]

Here's a link to docs

[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 https://github.com/paritytech/polkadot-sdk/pull/5130 and https://github.com/paritytech/polkadot-sdk/pull/5131