Open s8sato opened 6 months ago
struct AccountId(PublicKey)
struct Domain {
accounts: Map<AccountId, Account>,
// snip
}
struct Account {
id: AccountId,
domain: DomainId,
// snip
}
default
domainRegister<Account>
is an instruction to change account.domain
Unregister<Account>
is an instruction to reset account.domain
to default
It seems unnatural to expect a multihash@domain
address before the account is allowed to belong to the domain.
multihash
address for accounts would be ideal at the moment.
However, this implies Map<AccountId, Account>
directly under the world.
I'm not sure if a single top-level storage can withstand billions of accounts that Iroha ultimately aims for.
I'd keep the accounts map under each domain, accept both multihash
and multihash@domain
input, and convert multihash
to multihash@default
.
A drawback would be that address must include not only ID (multihash) but also domain
I'm not sure if a single top-level storage can withstand billions of accounts that Iroha ultimately aims for.
Can't fully agree since when having all accounts in the one place we can better optimize their layout.
Also with our current Storage
it's more beneficial to have more granular data.
Right now update in account imply whole clone of the domain.
A provisional account is assigned to default domain
What about permission interaction of assets and accounts?
Like suppose that we have some domain my_domain
, and we have asset my_asset
which is only allowed for account in my_domain
.
We want to transfer this asset to offline account my_account
.
On transfer my_account
would be assigned to default
domain and transfer would fail.
Do we want to support this case?
Indeed, it can be misimplementation to equate the domain membership and the account activation e.g. someone can stash an account to another domain and an admin of the original domain can no longer revoke permission of the account.
Instead, domain (candidate) should be fixed from when the account is provisional. Also, I'll consider shallow storages that maps account ids, in relation to implementing account activation
_Originally posted by @s8sato in https://github.com/hyperledger/iroha/pull/4411#discussion_r1562173269_