XCMP

[4meta5]

What does it do?

Adds XCMP transfer logic. There are three new pallets:

1. hrmp-channels is for proposing, accepting, and closing HRMP channels
2. xtransfer is for cross-chain transfers (tightly coupled with channels)
3. token-factory is a wrapper around the EVM for ERC20 minting/burning

The XCMP handler logic is in xtransfer/src/support.rs in the MultiCurrency implementation of TransactAsset. This is used by the LocalAssetTransactor associated type in the runtime implementation of xcm_executor::config.

This PR also removes:

• parachain-info (to use polkadot version directly instead)
• token-dealer (replaced by pallets listed above)

What important points reviewers should know?

TODO pallet outlines

Is there something left for follow-up PRs?

What alternative implementations were considered?

Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?

paritytech/polkadot#2661

What value does it bring to the blockchain users?

Checklist

• Does it require a purge of the network?
• You bumped the runtime version if there are breaking changes in the runtime ?
• Does it require changes in documentation/tutorials ?

[JoshOrndorff]

I know it says not ready for review, I was just too excited.

[JoshOrndorff]

If you couple to pallet evm, you can use the same mapping that is in its config trait without needing this associated type.

[4meta5]

I found this associated type in pallet_evm

/// Mapping from address to account id.
type AddressMapping: AddressMapping<Self::AccountId>;

but I did not find account id to address, which I think I still need. The direction matters because I need to convert from T::AccountId to H160 (and the pallet doesn't have the T::AccountId assignment at compile time)

[JoshOrndorff]

Just took another quick look. I have some high level questions:

1. What is the key difference between token dealer and token factory? Is there a clear separation of concerns between the two?

2. When a user decides to send a foreign asset (eg ACA) to Moonbeam, what kind of destination address do they specify? I think it should be an H160 account, right?

[4meta5]

TODO:

• polkadot-launch tests

[4meta5]

This PR adds 3 runtime methods in xtransfer for opening, accepting, and closing channels on the relay chain. These channels are what enable HRMP (between parachains).

Each of these methods require the call data as an input for Xcm::Transact because I don't know how to form the call data in the runtime. This Acala demo uses polkadot-js to form the call from the relay chain context, remove the prefix, and then the raw call is used. As of now, we do this and pass the raw call data to our runtime methods, but this is hacky.

There is this PR which includes three new message variants for Xcm to open, accept, and close channels. If these are added, we don't have to use Xcm::Transact, but I have not yet found the polkadot PR to add the messages.

[4meta5]

Current error:

2021-03-25 09:07:00        RPC-CORE: getBlock(hash?: BlockHash): SignedBlock:: createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec<Extrinsic>"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(Call):: Call: failed decoding parachainSystem.setValidationData:: Struct: failed on args: {"data":"SystemInherentData"}:: Number can only safely store up to 53 bits
2021-03-25 09:07:00             DRR: Error: createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec<Extrinsic>"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(Call):: Call: failed decoding parachainSystem.setValidationData:: Struct: failed on args: {"data":"SystemInherentData"}:: Number can only safely store up to 53 bits)

[4meta5]

I'll open smaller ones to get this in piece by piece :'(