New asset system - Separate asset types and add pallet-assets instances to runtime

[sea212]

What does it do?

• It creates new asset types
  • u128 for user created assets and campaign assets
  • MarketAssets that represent any kind of volatile asset that is used during a market lifecycle
• It adds pallet-assets to the runtime
  • One instance as Assets, this is the general instance that anyone can utilize to create new asset classes.
  • One instance as CampaignAssets, this is a permissioned instance that prohibits creation of asset using dispatchable calls. Only code, root, 2/3 council or all tech committee can trigger the creation of a new campaign assets. Campaign assets are special in that they are sufficient to create accounts and can be used to pay fees (to be implemented)
  • One instance as MarketAssets, this is a permissioned instance that prohibits creation of asset using dispatchable calls. Only code, root or 2/3 tech committee can trigger the creation of a new asset, such as MarketAsset::CategoricalOutcome(0,0)
• It adds custom pallet-assets weights and add pallet-assets to the benchmarking scripts

What important points should reviewers know?

• RemoveItemsLimit could not be properly configured yet, see Properly configure pallet-assets RemoveItemsLimit #1176

Is there something left for follow-up PRs?

• Properly configure pallet-assets RemoveItemsLimit #1176
• This is part 1 of multipe PRs that complete the new asset system. Logic that is still missing:
  • Make existing pallets use the new asset system.
  • Lazy migrate existing market assets: Pallets will continue using orml-tokens for existing market until all those existing market assets expired. Reason: Too many accounts hold existing market assets, migrating will be expensive and cannot be executed atomatically. During migration, the storage trie that hold old market asset information will most likely be manipulated by user interaction.
  • Abstract ordinary token functions like transferring, reserving/freezing, etc. in AssetManager.
  • Paying fees using CampaignAssets.
  • Using Assets and CampaignAssets as base assets in prediction markets.
  • Properly creating and destroying MarketAssets in pallets such as prediction markets.
  • Adjust Asset types in many pallets, such as xcm related pallets (should only allow ZTG and ForeignAsset(id) for now), orml-tokens, etc.
  • Future: Remove outcome asset classes from the old asset structure once all associated outcome tokens expired.

What alternative implementations were considered?

• Using one asset class enum and one pallet instance for pallet-instance with a CreateOrigin that knows which origins can create which asset class. Using instances instead seemed like a cleaner approach that logically separates asset classes with different purposes and restrictions.

Are there relevant PRs or issues?

References

[codecov-commenter]

Codecov Report

Attention: 7 lines in your changes are missing coverage. Please review.

Comparison is base (76d6a23) 93.47% compared to head (e7c912c) 93.45%.

Files	Patch %	Lines
primitives/src/asset.rs	0.00%	7 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@                     Coverage Diff                     @@
##           sea212-new-asset-system    #1177      +/-   ##
===========================================================
- Coverage                    93.47%   93.45%   -0.02%     
===========================================================
  Files                          121      121              
  Lines                        34264    34271       +7     
===========================================================
  Hits                         32028    32028              
- Misses                        2236     2243       +7     

Flag	Coverage Δ
tests	93.45% <0.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maltekliemann]

I think we should use the same ForceOrigin for all pallets. The distinction between Council and Tech Comm isn't there right now anyways.

[sea212]

I disagree for the following reasons:

1. The CampaignAsset class is much more powerful, as it allows to spawn assets that can be used to pay transaction fees. Thus it should require at least higher privileges than other asset classes to be created.
2. There are distinctions:
   a. While other asset classes use the ForceOrigin solely to technically correct faults, the CampaignAsset class uses the ForceOrigin to realize business decisions (pushing into directions by utilizing campaigns)
   b. The Council is different from the Technical Committee (TC), even on Zeitgeist. In contrast to the TC, the Council contains all members of the executive. Currently the Council consists of 5 members, with an required agreement from the Council of at least 2/3 to spawn campaign assets, at least two members of the executive have to agree, thus also mapping agreement within the executive of Zeitgeist to move forward with campaigns.

I decided to add the TC to allow assistance in regards to technical aspects, such as cleaning up campaign assets after a campaign is over. However, I think granting the (complete) TC the ForceOrigin power invalidates my second argument. I am leaning towards removing the TC completely from the ForceOrigin of the CampaignAsset class. What's your opinion?

This makes me think about point 1. though. The MarketAssets have the ForceOrigin TwoThirdsOrTechnicalCommittee. Obviously MarketAssets have an even more tangible value. MarketAssets should never be managed directly as the pallets control the whole lifecycle of market assets such as outcome tokens or pool shares. I added this because I wanted to give the TC the opportunity to hotfix some inconsistent states introduced by pallets. Thinking more about it though, I think the TC should not have the power to manage market assets. What's your opinion?

Makes me also question right now if it makes sense at all to add the TC to any ForceOrigin, including CustomAssets. After all, with the help of the Council the TC is capable of spawning a referendum with a short period until dispatch.

[maltekliemann]

I'm okay with all of these options. As long as there are no elections, I don't see any difference between the Council and TC. In the long run (assuming elections take place), I'd prefer if the TC did not have control over market assets. This is based on the assumption that until then, all bugs will have been fixed or can be fixed by governance rather than TC intervention.

[sea212]

Does it make more sense like this: a86c36a

Idea: Still convinced about at least 2/3 Council for CampaignAssets, full tech committee for MarketAssets (due to the potential impact) and 2/3 technical committee for CustomAssets.

[maltekliemann]

Suggested change

	pub enum PredictionMarketAsset<MI: MaxEncodedLen> {
	pub enum PredictionMarketAsset<MI> {

Not sure if that's a good idea, but I don't think we need this requirement here.

[maltekliemann]

I guess it's for convenience?

[sea212]

We will need that for MaxEncodedLen implementation for the Pool struct.

[maltekliemann]

Ok, I think we can get rid of this after merging #1197