Supporting ENS reverse record

💬 General Discussion
1

ENS reverse record (pointing ETH address to an ENS name) allows Dapps to discover ENS name for the connected user and it is one of the most important features through our current L2 integration plan don’t have good ways supporting it. This is a there

How ENS reverse record work.

The reverse record has its own namespace called addr.reverse.

For example, the account 0x314159265dd8dbb310642f98f50c066173c1259b can claim 314159265dd8dbb310642f98f50c066173c1259b.addr.reverse. After doing so, it can configure a resolver and expose metadata, such as a canonical ENS name for this address.

Read more detail here.

Idea 1 : Multiple addr.reverse replica

Steps

  • Create a replica of addr.reverse record into multiple L2 platforms.
  • User sets a reverse record of 0x123 to ricmoo.eth on Optimism
  • User sets a reverse record of 0x123 to ricmoo.firefly.eth on ZKSync
  • Registry picks 0x123 to ricmoo.firefly.eth on ZKSync because it’s the last updated record.

Concerns

  • Looking into every single L2 for the record may be resource-intensive hence may have to whitelist a few known ones (unlike forwarding resolution which anyone can pick any L2).

Idea 2: Message signing

Steps

  • Change Reverse record to allow registration via message signing
  • Move addr.reverse to a L2 (eg: Optimism).
  • Optimism user can register directly on Optimism
  • When the user on L1 or other L2s want to register, sign the message and pass it to the canonical L2.

Concerns

  • Someone has to pay for gas registering on Optimism (though ENS could substitute for gas assuming gas cost is negligible and we can prevent some sort of DDOS attack).
1 Like
2

Message signing sounds like a lot cleaner solution imo and the process is already familiar to many.

1 Like