hyperledger
Namespace dimension vs. lightweight IDs
Current Design
- Account keys and domain names are orthogonal in
AccountId - Asset names and domain names are orthogonal in
AssetDefinitionId AssetIdis a cartesian product of these elements
This design allows:
account@domainandaccount@another_domainto be completely separate walletsasset#domainandasset#another_domainto be distinct assets without namespace conflicts
Alternative Approach
Instead of embedding relationships within primary entities, we could store relationships in separate tables. For example, a table for account balances could focus only on account and asset primary keys, ignoring domain-level complexity. This would reduce identifier size at the cost of reducing namespace depth and introducing an operational overhead similar to RDB's JOIN.
Do I understand correctly that this only affects internal representation and doesn't affect Iroha API?
It can affect APIs.
For example, asset#domain might work well as an output interface, but not as an input interface -- domain part is redundant as an identifier and could lead to unnecessary errors.
For example,
asset#domainmight work well as an output interface, but not as an input interface --domainpart is redundant as an identifier and could lead to unnecessary errors.
I am not sure I understand this. How API change would look like, specifically?
https://github.com/hyperledger-iroha/iroha/issues/4426#issuecomment-3050538075
S. Sato, [2025/06/26 17:09] On this occasion, I’d like to ask about asset definition IDs in relation to #5361. Should rose#wonderland and rose#anotherland be treated as entirely separate definitions? If not, we could make the domain secondary information rather than part of the ID, so that the ID (key) is more lightweight.
One use case under the current spec might be representing a wrapped token of the rose (native to wonderland) in the anotherland as rose#anotherland. But even then, couldn’t we simply express it by the fact that the account in the anotherland holds the rose ?
I don’t ask for crypto. M◉⃤|<𓊖༒𓊖⛦ Takemiya 武宮誠 (Sora.org & SORAMITSU), [2025/06/26 19:29] Assets defined in separate domains would be separate assets even if they have the same name. The problem we are trying to solve by doing it this way is that in ethereum, there are lots of fake assets with the same name, so by adding the domain, users can more easily check that a domain is the one they want to own the asset issued from. To me it seems to be better to keep assets grouped by domains to make it more orderly and make it a little harder for scammers
W҉i҉l҉l҉R҉R҉ (リヒター) Вильям 🫀⛓️🚆, [2025/06/26 19:42] So accounts are not related to domains (for muh decentralisation) but assets are (for muh legitimacy) Sounds like a good definition
S. Sato, [2025/06/26 20:27] In both cases, there is a relationship with a domain. What I'm questioning here is identification: if knowing xxx uniquely determines its domain, then the pair (xxx, domain) is redundant as an identifier.
S. Sato, [2025/06/26 20:27] Therefore, removing the domain from the asset definition ID does not mean losing the domain membership information—it merely moves that information outside the ID. At that point, the asset name also serves as the unique identifier, so two asset definitions cannot share the same name. (However, to prevent the use of confusing characters, it might be better to restrict the characters allowed in names to ASCII)
S. Sato, [2025/06/26 21:41] There’s no immediate need to change the asset definition IDs, so let’s first see what insights we can gain by changing the account IDs. For example, we might discover that even after altering the IDs, grouping by domain remains straightforward