Invalid incoming XCMP message data when XCM contains multiple assets and one of them is the relay chain asset

[jiguantong]

Version: polkadot-v0.9.26
StackExchange: https://substrate.stackexchange.com/questions/4929/invalid-incoming-xcmp-message-data

Steps to reproduce:

1. Rockmine submit polkadotXcm.reserveTransferAsset and transfer two assets, one of them is {parents: 1, Here}

assets: XcmVersionedMultiAssets
{
  V1: [
    {
      id: {
        Concrete: {
          parents: 0
          interior: {
            X2: [
              {
                PalletInstance: 50
              }
              {
                GeneralIndex: 9
              }
            ]
          }
        }
      }
      fun: {
        Fungible: 1,000,000,000,000
      }
    }
    {
      id: {
        Concrete: {
          parents: 1
          interior: Here
        }
      }
      fun: {
        Fungible: 1,000,000,000,000
      }
    }
  ]
}

encoded call: 0x1f02010101009120010001010004578647ec6e8e1ca8b91d5b6c4df991e73bcc515b2aedcef31e64db8c69e64d01080000020432052400070010a5d4e800010000070010a5d4e801000000
2. The dest chain can't decode the XCM and no event be deposited.

DEBUG

I debug with local environment rococo-dev & pangolin parachain-dev & statemint-dev, the results show xcmp-queue can't decode the XCM here https://github.com/paritytech/cumulus/blob/polkadot-v0.9.26/pallets/xcmp-queue/src/lib.rs#L640

[bkchr]

CC @KiChjang

[KiChjang]

@jiguantong What happens if you reorder the assets, so that the ../Here asset is first in the list?

[jiguantong]

@jiguantong What happens if you reorder the assets, so that the ../Here asset is first in the list?

encoded call data on rockmine: 0x1f02010101009120010001010004578647ec6e8e1ca8b91d5b6c4df991e73bcc515b2aedcef31e64db8c69e64d0108000100000700e40b54020000020432052400070010a5d4e801000000

I can't send it after reordering.

The console of chrome shows this error:

2022-09-28 22:54:38        RPC-CORE: submitAndWatchExtrinsic(extrinsic: Extrinsic): ExtrinsicStatus:: 1002: Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed
WASM backtrace:

    0: 0x3797d - <unknown>!rust_begin_unwind
    1: 0x3bed - <unknown>!core::panicking::panic_fmt::h18b15be283411c65
    2: 0xe6e6b - <unknown>!TaggedTransactionQueue_validate_transaction
: RuntimeApi, Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\nWASM backtrace:\n\n    0: 0x3797d - <unknown>!rust_begin_unwind\n    1: 0x3bed - <unknown>!core::panicking::panic_fmt::h18b15be283411c65\n

My dev node log is:

2022-09-28 22:47:56.461 ERROR tokio-runtime-worker runtime: panicked at 'Bad input data provided to query_info: Codec error', /home/workspace/polkadot-git/cumulus/parachains/runtimes/assets/statemint/src/lib.rs:672:1
2022-09-28 22:47:57.209 ERROR tokio-runtime-worker runtime: [Parachain] panicked at 'Bad input data provided to validate_transaction: Codec error', /home/workspace/polkadot-git/cumulus/parachains/runtimes/assets/statemint/src/lib.rs:672:1

[KiChjang]

@jiguantong You forgot to change the fee_asset_item parameter to 0, Try again with that changed?

[jiguantong]

@jiguantong You forgot to change the fee_asset_item parameter to 0, Try again with that changed?

0x1f02010101009120010001010004578647ec6e8e1ca8b91d5b6c4df991e73bcc515b2aedcef31e64db8c69e64d0108000100000700e40b54020000020432052400070010a5d4e800000000
I tried it and the error & log are the same as fee_asset_item: 1

[KiChjang]

Could we also ensure that it's the same amount of fungibles? Your issue description has 1 trillion units for both assets, but in your test cases, the ../Here asset is only 10 billion.

[jiguantong]

0x1f02010101009120010001010004578647ec6e8e1ca8b91d5b6c4df991e73bcc515b2aedcef31e64db8c69e64d010800010000070010a5d4e80000020432052400070010a5d4e800000000
Sorry, but the error and log are same.

[KiChjang]

Okay, good so far. We can now safely eliminate the cause being an ordering issue in the MultiAssets struct:

https://github.com/paritytech/polkadot/blob/c620450de80f76e15a735a0d13efe4540d3053a0/xcm/src/v1/multiasset.rs#L289-L294

The code above ensures that we have ordered the assets correctly, which you already have.

This means that the decoding issue stems from a different cause. Do you know what the safe_xcm_version is on the receiving chain?

[jiguantong]

para(2084), polkadotXcm.safeXcmVersion: 2

[KiChjang]

And how about the sending chain as well?

[jiguantong]

Rockmine(1000), polkadotXcm.safeXcmVersion: 2

[jiguantong]

Well, it seems that Rockmine stopped producing blocks due to the above test

[KiChjang]

Ok, so we can't really eliminate the possibility that the decoding issue is due to the ordering of the assets quite just yet, because we don't know if your error arose because the chain stopped producing blocks. I can see that Rockmine had actually stopped producing blocks earlier than the time when I had asked you to try executing the extrinsic again.

Given so, my hunch is still due to the code I referenced here: https://github.com/paritytech/polkadot/blob/c620450de80f76e15a735a0d13efe4540d3053a0/xcm/src/v1/multiasset.rs#L289-L294, i.e. the receiving chain cannot decode it because the asset ordering is wrong. But we'll see once Rockmine starts producing blocks again.

[jiguantong]

After testing it on other chains, I think this is another bug if we reorder the assets, we can track it here: paritytech/polkadot#6074.