How the Ethereum Name Service plans to support layer 2

blog.mycrypto.com7m ago

With the rising popularity of Ethereum over the past few years, gas prices have increased significantly and people have begun looking for alternatives to reduce those costs. For this reason, many projects started using Layer 2 (L2) solutions, which usually have significantly lower gas fees. The Ethereum Name Service (ENS) is one of such projects, and will be adding support for L2 via two new proposals: ENSIP-10: Wildcard Resolution and EIP-3668: CCIP Read: Secure offchain data retrieval.

The problem with using ENS domains right now is the high cost to set up a domain. You have to register it, set a resolver for the domain, and then make the resolver point to your address. Gas costs could be reduced a little bit by using ENS subdomains, like maarten.mycrypto.eth, but then you still need to set a resolver for the subdomain and point it to your address. This could get expensive very quickly.

EIP-3668 and ENSIP-10 solve this problem by making it possible to resolve ENS domains without the Ethereum network.

New Proposals, Summarised

EIP-3668 introduces a secure Cross-Chain Interoperability Protocol (CCIP) Read method for clients to fetch data offchain. Note that while "offchain" in this context means "off the Ethereum chain," it could be fetched on another chain. This could be a Layer 2 network, or some other arbitrary way of resolving, depending on how it's implemented.

A simplified diagram of EIP-3668, originally from the EIP-3668 specification.

This works by first performing a call on a contract that returns a gateway URL and some data. The client then sends an HTTP request to the gateway with the specified data, which can fetch the data in any way it wants to. The data returned by the gateway can be verified using the callback function on the onchain contract.

This specification is not specific to ENS however. It can be used to fetch any data offchain in a secure way.

ENSIP-10 (yes, ENSIP) makes it possible to resolve wildcard domains. An example of such a domain could be *.mycrypto.eth, where * is a wildcard. Any subdomains that end with .mycrypto.eth, like maarten.mycrypto.eth then point to the same resolver, which can use custom logic to resolve the domain.

Resolving ENS Domains on L2

It is completely up to the contract and gateway to decide how wildcard domains are resolved and how offchain data fetching is conducted. By combining the two proposals we can set up a wildcard domain and use an offchain method like an L2 network to actually resolve the address.

The gateway can perform a call to a resolver contract on an L2 network, and fetch the address corresponding to the ENS domain. This way, you only need to point an ENS (sub)domain to a resolver contract using CCIP. Any changes to the (sub)domain can be done on a cheaper L2 network. For wildcard domains, it's not necessary to perform any transactions on the mainnet to register a new subdomain, since any subdomain will point to the L2 resolver contract.

There is no official way to do this yet, but DApps and other projects can create their own solution using the two proposals. ENS is aiming to launch an official integration with Layer 2 near the end of Q1, 2022.

More on ENS Sign-in With Ethereum: An Alternative to Centralized Identity Providers In the future, email/password login may be no more. Talk To Us & Share Your Thoughts