Part 1 of our discussion around Decentralized Identification solutions, Ethereum Name Service (ENS), and Decentralized Identifiers (DID)
It has been a busy year for Blockchain projects, with plenty of attention being given to ENS.
Since its release, ENS has become a widely used and integrated blockchain domain name standard. In particular, the campaign to manage the airdrop of tokens has generated widespread discussion in the community. Currently, more than 200,000 users have used ENS and created more than 510,000 domain names. Furthermore, ENS has been integrated into more than 300 applications.
Broadly speaking, ENS domain names also belong to a kind of decentralized identifier. The identity of the domain name is formed by a collection of attributes, identified by a certain domain name. As a domain name system, ENS conforms to the three characteristics of the Zooko triangle, namely security, decentralization, and human readability. So some people think: as a veteran blockchain project, backed by Ethereum, ENS will become an alternative to decentralized identities (hereinafter collectively referred to as DID) and unify DID‘s application scenarios.
This article will analyze from the perspective of practical applications whether ENS can really replace DID.
What exactly is ENS?
ENS, the full English name of Ethereum Name Service, is translated as Ethereum Domain Name Service. It is a decentralized, open, and extensible naming system based on the Ethereum blockchain.
In Web2, the original IP of a website is actually a string of numbers. For example, the IP of Google’s homepage is “188.8.131.52”. But when we open Google, we usually only enter “google.com”. This is because through DNS technology, the computer resolves the “google.com” we input into the network IP address “184.108.40.206”, and then links to Google’s server for us to use.
ENS is to Web3 what DNS is to Web2. The difference is that in Web3, the domain name resolved by ENS does not map the website IP, but the user’s Ethernet address. For example, Vitalik’s ENS domain name “vitalik.eth” maps to his Ethereum address “0xd8….45”. When you choose “vitalik.eth” for interaction, the underlying logic is that the computer resolves the domain name and links it to the corresponding Ethereum address, and then you can exchange data with this Ethereum address.
ENS reverse analysis function
Why can we directly use “google.com” instead of “220.127.116.11”? This is because through DNS, the computer associates the domain name “google.com” with this string of IP numbers.
Similarly in Web3, the website IP becomes the Ethereum address (42 characters). For us, memorizing this long list is unrealistic and anti-human. ENS provides the function of reverse resolution, which is to associate a short and readable domain name with this long sequence.
When you have an ENS domain name, you only need to tell the other party “My domain name is ‘xxx.eth’”, and the other party can directly search and interact with you to perform on-chain interactions..
This feature also makes ENS one of the DID solutions in Web3. Once the application integrates ENS, users who already have an ENS domain name can directly use the private key of the Ethereum address to authorize login, without creating an account and password. At the same time, the system will use the ENS name as the account name by default.
In addition, ENS can also support domain name resolution for other types of resources, including content hashing. Simply put, the domain name can be linked to content stored on distributed storage systems (i.e. IPFS, Swarm, etc.), which can contain the user’s historical data, such as account avatar, NFT, etc.
Based on this, ENS can further realize the function of decentralized accounts, not only providing account login, but also saving user data for application retrieval.
As mentioned at the beginning, there are already many protocols and applications connected to ENS. Because of the decentralized login method provided by ENS and the overlap of some services with DID, coupled with the backing of Ethereum, the claim that “ENS can replace DID” is made.
But is this really the case?
What is DID?
Before comparing ENS and DID, let’s take a brief look at DID.
According to the W3C DID standard, DID can be used to identify any entity, including people, institutions, organizations, devices, etc., and is decoupled from traditional centralized organizations such as centralized identity registration agencies, identity providers, and certificate authority centers. They allow the user (identifier control/owner) to fully control the decentralized identifier without the permission of a third party.
At the same time, DID has global uniqueness, high availability, resolvability and password verifiability, and is usually associated with cryptographic technology (such as public and private keys). DID has a wide range of uses, such as establishing a secure communication channel between decentralized data clients and servers.
The decentralized identity system constructed with decentralized identifiers mainly includes two components: the decentralized identifiers described above, and Verifiable Credentials (VC).
Take Ontology’s decentralized identity solution as an example. When a user creates a decentralized identity, DID will verify the user’s true identity through a third-party authority and generate a verifiable voucher VC. Users can save the VC in their own decentralized data client, and during future login and verification, the application can be authorized to verify their VC.
This kind of authorization is not a full verification, only allowing access to the relevant data, other data is not open to the application, and the other party cannot view it. For example, when you rent a car, the car rental platform can view only the driver’s license and historical car rental records that you have authorized to release, and other data cannot be viewed.