[suggestion] Eliminate `AssetType` inconsistencies

[Mingela]

Feature request

There are several value types for assets exist:

"AssetValue": {
  "Enum": [
    {
      "tag": "Quantity",
      "discriminant": 0,
      "type": "u32"
    },
    {
      "tag": "BigQuantity",
      "discriminant": 1,
      "type": "u128"
    },
    {
      "tag": "Fixed",
      "discriminant": 2,
      "type": "Fixed"
    },
    {
      "tag": "Store",
      "discriminant": 3,
      "type": "Metadata"
    }
  ]
}

Basically just Numeric and Store.
Although:

• One can Transfer, Mint and Burn assets of type Numeric, but not assets of type Store
• One can SetKetValue and RemoveKeyValue in relation to a Store asset, but not Numeric one
• Once/Infinitely mintability makes little sense since it does not affect Store assets at all
• A Store asset cannot be destroyed, there will be empty metadata container in the end

Motivation

Current situation hardly can show Store and Numeric assets being just a type of the same entity. They feel totally different entities.

I'd support either enabling the same set of instructions to be applicable to any asset with meaningful outcome or make Store asset something different than an asset. In the latter case an adjustment to enable deleting that somehow would be still worth considering.

Who can help?

No response

[nxsaken]

@mversic @Erigara I'd like to work on this and the related tickets: #3924 and #4101.

Also, while working on examples/docs, I struggled to motivate the distinction between registering and minting assets, since minting/setting a key-value pair on a non-existing asset will create it anyway, making Register somewhat redundant and possibly footgun-prone in the permissions department (e.g. having a permission to mint but not register will effectively let me register). I think it makes sense to generally reconsider the data model and make it more explicit and DRY.

IMO, Register should only give the account an ability to hold assets of a certain definition. Mint, Burn, etc. should only increase or decrease the value, returning an error if there is no "wallet" to hold the asset.

[mversic]

@mversic @Erigara I'd like to work on this and the related tickets: #3924 and #4101.

Also, while working on examples/docs, I struggled to motivate the distinction between registering and minting assets, since minting/setting a key-value pair on a non-existing asset will create it anyway, making Register somewhat redundant and possibly footgun-prone in the permissions department (e.g. having a permission to mint but not register will effectively let me register). I think it makes sense to generally reconsider the data model and make it more explicit and DRY.

IMO, Register should only give the account an ability to hold assets of a certain definition. Mint, Burn, etc. should only increase or decrease the value, returning an error if there is no "wallet" to hold the asset.

Either that or remove Register<Asset> since it's anyway already possible to register it via minting it. And what about Transfer<Asset>. Should asset first be registered? IMO it doesn't make sense to first register asset in the case of transfer

[nxsaken]

@mversic I think both are valid depending on our goals. If we want to provide explicit instructions, we should disallow implicit Registers via mints and transfers and ask users to Register an ability to hold an asset explicitly. If we don't want the notion of first being able to hold an asset to acquire it, then we should remove Register and Unregister – but I like that less because having none of the asset would be the same as having zero of it. Some users may want to use the none case to mean that the user does not have a respective wallet yet, and I think we should provide that flexibility.

[Erigara]

Imo it kinda strange to have Register and Unregister for assets, so implicit balance update through Mint, Burn, Transfer should be enough.

[nxsaken]

@Erigara my reasoning is that even though I have an overall user account in FooBank (equivalent to Iroha Account) and, say, KZT (Iroha Asset Definition) and USD money accounts (Iroha Asset), I can't just accept transfers or do cash-ins in EUR without opening a EUR account first. It can be meaningful to have None of the Asset be different than Some(0) or Some(<EmptyMap>). Maybe it's fine to conflate them.

[mversic]

@Erigara my reasoning is that even though I have an overall user account in FooBank (equivalent to Iroha Account) and, say, KZT (Iroha Asset Definition) and USD money accounts (Iroha Asset), I can't just accept transfers or do cash-ins in EUR without opening a EUR account first.

on the other hand I can have a multi-currency account in my bank and be able to receive any payment

[nxsaken]

@mversic but you have to ask for it, it doesn't come with the user account. And multi-currency accounts are in reality just multiple accounts abstracted away into a single one (though depends on your country probably)

[mversic]

Imo it kinda strange to have Register and Unregister for assets, so implicit balance update through Mint, Burn, Transfer should be enough.

I agree, in my opinion Register/Unregister seem semantically dubious and just add more friction for the user

can we also get some insight how other blockchains do it?
some input from @Mingela and @takemiyamakoto would be highly appreciated