ERC-7828: Chain-specific addresses using ENS

[teddy]

@clowes.eth

ERC 7785

While I appreciate the feedback (and the context on the ways it affects 7828) I’m trying to decouple 7785 from 7828 since the former tries to solve much harder problems (both at the technical and social-consensus layers) and I’m trying to get the latter finalized on a tighter timeline.

I’d like to focus this thread on 7828 (although including the ways in which it can pave the way for a 7785 future is very much in scope) and have any further discussion happen in its own magicians thread

@clowes.eth

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

Unfortunately there are a few reasons for that:

• It sets a hard blocking between this standard and 7785, meaning 7828 will not be define-able util we have an agreed upon normative spec for 7785, and 7828 Interoperable Names will not be possible to use until 7785 is productive. The currently proposed spec allows to use human-readable names using the best currently available technology, and also upgrade to use 7785 when it’s ready.
• It does not define a way to refer to an address on a chain that is not supported by 7785, meaning users would be exposed to at least two addressing standards. It’s worth noting that given there’s no normative spec of 7785, we can’t really discuss what it’s limitations will be, and therefore it’s an open question which chains would be excluded by this restriction. Some possible options:

  • Some kinds of L2s, due to technical limitations on proving stuff on L1 with L2 data.

  • Any alt-L1

  • In the case where there’s not a permissionless way to register a chain on L2, any chain that has not been given the explicit blessing of whoever owns chaindata.eth.

    While it’s true that an Ethereum standard doesn’t have an obligation to serve the needs of chains outside the ethereum ecosystem (however you define its boundaries), it does have to serve its users by providing a uniform interface for addressing (chain, address) pairs they might encounter in the context of using Ethereum applications, and having a format that’s very different for a chain that works with 7785 than one that doesn’t would be a negative for users.

• (potentially solvable) In the case of an L3 chain, e.g. a chain that’s a rollup of a rollup, how would you differentiate between a name for a chain and a name for an address within that chain?

@nategraf

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

These strike as reasonable demands as well.

@clowes.eth

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.

If we were to do away with the name resolver registry, and instead focus on ENS alone, would you stand behind something like the following?

• human-readable names of addresses are entirely delegated to ENS, allowing for use of DNS-in-ENS and doing away with the ICANN collision issue (still would have to dive deep into ENSIP-6)
• chain part is like above, essentially reserved until ERC-7785 ships, but has an exception on the .short TLD to signify usage of the ethereum-lists/chains list of shortnames, so we can have good-enough human-readable chain names in the meantime
• 1-2 ENSIPs are pushed so chainid/cointype used within ENS are both ERC-7785-proofed and consistent with the definitions of ERC-7930, making implementations easier by minimizing the amounts of translations