search

hyperledger / iroha

Iroha - A simple, enterprise-grade decentralized ledger
https://wiki.hyperledger.org/display/iroha
Apache License 2.0
434 stars 277 forks source link

Target accounts before registration #4426

Open s8sato opened 5 months ago

s8sato commented 5 months ago

I think the point is the domain membership screening. How should a new account apply for and be allowed to join a domain? In terms of authority, there will be a gap between transferring one's own asset to a new account and registering a new account, especially in "private domain". So as you pointed out, the admission process should be managed by a different authority than the sender of the first transaction that mentioned the account.

One idea is that each domain has its own admission policy as a trigger that "activates" a new account in response to the account creation event. Admission policies may vary from domain to domain e.g.

  • No screening
  • Wait for approval of the domain owner
  • Wait for approvals of m of n domain members

In any case, as I implied, I'm going to create a new issue on this and remove the 2nd commit from this PR

_Originally posted by @s8sato in https://github.com/hyperledger/iroha/pull/4411#discussion_r1562173269_

s8sato commented 5 months ago

Related discussions so far:

s8sato commented 4 months ago

current implementation policy


struct AccountId(PublicKey)

struct Domain {
    accounts: Map<AccountId, Account>,
    // snip
}

struct Account {
    id: AccountId,
    domain: DomainId,
    // snip
}

background

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

Erigara commented 4 months ago

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?

s8sato commented 4 months ago

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

s8sato commented 3 months ago