Reverse Resolution in off-chain settings

🧑‍💻 ENS Development
9

There’s a lot of words here and I’m not sure I understand, so I’m just gonna say things:

Reverse resolution {addr}.addr.reverse is just address → name.

I see no purpose in having anything more complicated than this, so I’m against the current subdomain → resolver = PR → PR.setName() setup simply for gas and complexity.

For example, do we really need this? raffy.51050ec063d393217b436747617ad1c2285aeeee.addr.reverse
 Note: I think there’s value in having EoA-claimable nodes in the registry, but they’re massive overkill for what reverse names do for 99.99999% of use-cases.

The fact that contracts aren’t widely named in 2024 is also odd to me.

A much simpler registry would just store reverse-key (node or address) → resolver address outside of the ENS tree — aka 1 slot on-chain. This registry would only be editable through DAO approved registrars using different proving mechanisms. These should be trustless and irrevocable.

*.addr.reverse (or *.reverse) can be wildcard, and it consults this simplified registry, and forwards the request to the resolver set for that address.

  1. There should be a simple storage contract L (literal) that stores reverse-key → name (string) and any EOA who wants string-based on-chain names can use that.

  2. There should be another contract W (wrapper) that has a map reverse-key → node which converts your reverse address namehash to a wrapped namehash, and then just calls names(), eliminating the need to store a name because it’s already stored on-chain.

  3. If you want a different proving mechanism, deploy another contract (eg. signature, contract ownership, etc.). For example, why can’t contracts just be asked for their own primary? For example, if a contract sets their reverse-key → F (contract forward), F can be a contract that simply calls C.primaryName() when it’s asked to F.resolve(C.addr.reverse, name()).

  4. If you set your reverse-key → custom resolver, then that contract can do whatever, and go off-chain.

If we’re considering using CCIP for reverse resolution, which requires client changes, we should use a solution like this, as it gives maximum control to the owner and minimizes gas.

Some examples:

  • If I have 100 EoAs, I should be able to deploy a contract Q that answers resolve(*.reverse.addr, name()) for any of those 100 addresses, and responds "raffy.eth". And then for each of those 100 EoAs, set reverse key → Q. I should also be able to provide some kind of delegated signature, so I can do this in 1 transaction.

  • If I deploy a new contract, I should be able implement a function primaryName() returns (string) that is my primary name. During the constructor, I claim that name by finding that registrar by name, and then calling claim() on it. That should cost almost nothing (eg. set resolver key → F (forwarding contract above).

  • For virtual names of basename B, EoAs should be able to set reverse-key → B and then that wildcard contract (likely off-chain) can provide the primary.

Additionally, name(node) could be generalized to name(node, chain).

A related idea from Expanding Beyond Mainnet was having a special coinType which indicates universal EVM deployment address (maybe 0x8000003c, evm bit + 60).