DNS (Domain Name System) was born almost forty years ago to provide the ability to assign human-readable names to nodes in a network. Without names, such nodes would have had to be identified via IP addresses, which are very difficult to memorize, write, and read.
ENS (Ethereum Name Service) aims to solve the same problem in the Ethereum blockchain. It maps human-readable names (such as “name.eth”) to Ethereum addresses or content hashes, which would be extremely error-prone to write by hand.
A brief look at ENS
As per the official documentation, ENS is defined as “a distributed, open, extensible naming system.” Being a decentralized system, ENS is not controlled by any centralized entity or party. As such, there is no single point of failure. Additionally, ENS supports IPFS (InterPlanetary File System), a peer-to-peer protocol to store and share data in a distributed file system.
ENS is built on two fundamental components: the registry and the resolvers. The former is a smart contract that records all the domains registered on ENS, along with some metadata regarding each domain (owner, resolver, and the caching time for all the records under the domain). Resolvers are smart contracts, too. They turn human-readable names (i.e., the domain names) into hexadecimal addresses, and vice versa.
Hence, resolving a name in ENS requires two steps:
- ask the registry for the address of the resolver corresponding to a given domain
- query the resolver (for example, asking the address corresponding to a given domain)
ENS supports Ethereum domains, .eth, as well as the most popular “DNS” domains, such as .com, .io, and .org.
This sounds all good, but, at the time of writing, most browsers are not able to resolve .eth domains without a little help. Some third-party extensions out there do the job, but they require extra steps to be set up. For this reason, two gateways have been created so far: eth.link and eth.limo.
In this blog post, we’re going to compare them.
eth.link
eth.link is a centralized way to access information in the ENS from DNS, managed by Cloudflare, a company providing CDNs (Content Delivery Networks) and DDoS (Distributed Denial-of-Service) mitigation services.
Under the hood, eth.link uses a wildcard DNS record (*.eth.link) to capture requests for all ENS domains. In other words, eth.link leverages the resolution of .link domains to obtain information about a given .eth domain. For example, a DNS A record request for mydomain.eth.link would trigger the wildcarded *.eth.link record and return the A record in ENS for mydomain.eth.
eth.link runs entirely on Cloudflare Workers, which is essentially a runtime in execution on several servers (owned by Cloudflare) across the world. In the rest of the post, we’ll refer to “Workers” as the server themselves, for the sake of simplicity.
Whenever a user tries to access mydomain.eth.link, Workers query ENS (i.e., the Ethereum blockchain) for a CID (Content Identifier). CIDs are directly derived from the content of a resource, so they are often referred to as self-describing identifiers. They’re basically hashes describing the content of something, such as a webpage.
Once the CID for mydomain.eth.link is established, Workers query an IPFS Gateway with the CID in order to obtain the content of the webpage. The content is then forwarded to the user.
The main issue of eth.link is surely its centralization, which puts a lot of control in Cloudflare’s hands. It also makes it more prone to the following issues:
- single point of failure and downtime, as eth.link runs on Cloudflare’s infrastructure
- lack of transparency: Cloudflare owns the infrastructure and every data about it (traffic, uptime and downtime, and so forth). Thus, the community only knows what Cloudflare shares with them
- censorship
- man-in-the-middle attacks: a rogue employee or an attacker with access to Cloudflare’s servers could manipulate the content to be served
To solve the issues listed above, another gateway was born: eth.limo.
eth.limo
eth.limo is a decentralized alternative to eth.link. Similar to eth.link, eth.limo is based on a wildcarded DNS record, *.eth.limo. However, instead of being managed by a single organization, it is powered by a DAO (Decentralized Autonomous Organization), so its inner workings are defined in a smart contract and cannot be changed unilaterally.
The flow is the same as that described above. When a user tries to access mydomain.eth.limo, the LIMO service fetches the CID for the webpage from Ethereum’s main network and then returns the content of the requested webpage. The project is still in a very early phase, but the goal is to be able to let anyone deploy a personal LIMO service.
The developers are also considering letting anyone operate a node for the official network in order to build a community-run CDN. This is quite different from eth.link’s approach, where the nodes of the network are entirely under Cloudflare’s control.
Early tests showed that eth.limo is faster than eth.link, even though the load is still much different, being that eth.limo is still in alpha test:
Source: https://twitter.com/eth_limo/status/1433093424178253828?s=20
eth.limo is younger than eth.link. Hence, it is still being tested and developed. However, its roadmap is focused on user privacy and community governance and oversight.
Conclusion
In this post, we saw a brief comparison of two alternatives to resolve .eth domains using ENS. On the one hand, we have the experience and the infrastructural power of Cloudflare powering eth.link. On the other hand, we have a community-driven project built around decentralization and with a strong focus on user privacy, eth.limo.
Even if similar in how they work, the two projects are deeply different. eth.limo is surely less mature than eth.link and with a very ambitious program. As its core principles adhere much more to Ethereum’s and blockchain’s ones, I think it’ll become a very interesting project in the future. At the moment, however, it’s at the beginning of its life, and using only eth.limo could be a risky choice.
eth.link, on the other hand, is more “production-ready” because it’s been around for more time. Hence, if I were to start a personal project using a .eth domain, I’d probably want to use both of them, with the goal of migrating to using exclusively eth.limo as soon as it becomes more stable.
At the time of writing, those are the only two possibilities. As the ability to choose is an important part of the transition toward decentralized applications and the web, we’ll see if, in the future, new alternatives will come up.
The post .eth.link vs .eth.limo: Comparing alternatives for .eth domain resolution appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/FYTdf5x
via Read more
