ERC-7828: Chain-specific addresses using ENS

[clowes.eth]

Note: I wrote this at the end of March but was unable to post it due to permissions. Retrying, having caught up.

Some commentary.

My context/background: domain names and ENS.

ERC 7785

The current spec as-is seems to lack in clarity what ENS resolution specification this ERC seeks to take advantage of.

ENS have a number of ENSIPs pertaining to address resolution (ENSIP-1, ENSIP-9, and ENSIP-10 for example) as well as the resolution of arbitrary and/or standardised text records (see ENSIP-5).

Regardless of where it appears, when we see arbitrum.eth what exactly are we resolving? Are we resolving an address? I don’t think so - that makes little sense.

ERC 7885 states that “The name should resolve to a record containing not only the chain identifier, but also all the optional information necessary to verify the identifier.”. The implication here is that we are resolving arbitrary data (in a specific defined format) subject to ENSIP-5. If so, what key are we defining (and standardising) to hold this data?

Second Level ENS names

A number of people have mentioned that chain operators do not necessarily own their ‘logical’ corresponding second level .eth ENS name.

I do not think a specification should define expectations that this is the case - this is an implementation detail. Arbitrum (for example) should be able to choose if they want to use arb.eth, arbitrum.eth, or nitro123.eth.

2 Character ENS Names

“EF populates two subdomains l2.eth and chainid.reverse using Ethereum lists.”

The only entity that has the power to assign ownership of the l2.eth ENS name is the ENS DAO noting that the minimum length of an ENS name given current rules is 3 characters. This would need careful consideration given the precendent allocating the name would set.

Subdomains?

I think this using subdomains might be a better approach. An arbitrary ENS name is registered e.g chaindata.eth and a custom resolver deployed with revokable admin controls. Subdomains could then be allocated and custom text records set subject to the aforementioned pre-defined key (e.g chainData).

The approach can be taken further with versioning within the subname scheme - v1.arbitrum.chaindata.eth or latest.arbitrum.chaindata.eth (with the canonical latest data resolved from arbitrum.chaindata.eth).

My understanding is that chain data is unique and immutable subject to specific rollup configuration - once deployed we can hand off control over subname allocation to the multisigs controlled by the rollup creators.

For bonus points: Lobby the ENS DAO for .chain and you unlock the possibility of v1.optimism.chain. Note: this will be a big ask giving consideration to the ENS Constitution and ICANN’s new gTLD program.

ERC 7828

In the context of 7828 there is debate about the appropriateness of using @ and the potential for confusion with email.

Why can we not simply use user.v1.arbitrum.chaindata.eth?

• 0x123.v1.arbitrum.chaindata.eth => 0x123 on the chain identified in the chainData text record for v1.arbitrum.chaindata.eth

• clowes.optimism.chaindata.eth => Resolve the chainData text record on optimism.chaindata.eth and then resolve clowes.eth using ENSIP-9 with the coinType specified in the resolved chainData.

In the latter case we could grandfather in the coinType set derived for the current versions of rollups subject to ENSIP-11. coinType derivation moving forward could be adapted to consider a version number or they could simply be arbitrarily set with uniqueness checks within the resolver implementation.

TL;DR

Can this all just be an ENS Resolver contract, an ENSIP-5 text record identifier, and a format for its value?

More Thoughts (7th May)

DNS

DNS collision is a non-issue with ENS as .eth is the only chain only TLD offered.

.eth is the three letter country code representation of Ethiopia and it is reserved but not assigned by ICANN. I believe there have been conversations about the path to potentially getting control of .eth in the zone and utilising it, but don’t quote me on that.

ENS have a DNS integration. Also see ENSIP-17. The owner of a DNS name can import that name and utilise it within the ENS system.

Alternate naming services could cause extension collisions as has been seen historically e.g. .coin

My perception is that the general positioning of ENS DAO participants is one of working collaboratively with ICANN. See for example:

https://x.com/GUA/status/1917988549103882241

@teddy

I propose we instead lean away from ICANN/IANA, keeping names hierarchical but being able to easily tell them apart by using a different separator.

If we use ENS this is abstracted away in many respects. This discussion surrounds an Ethereum Request for Comment, and I think its a valid call to focus it around ENS - an Ethereum identity primitive.

@nategraf

If the domain structure an . separator are kept (e.g. eth.short), my two concrete proposals on this are:

• that it be made explicit that each new L0-TLDs must not be equal to an ICANN TLD.
• that caution is taken towards the risk of an L0-TLD being defined as a ICANN TLD in the future. E.g. .sol is not an ICANN TLD today, but feels more likely to be a TLD in the future than say .erc7828 (its too specific) or .eth (its in wide use by ENS).

In my view, any real competitor to ENS would have to have given consideration to ICANN and user experience. Namespace collisions help no-one and as such I think these are fair statements. If someone wanted to create a new naming service using .sol as the extension for example, it would be pragmatic for them to apply for .sol in the root zone as part of the upcoming gTLD process.

Noting this, dot separated subname based chain specific addresses, I think, solve this problem in a flexible and extensible manner…