What is the difference between `GlobalConsensus` (tuple struct with NetworkId) and `NetworkId` (be used via AccountId32) in XCM `MultiLocation`?

Question

XCM version: 3

I'm learing XCM. I want to specify a Polkadot account by MultiLocation when within a parachain on Polkadot like Statemint, I know it can be specified with ParentThen(X1(AccountId32)).into.

But are the other two ways below correct? What is the difference between the three of them?

Option 1: Use NetworkId to sepcify Polkadot in GlobalConsensus.

MultiLocation { 
   parents: 0,
   interior: X2(GlobalConsensus(Polkadot), AccountId32 { network: None, id: [...] }) 
}

Option 2: Use NetworkId to specify Polkadot in AccountId32.

MultiLocation {
   parents: 0,
   interior: X1(AccountId32 { network: Some(Polkadot), id: [...] }) 
}

I know this question may be similar to another , but the focus of that question may be Ethereum, here I want to know what is the difference between these two ways of specifying NetworkId and when should I use which?

Answer 1

Let's look at these three MultiLocation values, assuming we have a 32-byte account ID id:

1. (Parent, AccountId32 { network: None, id }).into()

This is more idiomatic, but otherwise exactly equal to the first suggestion you made:

ParentThen(X1(AccountId32 { network: None, id })).into()

It means "the 32-byte account of identity id as interpreted within the context of the parent's consensus system", with an extra note that id (i.e. that 32-byte value) should not be considered associated with a particular network.

An example of using this would be when referring to a Relay-chain account from within a parachain's logic. The Parent would take it "up" into the Relay-chain location and then the AccountId32 would bring it "down" into an account on it.

2. (Polkadot, AccountId32 { network: None, id }).into()

This is more idiomatic, but otherwise exactly equal to the second suggestion you made:

MultiLocation {
  parents: 0,
  interior: X2(
    GlobalConsensus(Polkadot),
    AccountId32 { network: None, id }
  )
}

It means "the 32-byte account of identity id as interpreted within the context of the Polkadot network which itself should be found within the local consensus system", with an extra note that id (i.e. that 32-byte value) should not be considered associated with a particular network.

Since no real consensus system contains the Polkadot network, this location doesn't make any sense.

The corresponding value of type InteriorMultiLocation is:

MultiLocation::from((Polkadot, AccountId32 { network: None, id }))

This does have a meaning: being an InteriorMultiLocation it never contains Parents and thus is used to represent Universal locations, i.e. locations to be interpreted within the hypothetical Universal Consensus defined as the parent of all top-level consensus systems.

Used in this way, the value would refer to the account id on the Polkadot Relay-chain, much like in the example for (1).

3. AccountId32 { network: Some(Polkadot), id }.into()

This is more idiomatic, but otherwise exactly equal to the third suggestion you made:

MultiLocation {
  parents: 0,
  interior: X1(
    AccountId32 { network: Some(Polkadot), id }
  )
}

This means "the 32-byte account of identity id as interpreted within the context of the local consensus system", with an extra note that id (i.e. that 32-byte value) should be considered strictly associated with the Polkadot network, as opposed to e.g. Kusama.

In general, specifying the network in an AccountId32 is not done since there is rarely a need to make a strict association between a particular account and a network. Generally an account is considered "compatible" if the public key (i.e. id) is the same length as account IDs on the local chain.

Answer 2

Let's take a look at the docs on GlobalConsensus:

/// A global network capable of externalizing its own consensus. This is not generally
/// meaningful outside of the universal level.

The only chance where a MultiLocation mentions something that is "at the universal level" would be bridges, hence outside of the application of bridges, we don't really use the GlobalConsensus junction all that much. So if the XCM in question originates from Kusama and attempts to send an XCM over to Polkadot via a bridge, then I would expect to see a GlobalConsensus junction, in order to instruct the bridge to relay it to the correct destination.

However, in most cases, the MultiLocation is referring to a location that is local, i.e. it does not exist outside of the local consensus system and doesn't require reaching out to the universal consensus level, and so most of the time, one does not even need to specify exactly which NetworkId to use in the id field of AccountId32 -- a simple None would already suffice (though it would still work if Polkadot is specified, provided that the local consensus system is indeed Polkadot). Note also that the account ID is not an SS58 address, and so no matter which parachain your source or destination is, the account ID would still stay the same, as an SS58 address can always be derived from an AccountId32.