Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Alias Service #1450

Closed
doubiliu opened this issue Feb 20, 2020 · 11 comments
Closed

Add Alias Service #1450

doubiliu opened this issue Feb 20, 2020 · 11 comments
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@doubiliu
Copy link
Contributor

doubiliu commented Feb 20, 2020

Thanks to @lock9 for speaking in issue #1179. I think we need to add a lightweight alias service in NEO3.It has been implemented in some other public chains and received by users.​

What is alias service

Alias ​​service, which aims to replace random strings that are difficult for humans to remember, such as wallet addresses and smart contract hash, with short phrases, etc.

People no longer need to memorize addresses and hashes, as long as they know a word or a phrase or a custom alias such as an email address or domain name address, they can perform operations such as transferring money and calling contracts.

For example, use doubi.wallet.huobi instead of an account address of doubi.

Advantage

In NEO3, we also need the alias service, which is a basic service. Unlike the domain name resolution services provided by various DAPP project parties, the alias service has many additional advantages:

  1. Easy to use: You can call the interoperable API directly in the contract, without the need
    to call the smart contract interface of a third-party project.
  2. Low-level support: Low-level logic can be added, and the transfer address is
    automatically mapped.
  3. Increase system income: increase the income of NEO holders.
  4. Lightweight: No additional domain name management logic and complex economic
    model

Application scenario

  1. Account address alias

  2. Contract address alias

Neo Version

  • Neo 3

Where in the software does this update applies to?

  • Other:
@doubiliu doubiliu added the Discussion Initial issue state - proposed but not yet accepted label Feb 20, 2020
@shargon
Copy link
Member

shargon commented Feb 20, 2020

This is not a Dapps?

@doubiliu
Copy link
Contributor Author

doubiliu commented Feb 21, 2020

It is not a Dapp.It is a servie or native contract. @shargon

@Tommo-L
Copy link
Contributor

Tommo-L commented Feb 24, 2020

Could we add this service? @neo-project/core

@erikzhang
Copy link
Member

I think this feature can be replaced by a native name service.

@Tommo-L
Copy link
Contributor

Tommo-L commented Feb 24, 2020

We've considered NNS, but it's a little complicated, including domain trading(with domain-level) and economic models, and it's not recommended to implement them in native contracts.

If we don't consider these, then the name service is the alias service and we can implement it quickly.

In addition, we can set up some naming conventions for users.

For dapp:

neo://xxx
xxx.xxxx.dapp
...

For account:

xxx.neo.wallet
xxx@xxx.xxx // email address
....

@shargon
Copy link
Member

shargon commented Feb 24, 2020

How do you will prevent the impersonation?

@Tommo-L
Copy link
Contributor

Tommo-L commented Feb 24, 2020

Bind with NeoID later? 😄

@shargon
Copy link
Member

shargon commented Feb 24, 2020

Then we should finish neo ID first :P or be able to claim a created alias as yours

@doubiliu
Copy link
Contributor Author

doubiliu commented Apr 3, 2020

Well. Although the ID solution will take some time to discuss, I don't think it affects the implementation of the alias service too much. NGD designed a rough function definition and process implementation.The overall implementation can be divided into two processes. The basic functions are implemented first, and the extended functions are implemented after the ID is determined.

The scheme is as follows:

Design goals

  1. Provide address alias service
  2. Provide contract alias service

Detail

Data Structure

Each alias in the system corresponds to an address (account address / contract address), and one address can correspond to multiple aliases.

Use <String alias, <UInt160 / UInt256 address, UInt256 owner>> to store the mapping between the alias and the account

image

To prevent impersonation, an ID can be introduced to authenticate the alias.ID does not have a strong relationship with the alias, you need to use the address as an intermediate bridge

Use <UInt160 / UInt256 address, <String alias, byte [] [] id >> to store the authentication relationship of the alias

Function Define

Name Return type Description
Base Function    
findAliasByAddress(UInt160/UInt256 address) List< string > Find all aliases corresponding to the specified address
findAddressByAlias(String alias) UInt160/UInt256 Find address corresponding to the specified alias.
registerAlias(UInt160/UInt256 address,String alias) true/false Register a alias.
modifyAlias(UInt160/UInt256 address,String alias) true/false Modify the address of the alias (callable by the alias registrant)
deleteAlias(String alias) true/false Delete alias.(callable by the alias registrant)
Extension function TBD    
isApproved(String alias) true/false Whether the alias is approved.
approveAlias(String alias,byte[] id) true/false Approve alias.(callable by the alias registrant)
getApproveInfo(String alias) byte[ ] [ ] id Get alias authentication information
removeApprove(String alias,byte[] id) true/false Remove alias authentication information.(callable by the alias registrant)

@erikzhang
Copy link
Member

We plan to build a native domain name system in neo. I think the alias service conflicts with it.

@doubiliu
Copy link
Contributor Author

doubiliu commented Apr 3, 2020

Got it, we will design the domain name service directly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

No branches or pull requests

4 participants