Giter Site home page Giter Site logo

Comments (4)

Erigara avatar Erigara commented on June 2, 2024 1

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?

from iroha.

s8sato avatar s8sato commented on June 2, 2024 1

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

from iroha.

s8sato avatar s8sato commented on June 2, 2024

Related discussions so far:

from iroha.

s8sato avatar s8sato commented on June 2, 2024

current implementation policy

struct AccountId(PublicKey)

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

struct Account {
    id: AccountId,
    domain: DomainId,
    // snip
}
  • A provisional account is assigned to default domain
  • Register<Account> is an instruction to change account.domain
  • Unregister<Account> is an instruction to reset account.domain to default

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

from iroha.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.