Place of assets in Iroha model

Nikita Puzankov, [13.05.20 15:25]
[ Photo ]
Hi team - I pushed code that compiles (with tests) https://github.com/hyperledger/iroha/pull/499 and going to fix tests before making code "clean" - but the main idea already can be checked in iroha_clien tests - like transfer asset:
as you can see, Instructions are not coupled with their parameters

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [13.05.20 17:13]
[In reply to Nikita Puzankov]
Generally you are right, but it is a little more complicated than this. Assets modifications should be in accordance with permissions. Some users could in theory be able to create new assets, whereas others are allowed to not create, but transfer. Permissions can be granted, so it is not necessarily the same people who have create permission that were the initial account that registered.

Nikita Puzankov, [13.05.20 17:31]
[In reply to Makoto Takemiya 武宮誠 (Sora.org - Soramitsu)]
why can’t we lock permissions on assets names and store assets under accounts?

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [13.05.20 17:46]
Not sure what you mean

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [13.05.20 17:47]
What I mean is there is no asset "owner." Accounts have assets and they have permissions about what they can do with those assets

Nikita Puzankov, [13.05.20 18:11]
[In reply to Makoto Takemiya 武宮誠 (Sora.org - Soramitsu)]
So instead of transferring assets, they transfer permissions?

Nikita Puzankov, [13.05.20 18:12]
For example there is XOR asset with quantity 20. My account is the only one with permissions to use them. If I want to "give" 2 XOR to another account, I reduce the quantity in my permission to 18 and grant permission with quantity 2 to another account?

Nikita Puzankov, [13.05.20 19:12]
right now in paper we have no connection between accounts and assets, in impl we have assets in both - domains and account:
WorldStateView { peer: Peer { peers: {}, listen_address: "127.0.0.1:1338", domains: {"domain": Domain { name: "domain", accounts: {Id { entity_name: "account", domain_name: "domain" }: Account { id: Id { entity_name: "account", domain_name: "domain" }, assets: {}, signatories: [[101, 170, 80, 164, 103, 38, 73, 61, 223, 133, 83, 139, 247, 77, 176, 84, 117, 15, 22, 28, 155, 125, 80, 226, 40, 26, 61, 248, 40, 159, 58, 53]] }}, assets: {Id { entity_name: "xor", domain_name: "domain" }: Asset { id: Id { entity_name: "xor", domain_name: "domain" }, quantity: 200 }} }} } },

Nikita Puzankov, [13.05.20 19:12]
and to fix tests rights we need to define the place assets belongs to. let's skip permissions part and solve this task first.

Nikita Puzankov, [13.05.20 19:29]
https://wiki.hyperledger.org/display/iroha/Place+of+assets+in+Iroha+model I made a small RFC about this question

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 05:43]
[In reply to Nikita Puzankov]
It's correct from a philosophical standpoint, but not a very practical way to look at it. It's like giving you a 50 ruble note gives you permission to go spend it.

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 05:55]
What I mean is there are robust permissions that we need. For example, only designated accounts should be able to add to the quantity, some accounts (like a bank) need to be able to change signatories of another anount (like a bank's customer). For queries, some users may be able to query their own or their own domain's transactions, but not other users or other domains.

And of course permissions should have good defaults. For example, in the Sora network, only the xor@sora account can mint new XOR, though this account should be able to create events that can mint xor, like the XST stable coins. And no one else should be able to mint XOR. For the Sora network, anyone should be able to read all data as it is a public blockchain, but the criteria to become a validator is to hold 700,000 vested XOR in a locked up bond and other accounts should nominate you with a total of 5 million vested XOR in a locked up bond.

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 05:56]
[In reply to Nikita Puzankov]
querying by assets (e.g., all transactions for sora#xor) and querying by accounts (e.g., all transactions for makoto@sora) are both common use cases, so you need both views and the KV-maps in the WSV should store links to both

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 05:57]
BTW, we should follow the Iroha naming convention where assets are domain#asset and accounts are acct_name@domain. This can be on the SDK-side, though, so whatever is easiest internally is best

Nikita Puzankov, [14.05.20 10:58]
@salakhiev how did you associate assets and accounts in iroha 1?

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 11:04]
It's a sql database model

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 11:06]
In Iroha2 we are using a kv store to model wsv, so it makes sense to just store the data we will query via api

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 11:07]
For example, we want to know how many assets each account has, how many qty exists in total for an asset, and be able to get transactions that are incoming/outgoing for an account by asset and also transactions for an asset in general, across all accounts

Kamil' Salakhiev, [14.05.20 11:08]
[In reply to Nikita Puzankov]
This model can help I think. https://soramitsu.atlassian.net/wiki/spaces/IS/pages/165734/Data+model

Makoto Takemiya 武宮誠 (Sora.org - Soramitsu), [14.05.20 11:09]
[In reply to Kamil' Salakhiev]
@humb1t this is why I put Assets under Domain originally, though of course the Domain is just something like a namespacing of where the Asset definition is, not who owns instances of it.