Assets/ForeignAssets tests and fixes

[bkontur]

• how to setup Deposits (AssetDeposit, ExistentialDeposit), admin/owner + initial balance for ForeignCreator?
• cannot call Transact([create, set_metadata]) with xcm origin, because set_metadata uses just ensure_signed()
• fix AssetTransactors with ForeignAssets
• check AssetIdConversionFailedToAssetNotFoundWrapper workaround for ConvertedConcreteId/MatchesFungibles and multiple FungiblesAdapters - [XCM] Multiple FungiblesAdapters support + WeightTrader::buy_weight more accurate error polkadot#6739
• move/refactor tests (as macros maybe?) to test-utils for easily reusability to different runtimes to aviod copy/paste
• move tests/stuff related to the UniversalAliases to the PR: Transfer asset via bridge #2013

[bkontur]

bot rebase

[paritytech-processbot]

Rebased

[bkontur]

bot rebase

[paritytech-processbot]

Rebased

[xlc]

Not sure this is the best place to ask but I have some questions:

1. Is this going to be permisionless and universal? i.e. support all assets from all parachains without governance on relaychain
2. How to prevent dust issue?
3. Can foreign asset be self-sufficient and eligible for tx payment?
4. How to handle asset metadata?
5. Any high level design docs that may already have answers to my questions?

cc @joepetrowski

[joepetrowski]

1. Yes, you can see the try_origin implementation in the base PR. So e.g. Acala governance will have a successful origin for ACA as well as tokens registered under its governance system.
2. Same as any other asset.
3. Yes. First, via governance referendum making them sufficient. Once DOTswap is working with that I'd like to re-evaluate sufficiency in general. As in, perhaps it is safe to say that anything that can be swapped for DOT to pay fees with on-the-spot is eligible for tx payment.
4. On asset creation, the para origin (i.e., e.g., Acala governance) will be the owner of that asset. It could further control the other privileged accounts, or use set_team to designate a local account with those privileges.
5. Just the discussions on the forum.

[bkontur]

bot rebase

[paritytech-processbot]

Rebased

[joepetrowski]

This might actually be something we want to block in ForeignAssetsConvertedConcreteId as in this context (Statemine) it is actually Equals<ParentLocation>.

[joepetrowski]

And should just be KSM.

[bkontur]

yes, we do that blocking for ForeignAssets:

• local relay chain token is not allowed (means KSM for statemine)
• also Statemine's TrustedBackAssets are not allowed here

https://github.com/paritytech/cumulus/pull/2167/files#diff-c92582ea200acffaa2858161fe6684de752bfd60d6828fc4d4e283116c036c94R59-R74

/// Excludes by default:
/// - parent as relay chain
/// - all local MultiLocations
///
/// `AdditionalMultiLocationExclusionFilter` can customize additional excluded MultiLocations
pub type ForeignAssetsConvertedConcreteId<AdditionalMultiLocationExclusionFilter, Balance> =
	MultiLocationConvertedConcreteId<
		EverythingBut<(
			// Excludes relay/parent chain currency
			Equals<ParentLocation>,
			// Here we rely on fact that something like this works:
			// assert!(MultiLocation::new(1, X1(Parachain(100))).starts_with(&MultiLocation::parent()));
			// assert!(X1(Parachain(100)).starts_with(&Here));
			StartsWith<LocalMultiLocationPattern>,
			// Here we can exclude more stuff or leave it as `()`
			AdditionalMultiLocationExclusionFilter,

[bkontur]

ah, I see, it was copy/paste from westmint, which adds here confusion, I changed that example here.

Anyway, from Statemine perspective MultiLocation { parents: 2, interior: X1(GlobalConsensus(Kusama)) } is not a Statemine/Kusama true KSM, because there is a parent: 2, so it means more like relay chain currency of some different Kusama global consensus.

GlobalConsensus(Kusama) is NetworkId from xcm:v3.
So maybe, we could add additional exclude to ForeignAssetsConvertedConcreteId for these cases: do not even allow any other foreign GlobalConsensus(same_as_local_consensus) where parent > 1.
So, from the Statemine perspective it would mean we only accept only one true GlobalConsensus(Kusama) which is our and we ignore any other GlobalConsensus(Kusama).

I am not sure if any other Kusama will exist, but if does and will be bridged to our Statemine, all assets will end in ForeignAssets.

Hypotetically, problem will come when there will be two more foreign GlobalConsensus(Kusama), so in that case , from Statemine perspective, both will be MultiLocation { parents: 2, interior: X1(GlobalConsensus(Kusama)) } and there is no way to differ between them, that means their assets will be also mixed in ForeignAssets.

So, that makes me thing, that we should really exclude GlobalConsensus(same_as_local_consensus) where parent > 1.

So:
Statemine should exclude GlobalConsensus(Kusama) where parent > 1
Westmint should exclude GlobalConsensus(Westend) where parent > 1
Statemint should exclude GlobalConsensus(Polkadot) where parent > 1

[joepetrowski]

Yeah this seems like a good approach.

so it means more like relay chain currency of some different Kusama global consensus.

NetworkId is an enum in XCM though, so any variants have to be added explicitly there. So yes there could be some other network called "Kusama" in the future, but its disambiguation would need to be handled in a change to that enum.

[bkontur]

here is a simple test that simulates more global consensuses Kusama and how should different consensus reanchor their assets:

                // local asset on different global consensus Kusama
		let my_asset_location = MultiLocation {parents: 0, interior: X2(PalletInstance(1), GeneralIndex(1234))};
		let my_universal_location: InteriorMultiLocation = X2(GlobalConsensus(Kusama), Parachain(2000)).into();

		// our statemine on our global consensus Kusama
		let statemine_as_target = MultiLocation {parents: 2, interior: X2(GlobalConsensus(Kusama), Parachain(1000))};

		// how should my asset look like from foreign statemine perspective
		let mut my_asset_location_for_statemine = my_asset_location.clone();
		my_asset_location_for_statemine.reanchor(&statemine_as_target, my_universal_location).expect("failed");
		println!("{:?}", my_asset_location_for_statemine);

		// our statemint on our global consensus Polkadot
		let statemint_as_target = MultiLocation {parents: 2, interior: X2(GlobalConsensus(Polkadot), Parachain(1000))};

		// how should my asset look like from foreign statemint perspective
		let mut my_asset_location_for_statemint = my_asset_location.clone();
		my_asset_location_for_statemint.reanchor(&statemint_as_target, my_universal_location).expect("failed");
		println!("{:?}", my_asset_location_for_statemint);

and the result is:

// this will come to Statemine
MultiLocation { parents: 1, interior: X3(Parachain(2000), PalletInstance(1), GeneralIndex(1234)) }

// this will come to Statemint
MultiLocation { parents: 2, interior: X4(GlobalConsensus(Kusama), Parachain(2000), PalletInstance(1), GeneralIndex(1234)) }

so in this case, xcm origin will be like:

UniversalOrigin(GlobalConsensus(Kusama)),

but on Statemine, it will be rejected by XcmExecutor

   UniversalOrigin(new_global) => {
				let universal_location = Config::UniversalLocation::get();
				ensure!(universal_location.first() != Some(&new_global), XcmError::InvalidLocation);

so that could mean, that XCM expects only one GlobalConsensus(Kusama) to exist,
that means, if will exist more differnet GlobalConsensus(NetworkId) for the same NetworkId, ForeignAssets does not have a way to distinguish between them

[bkontur]

NetworkId is an enum in XCM though, so any variants have to be added explicitly there. So yes there could be some other network called "Kusama" in the future, but its disambiguation would need to be handled in a change to that enum.

aha, ok, thank you, cool, that explains also my test above

[bkontur]

bot rebase

[paritytech-processbot]

Rebased

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/bridge-hub-questions/2693/2