Introduction

With the introduction of contenthash (aka EIP 1577), people are starting to realise the true potential of ENS beyond the basic usage of resolving Ethereum hex address.

Contenthash already allows you to set various types of data serialised in self describing format called multicodec. It supports over 100 of different protocols such as IPFS, Swarm, Onion (address format used for Tor anonymity network) and so on (the full list is here).

If the dataset you want to support is neither in the multicodec or not fits into 32bytes (= 256 characters) limit, we have another field called Text , which allows you to set multiple key & value pair with unlimited length in string format. This literally allows you to set anything. In fact, one of teams who hacked at EthNY and won ENS prize used these features to modify ENS manager app (and Metamask) to support onion. format.

Storgate team at ETHNewYork hackathon

Is ENS scalable for many blockchains?

Do you know where I am leading to? Recently Chris Remus asked over Twitter why people haven’t used ENS. The biggest response was that people don’t know where they can use ENS. Viktor Radchenko, the creator of Trust Wallet even replied that ENS lacks the functionality and not scalable enough for many blockchains.

If you have read through till this point, you already know that this is not true. ENS already exists. You just need to start using it.

Having said that, you have to take the critics of Wallet creators more seriously. With the rise of other “Ethereum Killer” blockchains, the pragmatic wallet providers (such as Trust Wallet and imToken) already started supporting other chains such as Bitcoin and EOS. For them, supporting naming service to only one chain lacks consistent user interface (though high-five 🙏 to ImToken to be one of the first wallets supporting ENS!). Even though EOS does have its own name service (EOS Name Service, aka ENS!!!), it will be wallet/dapp friendly if you can use one naming service to support all crypto currency addresses.

This leads to projects such as FIO and Unstoppabledomains which USP is to allow users to specify multiple blockchain address with single name.

In one way, this is a good validation that many people supports our core value that providing human readable name to hex address will improve usability and adoption of blockchain and crypto currencies.

However, it is concerning when a well known project from our own ecosystem decides to choose other name service because they think ENS does not offer what it takes to be a future proof chain agnostic name service.

Firstly, we should definitely come up with better standard which allows our ecosystem members to start using ENS for cross chain name resolution.

Secondly, each name service provider (ENS, Handshake, EOS Name service) have to be more mindful of trying to avoid name conflicts at top level. Imagine both Handshake, FIO and EOS Name Service offer a name called maktoken.xyz which resolves to completely different addresses depending on which name service wallets and dapps support. ENS at least tries our best to avoid the conflict by honouring existing TLDs through DNSSec integration (and .eth is the non existing TLD).

Example of overlapping names between ENS and EOS name service

Cross chain name resolution as a specification

In addition to build these standard, we have another set of more technically challenging problems to solve.

As a pioneer of smartcontract platform and less maximalistic view of Ethereum community nurtured the world of “Multiple EVM worlds”. We already have multiple “Mainnets” such as POA and lots of Consortium chains (eg: JP Morgan’s Quorum). There are also other chains which is compatible at EVM level such as Tron, ETC, and RSK(Bitcoin side-chain). For these chains, one can easily deploy the copy of ENS smart contract (and I heard that RSK already does that) but that would create data silos. Also, it is currently almost impossible to resolve names of other chains on-chain (eg: Writing a smartcontract which allows you to transfer token by ENS name, not by ENS address). We also have to consider layer 2 solutions such as Plasmas and state channel. To enable that we must come up with some sort of “Bridging specification” just like POA implements for Token exchange. Ideally these bridging specification could be applied to non EVM compatible cross chain solution such as Cosmos and Polkadot.

Call for participation at Berlin Blockchain week

We would love to hear from our community about various use case of cross chain name resolution usage as well as any proposal for standards. The best place to discuss online is on our forum but would love to hear your voice directly as well.

I (Makoto) am planning to go to Berlin during Berlin Blockchain week. Unfortunately I don’t have any talks planned on any of these events, but if there are any demand, I am happy to either propose as a topic on Magicians Berlin Council 2019 or can organise a separate small event (in that case, any help for venue would be appreciated).