Add ERC: Readable Interoperable Addresses using ENS #735
Conversation
eip-review-bot
changed the title
ERCS/erc-chain_specific_addresses.md
Outdated
|
|
||
| The resolution of a `address@chain` on the contrary, imposes that the left-hand resolves to an address and the right-hand to a chain identifier. | ||
|
|
||
| When given a `[email protected]`, the wallet can resolve `rollup.eth` to get a chain identifier and `user.rollup.eth` to get an address. In any other case it fails. |
There was a problem hiding this comment.
This doesn't require a new syntax: When the wallet is resolving user.rollup.eth, the standard resolution process should be resolve to resolve the way you described: resolve rollup.eth to get a chain identifier and user.rollup.eth to get an address.
This approach also allows user.rollup.eth to override this behavior by setting a record for their own preferred chain identifier to use when their ENS name is resolved. *.rollup.eth names will likely never override this, but I'd expect almost every user.eth to want to receive funds on some chain that isn't L1.
ERCS/erc-chain_specific_addresses.md
Outdated
| ``` | ||
| ### Note: default fallbacks | ||
|
|
||
| If a user receives a legacy address without chain name, the wallet can: |
There was a problem hiding this comment.
I don't think any of these fallbacks should be our target behavior. Users should be able to control on which chain assets sent to their ENS name arrive. I think ENS experts should lead the way on this resolution process via an ENSIP.
ERCS/erc-chain_specific_addresses.md
Outdated
| account ::= <user>@<chain> | ||
| ``` | ||
|
|
||
| Note the difference between `ens-name`, which is a full ENS name, and `ens-subdomain` that is just a segment of a name between dots. E.g. `user.app.eth` is a name, `user` and `app` are subdomains. |
There was a problem hiding this comment.
In the below examples, isn't the user also just <address> | <ens-name>?
There was a problem hiding this comment.
In the examples below it's indeed an but if I understand correctly it could also use an ens-subdomain such as [email protected] which might mean something different from [email protected].
The former would resolve user locally on arbitrum, and the latter (being a fully-qualified name) would resolve user.eth on L1. Is that not the intention?
There was a problem hiding this comment.
This actually opens up a very big issue that I believe it’s not discussed here: in theory, user should beuser across the whole Ethereum ecosystem at least, but in fact there are many Domain Name Services beyond ENS that are local to some L2s or even just one.
For example, I have jaack.eth, and also registered jaack.avax on Avalanche C-Chain and jaack.blast on Blast.
First, I believe we should consider ENS as the ‘main router’ for DNS resolutions, because it’s stated as a requirement in the ERC. Since this is the case, then resolution should be global across Ethereum, including rollups. So user needs to be `user.eth on any chain, especially considering that this ERC would likely be implemented around the time that Namechain will be at least on testnet, so the ENS registry is itself on a ‘service’ L2.
@yoavw the case where an address is local only to its chain is the one where most addresses owned by users are smart wallets / accounts that are not the same across chains (unlike EOAs, that have the same pubkey / privkey across any EVM).
Co-authored-by: Andrew B Coathup <[email protected]>
Head branch was pushed to by a user without write access
ERCS/erc-7828.md
Outdated
| ## Abstract | ||
| This proposal builds off of [ERC-7930] (Interoperable Addresses & Names) to provide a standard and human-readable format for chain-specific addresses which provides: |
There was a problem hiding this comment.
| ## Abstract | |
| This proposal builds off of [ERC-7930] (Interoperable Addresses & Names) to provide a standard and human-readable format for chain-specific addresses which provides: | |
| ## Abstract | |
| This proposal builds off of [ERC-7930] (Interoperable Addresses & Names) to provide a standard and human-readable format for chain-specific addresses which provides: |
ERCS/erc-7828.md
Outdated
| ## Motivation | ||
| The current Ethereum address landscape is leading to an ecosystem that will have hundreds and eventually thousands of L2s that use the same address format as Ethereum mainnet. This means an address by itself is not enough information to know which chain the address is related to. This can be problematic if funds are sent to an unreachable address on the incorrect chain. From the user account it should be possible to obtain the right chain identifier (chainID) to include in a transaction. |
There was a problem hiding this comment.
| ## Motivation | |
| The current Ethereum address landscape is leading to an ecosystem that will have hundreds and eventually thousands of L2s that use the same address format as Ethereum mainnet. This means an address by itself is not enough information to know which chain the address is related to. This can be problematic if funds are sent to an unreachable address on the incorrect chain. From the user account it should be possible to obtain the right chain identifier (chainID) to include in a transaction. | |
| ## Motivation | |
| The current Ethereum address landscape is leading to an ecosystem that will have hundreds and eventually thousands of L2s that use the same address format as Ethereum mainnet. This means an address by itself is not enough information to know which chain the address is related to. This can be problematic if funds are sent to an unreachable address on the incorrect chain. From the user account it should be possible to obtain the right chain identifier (chainID) to include in a transaction. |
ERCS/erc-7828.md
Outdated
| ## Specification | ||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. |
There was a problem hiding this comment.
| ## Specification | |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. | |
| ## Specification | |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. |
ERCS/erc-7828.md
Outdated
| ### Format | ||
| This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-7930]. |
There was a problem hiding this comment.
| ### Format | |
| This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-7930]. | |
| ### Format | |
| This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-7930]. |
ERCS/erc-7828.md
Outdated
| ### Checksum | ||
| Addresses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-7930] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. |
There was a problem hiding this comment.
| ### Checksum | |
| Addresses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-7930] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. | |
| ### Checksum | |
| Addresses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-7930] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. |
ERCS/erc-7828.md
Outdated
| ### Reverse Resolution step-by-step example | ||
| Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00010002` |
There was a problem hiding this comment.
| ### Reverse Resolution step-by-step example | |
| Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00010002` | |
| ### Reverse Resolution step-by-step example | |
| Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00010002` |
ERCS/erc-7828.md
Outdated
| ## Rationale | ||
| - We chose to use a centralized list of name registries, aka a [^name resolver registry], since mapping of chain names to chain ids, aka on-chain configs (as proposed in [ERC-7785]) are not yet a solved problem. Therefore there is a need to maintain a list of possible implementations, including stopgap solutions such as relying on ethereum-lists/chains. |
There was a problem hiding this comment.
| ## Rationale | |
| - We chose to use a centralized list of name registries, aka a [^name resolver registry], since mapping of chain names to chain ids, aka on-chain configs (as proposed in [ERC-7785]) are not yet a solved problem. Therefore there is a need to maintain a list of possible implementations, including stopgap solutions such as relying on ethereum-lists/chains. | |
| ## Rationale | |
| - We chose to use a centralized list of name registries, aka a [^name resolver registry], since mapping of chain names to chain ids, aka on-chain configs (as proposed in [ERC-7785]) are not yet a solved problem. Therefore there is a need to maintain a list of possible implementations, including stopgap solutions such as relying on ethereum-lists/chains. |
| ## Rationale | ||
| - We chose to use a centralized list of name registries, aka a [^name resolver registry], since mapping of chain names to chain ids, aka on-chain configs (as proposed in [ERC-7785]) are not yet a solved problem. Therefore there is a need to maintain a list of possible implementations, including stopgap solutions such as relying on ethereum-lists/chains. | ||
|
|
||
| ## Open Discussions |
There was a problem hiding this comment.
| ## Open Discussions | |
| ## Open Discussions | |
ERCS/erc-7828.md
Outdated
| ## Backwards Compatibility | ||
| The naming scheme herein defined can represent all names supported by [ERC-7930] by displaying raw addresses without resolution |
There was a problem hiding this comment.
| ## Backwards Compatibility | |
| The naming scheme herein defined can represent all names supported by [ERC-7930] by displaying raw addresses without resolution | |
| ## Backwards Compatibility | |
| The naming scheme herein defined can represent all names supported by [ERC-7930] by displaying raw addresses without resolution |
ERCS/erc-7828.md
Outdated
| ## Security Considerations | ||
| - By coupling the domain's TLD to a known resolution method, we avoid the case where the same human-readable name is registered on different naming registries pointing to different addresses, which would only have the address' 4-byte checksum as a mitigation on users sending funds to unintended addresses. |
There was a problem hiding this comment.
| ## Security Considerations | |
| - By coupling the domain's TLD to a known resolution method, we avoid the case where the same human-readable name is registered on different naming registries pointing to different addresses, which would only have the address' 4-byte checksum as a mitigation on users sending funds to unintended addresses. | |
| ## Security Considerations | |
| - By coupling the domain's TLD to a known resolution method, we avoid the case where the same human-readable name is registered on different naming registries pointing to different addresses, which would only have the address' 4-byte checksum as a mitigation on users sending funds to unintended addresses. |
eip-review-bot
changed the title
…ding to refer to l2.eth
eip-review-bot
changed the title
eip-review-bot
changed the title
| <!-- TODO: find a few more edge cases or get rid of the ul --> | ||
|
|
||
| #### Supported CASA namespaces | ||
| Forward resolution (Interoperable Address -> Interoperable Name): `eip155` (via ENSIP-11) and anything supported by SLIP-0044, as defined in ENSIP-9. |
There was a problem hiding this comment.
ENSIPs are not currently permitted for external links. Instead use the ERC (might be eip-2304?)
ERCS/erc-7828.md
Outdated
| ## Open Discussions | ||
| - Further constrain the syntax of human-readable names to minimize: | ||
| - Collisions on names by e.g. UTS46 case folding | ||
| - Addresses that are valid ERC-7828 but cant be squeezed into ENS or comparable standards | ||
| - Conflicts with existing standards: | ||
| - ENSIP-11 defines the bitmask to use for `eip155` `coinType` assuming chainids are 31 bits or shorter, which is in conflict with [ERC-7785] and the addresses representable in [ERC-7930]. |
There was a problem hiding this comment.
These kind of sections end up being problematic in Final proposals. They tend to get frozen in time, and cannot be updated. Instead, put this in an <!-- HTML-style comment --> and the linter will ensure it gets removed before advancing.
feat: migrate to onchain chain name resolution
|
The commit 9aa2b40 (as a parent of addcc58) contains errors. |
No description provided.