Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evm reverse resolution #157

Merged
merged 42 commits into from
Jul 17, 2024
Merged

Evm reverse resolution #157

merged 42 commits into from
Jul 17, 2024

Conversation

jefflau
Copy link
Member

@jefflau jefflau commented Aug 24, 2023

Renamed the branch so it isn't ensip-16. Old comments/PR here: #132

### Resolving Primary ENS Names by a dapp

* If a dapp has a connected user it SHOULD first check the chainId of the user
* If the chainId is not 1, it SHOULD then construct the ENS name [address].[evmChainCoinType].reverse to obtain the primary ENS name of the user. If none is found, it SHOULD assume that the user has no primary ENS name set

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is cool and kinda what I had in mind but I like the proposal of having L2 registrars in the mix, still grokking but 👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate any and all feedback!

1) Sign a message to set a default record
2) call `setName()` on the default registrar on L1

Possibility: Allowing L1 Primary ENS names to also use `default.addr`. This could be incorporated into the public resolver's `name()` function.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be default.reverse ?

Copy link
Member

@Arachnid Arachnid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should probably explicitly include the directions from ENSIP 11 here on how to create a coin type from a chain ID.

Perhaps we should have some syntax for this? Most primary names are going to be for chains that have chain IDs as coin types, and it seems weird that they would all have hugely long decimal identifiers instead of the shorter ones a chain ID would offer. The extended DNS resolver uses the syntax e<chain id> as a shorthand; perhaps we can do something like that here too?

Copy link

cloudflare-workers-and-pages bot commented Mar 20, 2024

Deploying ens-docs with  Cloudflare Pages  Cloudflare Pages

Latest commit: 5c45407
Status: ✅  Deploy successful!
Preview URL: https://8f2d5b92.docs-bao.pages.dev
Branch Preview URL: https://evm-reverse-resolution.docs-bao.pages.dev

View logs


To determine the avatar URI for a specific EVM chain address, the client MUST reverse-resolve the address by querying the ENS registry on Ethereum for the resolver of `<address>.<coinType>.reverse`, where `<address>` is the lowercase hex-encoded Ethereum address, without leading '0x'. Then, the client calls `.text(namehash('<address>.<coinType>.reverse'), 'avatar')` to retrieve the avatar URI for the address.

If a resolver is returned for the reverse record, but calling `text` causes a revert or returns an empty string, the client MUST call `.name(namehash('<address>.<coinType>.reverse'))`. If this method returns a valid ENS name, the client MUST:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this is worded is overly specific, and implies a method that won't work for a default reverse resolver.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah actually this doesn't really make sense, because there are no custom resolvers on L2 reverse registrars anyway

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the examples should be written descriptively - describing what the client does in the example scenario. SHOULd and MUST etc are for the specification itself.

Copy link
Member

@Arachnid Arachnid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also needs updating to reflect the decision to hex-encode chain IDs.


To determine the avatar URI for a specific EVM chain address, the client MUST reverse-resolve the address by querying the ENS registry on Ethereum for the resolver of `<address>.<coinType>.reverse`, where `<address>` is the lowercase hex-encoded Ethereum address, without leading '0x'. Then, the client calls `.text(namehash('<address>.<coinType>.reverse'), 'avatar')` to retrieve the avatar URI for the address.

If a resolver is returned for the reverse record, but calling `text` causes a revert or returns an empty string, the client MUST call `.name(namehash('<address>.<coinType>.reverse'))`. If this method returns a valid ENS name, the client MUST:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, the examples should be written descriptively - describing what the client does in the example scenario. SHOULd and MUST etc are for the specification itself.

@jefflau jefflau requested review from Arachnid and makoto May 10, 2024 09:35

To make things explicit we will require the signing of a message to confirm that the address in question would like to use mainnet or another network as fallback. This would either resolve directly on mainnet. Defaults would only be applicable to EoAs that can sign a message. This is because smart contract accounts would not be able to reliably set a default on all chains.

### Setting default
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is quite vague. Is it worth including at all?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean removing everything related to defaults?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes; it seems incomplete.

@jefflau jefflau requested a review from Arachnid June 7, 2024 08:29

1) If a dapp has a connected user it SHOULD first check the chainId of the user.
2) It will then construct the cointype using ENSIP-11: `coinType = 0x80000000 | chainId`, which must be converted to lower-case hexadecimal representation.
3) If the chainId is 1, it should call `[address].addr.reverse`, then skip to step 5.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it mean to "call" an ENS name?


ENSIP-12 was concieved before the ENS L2 reverse resolution specification and therefore should be updated to reflect the current state of ENS primary name resolution. This means that all avatar records are able to be updated on a per-chain basis by updating the avatar record on their reverse node.

#### Example of resolving an avatar on an L2 or EVM chain
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is titled "example" but seems to describe a mandatory process for resolving avatars. It also duplicates much of the functionality of the above section. Can we reformulate it to be clearer as a standard, and less duplicative?


To make things explicit we will require the signing of a message to confirm that the address in question would like to use mainnet or another network as fallback. This would either resolve directly on mainnet. Defaults would only be applicable to EoAs that can sign a message. This is because smart contract accounts would not be able to reliably set a default on all chains.

### Setting default
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes; it seems incomplete.

@jefflau jefflau requested a review from Arachnid June 19, 2024 16:39
To determine the avatar URI for a specific EVM chain address, the client can follow the resolution process above until step 6) And then do the following

1. Perform [Ethereum address avatar text record resolution](https://docs.ens.domains/ensip/12#ethereum-address) on the reverse node.
2. If none is found, proceed to step 7), if no primary name is found, consider the avatar resolution a failure
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Step 7?

1. Perform [Ethereum address avatar text record resolution](https://docs.ens.domains/ensip/12#ethereum-address) on the reverse node.
2. If none is found, proceed to step 7), if no primary name is found, consider the avatar resolution a failure
3. Perform [ENS name avatar text record resolution](https://docs.ens.domains/ensip/12#ens-name) on the ENS name.
4. Complete the Reverse resolution process and consider the avatar found valid if the Primary name has been verified on step 12)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this last line is necessary.

### Examples of valid L2 reverse resolution

* Arbitrum: 0f32b753afc8abad9ca6fe589f707755f4df2353.8000A4B1.reverse
* Optimism:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unwanted newline?

@jefflau jefflau merged commit d5e1e8f into master Jul 17, 2024
4 checks passed
@lucemans lucemans deleted the evm-reverse-resolution branch July 17, 2024 09:52
3) Otherwise, set `coinType` using ENSIP-11: `coinType = 0x80000000 | chainId`.
4) Set `reverseName = '[address].[coinTypeAsHex].reverse'`
5) Set `node = namehash(reverseName)`.
6) Fetch the resolver for the reverse name: `resolver = registry.resolver(node)`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this should explicitly state that clients use wildcard resolution so that CCIP-enabled reverse nodes are picked up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants