Foreign assets creation via token reserve

[gonzamontiel]

What does it do?

• Introduces a new origin ForeignAssetOwnerOrigin. It validates that the origin is an XCM location, that contains another location. This is useful to validate that a parachain can create or modify an asset only if it contains the asset. It's based on an implementation of xcm_simulator.
• The allowed XCM origins are defined by LocationToAccountId
• The above origin affects all extrinsics inside the moonbeam foreign assets pallet
• create_foreign_asset now reserves a deposit from the caller (i.e. parachain sovereign accounts)
• The deposit amount is configurable (ForeignAssetCreationDeposit) and can be changed with pallet_parameters
• A new storage maps the asset creator, and the amount reserved at creation, by asset id. The creator is an enum that allows to be Governance (for old or migrated assets), and any account for new assets.

⚠️ Breaking Changes ⚠️

• The extrinsics create_foreign_asset, change_xcm_location, freeze_foreign_asset, unfreeze_foreign_asset can only be called by a Parachain Location origin (through XCM) or Governance
• The parachain teams are required a deposit of funds that is configurable in the pallet.
• The deposit will be taken from the sovereign account of the caller of create_foreign_asset
• The initial deposit values are:
  • Moonbase: 100 DEV
  • Moonriver: 1000 MOVR
  • Moonbeam: 10000 GLMR

Disclaimer: the pallet is not in use and the functionality wasn't exposed publicly AFAIK. The changes are still breaking, but most likely harmless.

TODO

• Make deposit amount configurable (and changable with pallet parameters)
• Modify foreign assets migration to add the old assets to the new storage
• Add tests

What important points reviewers should know?

Some assumptions were made considering the current state of the pallet:

• There are no foreign assets yet created in live chains
• The AssetOwner was meant initially to be a descriptive enum of the possible sources of creation of an asset, but since there were no assets yet created, we only need to distinguish between migrated assets, and the ones created from now on (any account). Naming in this enum might be improved.
• The Foreign assets migration was modified to mark the migrated assets in the storage and distinguish them from the newly created ones.

Is there something left for follow-up PRs?

What alternative implementations were considered?

Using Fungibles was investigated, but the implementation uses ReservableCurrency, following the same pattern as pallet assets.

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

We should run the migration added here #3020 after this PR is merged.

What value does it bring to the blockchain users?

It should be easier for Parachain teams to register their assets natively in Moonbeam

[github-actions]

WASM runtime size check:

Compared to target branch

Moonbase runtime: 2424 KB (+4 KB) 🚨

Moonbeam runtime: 2380 KB (-24 KB) ✅

Moonriver runtime: 2392 KB (-8 KB) ✅

Compared to latest release (runtime-3401)

Moonbase runtime: 2424 KB (+392 KB compared to latest release) 🚨

Moonbeam runtime: 2380 KB (+368 KB compared to latest release) ⚠️

Moonriver runtime: 2392 KB (+380 KB compared to latest release) ⚠️

[gonzamontiel]

I didn't follow the whole code, but how do we know here that the original Origin is indeed some type of Governance ?
What I mean is, I think we are coupling this enum which belongs to the pallet, to the configuration of the pallet. If we or someone configures the ForeignAssetCreatorOrigin to be Signed, then this would be marked as Governance, am I right ?

[TarekkMA]

MapSuccessToGovernance and MapSuccessToXcm are just some utility classes that will help converting the Success type of EnsureSigned, EnsureXcm, EnsureRoot, etc to be one of two types of OriginType.

You still have to provide what is considered Governance and what's considered Xcm, for example in mocks.rs I use MapSuccessToGovernance<EnsureRoot> this will consider root as governance.

[gonzamontiel]

Okay I follow now, we need to be careful because the constraint comes from the Success type in the definition of MapSuccessToGovernance and MapSuccessToXcm.

[gonzamontiel]

I really like the changes now. I left some comments regarding how we constrain the ForeignAsset*Origin types in the config, so we only allow some type of governance and some type of XCM. The implementation is smart, but is relying in the Success type of the origin. This wouldn't mean it is a security issue, because we are the ones configuring the pallet correctly, but it could potentially be misconfigured.

[gonzamontiel]

Okay I follow now, we need to be careful because the constraint comes from the Success type in the definition of MapSuccessToGovernance and MapSuccessToXcm.

[gonzamontiel]

Implicitly, here it is assumed that having and empty tuple as the Success type, means the Origin comes from either Root or Governance, because no account is associated to the origin. While this is true in most cases, it is not strict (we could have a custom Signed origin that returns and empty tuple, and it would be considered Governance)

[gonzamontiel]

Same as above, here it is a assumed that having a Location as Success type means that the Origin comes from XCM. In this case I would say is better than the other, because a Location type already indicates some relationship with an XCM origin.