Discussion: Extend GlobalConsensus junction to include a Bridge ID

[vgeddes]

The GlobalConsensus junction signifies that a network is capable of externalizing its consensus system to other global consensus systems. However, I believe there is a piece of information missing. This externalization is always mediated via a bridge between the two consensus systems. Without a bridge, the externalization could not occur.

I propose for XCMv4 that we extend the GlobalConsensus junction to include the ID of the bridge:

GlobalConsensus(NetworkId, BridgeId)

I believe this change improves the semantics of XCM MultiLocations when it comes to identifying bridged assets on Polkadot.

Consider the following scenario with the existing XCMv3 language. We can represent the location of the ERC20 DAI token relative to Polkadot using the following notation:

/GlobalConsensus(Ethereum)/AccountKey20(DAI)

Suppose two different bridges want to transfer DAI to Statemint. There will be a clash, as they would both like to use /GlobalConsensus(Ethereum)/AccountKey20(DAI) identify their assets within the Polkadot.

To work around this, they could add an extra "dummy" junction like GeneralIndex or AccountKey20 to disambiguate:

/GlobalConsensus(Ethereum)/AccountKey20(SomeBridgeSpecificContract)/AccountKey20(DAI)

However, this does not really reflect Ethereum's consensus hierarchy all that well, as Ethereum doesn't have nested contracts. DAI is not really contained within SomeBridgeSpecificContract. So I feel it would be better to include the bridge id within the GlobalConsensus junction.

[KiChjang]

Could you explain what problems there are for clashing? I actually don't believe that there is a clash; in fact, it's working as intended when 2 MultiLocations are pointing to the same location -- it just means that they're representing the same asset, which is exactly the case here.

What you seem to be indicating is that the reserve assets on the 2 different bridge contracts are not the same, which is a completely separate problem, and can be solved by simply using separate MultiLocations for each of them, as they are in fact not the same asset.

[vgeddes]

What you seem to be indicating is that the reserve assets on the 2 different bridge contracts are not the same, which is a completely separate problem, and can be solved by simply using separate MultiLocations for each of them, as they are in fact not the same asset.

This makes good sense, come to think of it We shouldn't be using /GlobalConsensus(Ethereum)/AccountKey20(DAI) to represent bridged DAI on Statemine, because bridged DAI is really a derivative asset, backed by real DAI locked up in a vault in ethereum.

[vgeddes]

What you seem to be indicating is that the reserve assets on the 2 different bridge contracts are not the same, which is a completely separate problem, and can be solved by simply using separate MultiLocations for each of them, as they are in fact not the same asset.

I've changed my mind on this.

Actually the two different bridge contracts on Ethereum both hold the same DAI token in reserve. They are the same asset. In fact the way its implemented in Ethereum is that the DAI contract itself is actually the consensus system that holds the reserves. It has an internal ledger that says an account for Bridge X has so many tokens in reserve, and and and account for Bridge Y has so many tokens in reserve.

However synthetic assets on AssetHub derived from these foreign reserves are not fungible with each other. That said, its still convenient and useful to be able to identify the synthetic assets using the contract address of the foreign token.

The alternative is to just identify the synthetic asset using a location of the form /Para(AssetHub)/PalletIndex(X)/GeneralIndex(Y), where Y is some randomly allocated asset ID. But then we've lost the discoverability aspect, compared to /GlobalConsensus(Ethereum)/AccountKey20(DAI)

Adding a BridgeID allows to discriminate between synthetic assets derived from the same foreign token, while maintaining the discoverability aspect.