Namespace dimension vs. lightweight IDs

[s8sato]

Current Design

• Account keys and domain names are orthogonal in AccountId
• Asset names and domain names are orthogonal in AssetDefinitionId
• AssetId is a cartesian product of these elements

This design allows:

• account@domain and account@another_domain to be completely separate wallets
• asset#domain and asset#another_domain to 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.

[0x009922]

Do I understand correctly that this only affects internal representation and doesn't affect Iroha API?

[s8sato]

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.

[0x009922]

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.

I am not sure I understand this. How API change would look like, specifically?