search

hyperledger / iroha

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

Account alias resolution #4372

Open s8sato opened 5 months ago

s8sato commented 5 months ago

Feature request

  1. 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

https://github.com/hyperledger/iroha/issues/2085#issuecomment-1991254965

Who can help?

No response

s8sato commented 4 months ago

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 commented 4 months ago

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

s8sato commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Draft happy path

Prerequisites:

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