search

EthereumCommonwealth / Roadmap

GNU Lesser General Public License v2.1
57 stars 17 forks source link

Crosschain ENS lookup. #28

Closed Dexaran closed 4 years ago

Dexaran commented 7 years ago

Abstract

Ethereum addresses are exactly the same on all Ethereum-based chains, such are ETH, ETC, UBIQ, EXP, Musicoin, SoilCoin (not sure about RSK, didn't investigated yet).

This means that you can use one account (read: private key) for all chains. As the owner of 0x488c9e2df11ac9d19eb07df362cb174ffd4724d8, I also own an account with the same address on any of the above chains and can dispose of funds from it.

This means that if the address 0x488c9e2df11ac9d19eb07df362cb174ffd4724d8 is the owner of the name dexaran.eth in ENS, then you can perform a lookup in the ENS contract that is deployed ETH chain, but execute the transaction on any other of the specified chains.

In two words: you can send ETC to the owner of dexaran.eth and he can access them without any problems.

Proposal

I wish to create a service that will perform lookup on any of the existing ENS forks based on the name resolution. I will integrate it into ClassicEtherWallet and write a patch to MEW as well.

For example:

If ENS integrates with ICANN, I will change the search method so that any user can artificially choose which particular naming service he wants to use.

Motivation

I believe that improving any of the Ethereum-based networks will be beneficial for the whole Ethereum ecosystem. I also believe that Ethereum Classic, UBQ, Expanse and others belong to the Ethereum ecosystem.

This is similar to how all crypto-currencies based on BitCore get benefits from updates like SegWit or Lightning.

It is obvious that the integration between chains is beneficial for both participants and increases the cost of both chains.

This is beneficial for users: each name will cost you in proportion to the currency rate of the network in which you buy the name. If the user doesn't care about the resolution he can just pick the cheapest one.

It also allows us to introduce new TLDs without affecting the original ENS.

The issue

We should came into agreement about what exactly resolutions would be assigned to each naming service. Currently, ENS uses .eth, and ECNS uses.etc. I propose:

iquidus commented 7 years ago

Ubiq (UBQ) will use .ubq

chrisfranko commented 7 years ago

.exp is fine for us also.

Dexaran commented 7 years ago

We have decided that it will be better to implement manual lookup source selection as @realcodywburns suggested.

https://github.com/Dexaran/ICO/issues/26#issuecomment-324541572

alexvandesande commented 7 years ago

Interesting proposal. ENS is a very flexible architecture, meaning that the whole auctioning off system is a part of the .eth registrar, but other contracts could have different ways to approach it. We have avoided adding any other TLD other than .eth but this is the first time I seen that could make sense.

Is your proposal that one chain would be the "definitive authority" on ens? Or are you simply proposing that each chain deploys their own version of the same code?

pinging @arachnid

Dexaran commented 7 years ago

@alexvandesande

Or are you simply proposing that each chain deploys their own version of the same code?

ETH chain has an original ENS. I have modified it a bit and deployed ECNS contracts on ETC chain earlier. ECNS has a couple of differences:

  1. ECNS doesn't burn funds unlike ENS.
  2. ECNS Registrar contract contains constant returns function that implements namehash algorithm. I think that it is necessary to allow third party services to call contract instead of implementing namehash by their own.
  3. ECNS contains an emergency function to extract stuck ERC20 tokens.
  4. ECNS has .etc TLD.

Expanse has its own ENS already. I have contacted UBQ developers and they said that they are working on UbqNS. They wish to simplify name registration process rather than using blind auction.

I've heard that it is planned to integrate ENS with ICANN. I'm often asked to add .token / .coin / .ico TLDs to ECNS. I think that we have a great opportunity to introduce different name registration models / TLDs / ENS modifications without any violation of the original ENS.

In couple of words the main idea is: Allow users to register name on one chain but use it on any Ethereum-compatible chain.

Anyways I like the idea of creating a cross chain service. We can implement it into ClassicEtherWallet and ClassicMask (a wallet extension; port of MetaMask with a couple of modifications) and propose a patch to MEW.

Dexaran commented 7 years ago

I suggest a TLD for .eth / .etc / .ubq / .exp to make it clear which chain ENS is used. I think that we can extend it later if it will be necessary.

realcodywburns commented 7 years ago

I am not sure if any of the desktop wallets are cacheing ens names, but it could be helpful in the long term. The most accurate way (DNS like) would be to create a decentralized root name server. For our purposes, a json file that lists the ens/ecns/whatever's public api point & resolver contract address that is publicly accessible. Any system could then query the root to find where all .etc addresses are stored, and then call the specific contract to get the address.

The flow for dontpanic.etc. would go: client >> local cache [>> dRNS >> ECNS] where the ECNS would be used to resolve the pubKey if it was not already cached. That pubKey could then be used to query all chains through public API points to call balances

realcodywburns commented 7 years ago

Thinking deeper into it , the tld should resolve into the corresponding eip155 chain id as specified in https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md such that dontpanic.etc. would resolve to 0xfff......321.61