Account alias resolution

[s8sato]

Feature request

2. Open a separate issue to discuss whether we want to implement alias as part of Iroha or delegate this to external service (I would prefer to keep alias resolution as a separate service outside Iroha to not complicate the codebase)

Motivation

#2085 (comment)

Who can help?

No response

[s8sato]

As long as transaction.payload.authority is AccountId, aliases should be resolved before the transaction building.
Otherwise the transaction signature will be affected by aliases, which means verifiers should consider alias history of the transaction authority

[mversic]

you make a good point for the case of having alias resolution as external service

[s8sato]

My last post didn't say anything so let me redefine the motive to external name services:
Since the transaction authority is the client itself, it is already in the config in a resolved format.
Rather, the problem with having an internal name service (or an internal entrypoint for external name services) is that API has to accept aliases as a variant of other account IDs in the request (e.g. transfer destination).
If we want to treat aliases as optional, it should not affect the current API.

The problem then is that such an external name service needs to have the same security as Iroha:
Suppose the name service has been hacked. Your destination alias will resolve to the scammer's address. This would mean that the name service spoiled the security provided by Iroha.
So the name service would be a decentralized system. In blockchains, it seems to be common to use blockchain for name service.

My suggestion is to deploy another chain dedicated to aliases, and having clients communicate with it to resolve aliases as needed.
I think we can learn from ENSv2, which is moving core functionalities from the mainnet to L2

[s8sato]

My last post didn't say anything

No, it said something:
if clients built a transaction with unresolved names, the signature should be verified with that unresolved names, which means the name resolution would penetrate deeper than the authentication, which would be a cost on every verifier

[s8sato]

Draft happy path

Prerequisites:

• A resolver is a Torii endpoint of a node of another Iroha network deployed as a name service
• An alias is an asset (definition) in the name service

Resolution on sending requests:

1. Client accepts AccountAddr as user input, which is either AccountAlias (e.g. alice@wonderland) or AccountId
2. Client detects AccountAlias before building a transaction/query and query the resolver to resolve them
   • Request contains an array of FindAssetDefinitionById (e.g. alice#wonderland)
   • Response contains an array of AccountId (e.g. alice#wonderland.owner) which is the same order as the request
3. Client replaces every AccountAlias with the AccountId and sign the transaction/query

Reverse-resolution on receiving responses:

1. Client receives a query result
2. Client detects AccountId and query the resolver to reverse-resolve them
   • Request contains an array of FindAccountKeyValueByIdAndKey (e.g. ed0120...@wonderland.aliases)
   • Response contains an array of JsonString which is the same order as the request
3. Client replaces some AccountId with the primary AccountAlias (e.g. aliases.0) and show the query result

Questions

• Do we assume that the name service will support multiple Iroha chains? If so, should aliases be unique across chains?
• How does a single endpoint guarantee that aliases are correctly resolved?
• How to prevent rewriting of the resolution requests/responses by intermediaries?