Future of the Primary ENS Name

🧑‍💻 ENS Development Standards
1

The Primary ENS Name (aka Reverse Registration) is one of the most critical feature to make ENS as “Web3 User name”. Any dapps can reverse lookup ENS of the connected user and display ENS name as the primary username.
Many blockchain explorers and dapps decode the transaction history to add ENS names into their site.

However, because the current primary name can only be set by the address owner, it brings the following limitations.

  • a. Cannot set primary name at registration in one transaction
  • b. Contracts cannot set primary name unless the contract supports the ability to call arbitrary functions via the contract
  • c. Users has to pay the gas on L1
  • d. Dapps (or other services) cannot substitute gas on behalf of the user

The upcoming smart contract upgrade solves a, and b (with the introduction of owner and authorised ), but c & d still remain as problematic.

The problem even becomes more apparent as CCIP-read becomes adopted to integrate with Layer 2/Offchain. Even though users pay little or no gas to register names offchain/l2, users still has to pay the gas on L1. This is because reverse registrar (aka primary name) is currently another tld under hash[addresss].addr.reverse on l1. The current architecture doesn’t allow users to change primary name registration offchain/l2 unless the entire name space moves to a l2 chain (even when this happens, it does not allow you to set primary names of your choice).

There are a couple of improvement plans suggested and I would like to use this thread to continue the conversation.

Option 1: Multiple reverse registrar across multi chain.

This was discussed back in 2021 during the after hour of ENS workshop between matoken.eth and ricmoo.eth

The idea is to deploy registrar to each chain, and the registry has the list of chainId and registrar contract names to lookup. The addition/deletion of the cross chain registrar registrion is done by the DAO voting. When the user has registered reverse name on the multiple chains, the last registered record wins (assuming that the registration date exists on chain).

The pros of the idea is that it allows user to pick the chain of their choice.
The cons of the idea is that the reverse lookup may become slow when the list gets big. It also does not allow users to use offchain as a data storage (and probably need special consideration for non EVM chains like Starknet).

Option 2: Gasless primary DNS names

The idea by Premm.eth.

(Premm to fill in)

9 Likes
2

I’m excited to share more information about gasless primary names soon, but in the meantime, I’ve been doing some research on the topic. I wanted to share a relevant resource:

The reverse resolution process involves selecting the correct primary name from the set of forward resolutions that correspond to a wallet address. Malicious reverse resolvers have limited options - they can either resolve the wrong primary name from the set of forward resolutions or choose not to resolve the primary name at all.

With CCIP-Read, the gateway is responsible for resolving the primary name in a verifiable manner. The private key of the gateway, verified by the reverse resolution resolver, serves as the first layer of proof.

Gasless primary names introduce an additional layer of proof - a signature by the primary name’s resolved address indicating which name from the set of forward resolutions is the primary name. This means that a malicious gateway can only censor the resolution and choose not to resolve the primary name or resolve an old primary name if the owner changes their primary name.

To address the issue of censoring, ENSIP-10 and CCIP-Read allow an on-chain record to override an off-chain record. If the gateway is censoring, the owner of the reverse resolution address can execute an on-chain transaction to override the gateway.

The issue of resolving an old primary name can be mitigated in multiple ways. One option is to add start and end dates or block numbers to the signature. Once the signature expires, it cannot be used. The problem with this approach is that it requires new signatures from the resolved address every time the signature expires. Alternatively, signatures could be valid indefinitely, but there could be an on-chain method for revoking signatures. If a gateway resolves old signatures instead of the latest signature, the signer can execute an on-chain transaction to revoke any old signatures.

I believe that being censored and resolving to the wrong primary name are equally problematic. The solution to both issues is to use an on-chain record to override the off-chain resolution. If resolving an old primary name is considered a significant enough threat in itself to warrant a separate mitigation strategy, an on-chain signature revoking system could be implemented.

Gasless reverse resolution allows users to set a primary name without paying anything on-chain initially. It only requires a gas transaction when the gateway is censoring or returning the wrong primary name from the set of names that resolve to the reverse resolution address. This is a significant improvement over the current setup, where all users must make an on-chain transaction to solve a problem (a censoring, malicious gateway) that doesn’t actually exist yet.

4 Likes
3

I’ve also thought about this before in a similar fashion. The idea was to have a canonical reverse registrar (and registry) on each EVM chain. And then it would be the job of the dapp to know which chain they are currently connected to: e.g. Optimism. If the user was on optimism, it would look for the reverse record on Optimism via the canonical registry. If it existed, it would proceed to check Ethereum L1 (via L1 records or CCIP-read) to make sure the forward resolution matches, and if so considers the reverse record to be valid.

  • Allows multiple reverse records for the same address for each chain.
  • Requires a canonical registry to search for the reverse record on that specific chain.
  • Doesn’t allow L1 primary ENS names to be set off-chain.
4 Likes
4

After research and some back and forth, this ENSIP looks close to what we would want from a multi-chain Primary ENS name:

Some important points would include:

  • Allows multiple reverse records for the same address for each chain.
  • Requires a canonical registry to search for the reverse record on that specific chain.
  • Doesn’t allow L1 primary ENS names to be set off-chain. (and possibly never allowing L1 primary ENS names to be set off L1)
  • Deprecating and discouraging use of addr(60) as a way of verifying a primary ENS name on other chains other than Ethereum mainnet.
  • Currently the resolvers used for setting primary ENS names would have to be unmodifable to allow CCIP-read to verify the L2 state root

Primary ENS names will be more important in a multi-chain account abstracted world, and so bringing this forward hopefully brings us closer to improving the UX for the entire Ethereum ecosystem

2 Likes
5

Is it possible with this proposal to set a primary name for all chains and not have to pay an L1 gas fee?

6

Yes, except for L1 of course.

7

In one transaction?

8

No, it will be at least one transaction per chain.