From 520176f3159f74debdd14009b2a17899549c53ba Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 00:00:33 -0800 Subject: [PATCH 01/37] Create erc-chain_specific_addresses --- ERCS/erc-chain_specific_addresses | 1 + 1 file changed, 1 insertion(+) create mode 100644 ERCS/erc-chain_specific_addresses diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses new file mode 100644 index 00000000000..8b137891791 --- /dev/null +++ b/ERCS/erc-chain_specific_addresses @@ -0,0 +1 @@ + From 2074bbd5a7206958d2e5ebc343e8f06069790fb4 Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 01:07:50 -0800 Subject: [PATCH 02/37] Update erc-chain_specific_addresses --- ERCS/erc-chain_specific_addresses | 170 ++++++++++++++++++++++++++++++ 1 file changed, 170 insertions(+) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index 8b137891791..9ce8d72e300 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -1 +1,171 @@ +--- +title: Chain-specific addresses using ENS +description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. +author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin) +discussions-to: +status: Draft +type: Standards Track +category: ERC +created: 2024-11-27 +requires: 7785 +--- +## Abstract + +This document builds off of ERC-7785 (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: +- A unified format for accounts that specifies, together with the address, the chain where the address lives. +- The use of human-readable chain names and how they can be resolved to chain identifiers using ENS on L1. +- The use of human-readable account names and how they can be resolved to addresses using ENS on L2. + +## 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. + +The mapping from chain names to identifiers has, since [EIP-155], been maintained off chain using a centralized list. This solution has two main shortcomings: + - It does not scale with the growing number of L2s. + - The list maintainer is a trusted centralized entity. + +Instead of using chain identifiers, which are not human readable, the address could be extended with a human-readable chain name, which can then be resolved to a chain identifier. +The mapping from chain names to identifiers can be resolved off-chain using existing centralized lists such as [Ethereum Lists](https://github.com/ethereum-lists/chains) or on-chain using ENS (see EIP-7785). + +In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. However it would be desirable if the address name could be registered on a L2. + +Desired properties: +- a unified format to represent any address on L1 or L2 +- the ability to use chain names in addition to identifiers +- the ability to use ENS names in addition to addresses +- the ability to resolve ENS names on the L2 + +## 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. + +### Format + +Valid addresses MUST include the identifier of the chain they belong to. + +``` +L1-TLD ::= eth | sepolia | … +chain_id ::= 0x[a-fA-F0-9]{1,64} +address ::= 0x[a-fA-F0-9]{40} +chain ::= | | . +user ::=
| +account ::= @ +``` + +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. + +A few examples below. + +Option 1: using @ +``` +#Mainnet +- 0x12345...6789@0x1 +- 0x12345...6789@eth +- alice.eth@eth + +#Testnet (Sepolia) +- 0x12345...6789@0xaa36a7 +- 0x12345...6789@sepolia +- alice.eth@sepolia + +#Rollup# +- 0x12345...6789@chainId +- 0x12345...6789@arbitrum.eth +- alice.eth@arbitrum.eth + +#Rollup Sepolia +- 0x12345...6789@arbitrum.sepolia + +#My ENS name is registered on rollupX, but I want to receive funds on rollupY +- alice.base.eth@arbitrum.eth +``` + +Option 2: using : instead of @ +``` +#Mainnet +- 0x12345...6789:0x1 +- 0x12345...6789:eth +- alice.eth:eth + +#Testnet (Sepolia) +- 0x12345...6789:0xaa36a7 +- 0x12345...6789:sepolia +- alice.eth:sepolia + +#Rollup# +- 0x12345...6789:chainId +- 0x12345...6789:arbitrum.eth +- alice.eth:arbitrum.eth + +#Rollup Sepolia +- 0x12345...6789:arbitrum.sepolia + +#My ENS name is registered on rollupX, but I want to receive funds on rollupY +- alice.base.eth:arbitrum.eth +``` + +## Rationale + + + +TBD + +## Backwards Compatibility + + + +No backward compatibility issues found. + +## Test Cases + + + +## Reference Implementation + + + +## Security Considerations + + + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 94a581dbb9a5ebfe317b5d38f34f60f0e63c517f Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 01:45:16 -0800 Subject: [PATCH 03/37] Update erc-chain_specific_addresses --- ERCS/erc-chain_specific_addresses | 158 +++++++++++++++++++++--------- 1 file changed, 113 insertions(+), 45 deletions(-) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index 9ce8d72e300..7733d9933cf 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -33,8 +33,13 @@ In the same spirit, the address could be a human-readable name as well, which is Desired properties: - a unified format to represent any address on L1 or L2 - the ability to use chain names in addition to identifiers -- the ability to use ENS names in addition to addresses +- the chain portion can be a domain name, or just the suffix for a "base chain" (eg. `eth`, `myfavoriterollup.eth`, `sepolia`, `my_l3.base.superchain.eth`) +- the address portion can be either the appropriate type of address for the chain (0x... for EVM chains, otherwise eg. for starknet something else), or a domain name (ENS or other) - the ability to resolve ENS names on the L2 +- the address portion and the chain portion should be resolved separately +- checksums are MANDATORY +- checksum hash goes over the entire address, so users can't just replace a component and expect it to stay valid + ## Specification @@ -59,112 +64,175 @@ A few examples below. Option 1: using @ ``` -#Mainnet +Mainnet - 0x12345...6789@0x1 - 0x12345...6789@eth - alice.eth@eth -#Testnet (Sepolia) +Testnet (Sepolia) - 0x12345...6789@0xaa36a7 - 0x12345...6789@sepolia - alice.eth@sepolia -#Rollup# +Rollup - 0x12345...6789@chainId - 0x12345...6789@arbitrum.eth - alice.eth@arbitrum.eth -#Rollup Sepolia +Rollup Sepolia - 0x12345...6789@arbitrum.sepolia -#My ENS name is registered on rollupX, but I want to receive funds on rollupY -- alice.base.eth@arbitrum.eth +My ENS name is registered on rollup1, but I want to receive funds on rollup2 +- alice.rollup1.eth@rollup2.eth ``` Option 2: using : instead of @ ``` -#Mainnet +Mainnet - 0x12345...6789:0x1 - 0x12345...6789:eth - alice.eth:eth -#Testnet (Sepolia) +Testnet (Sepolia) - 0x12345...6789:0xaa36a7 - 0x12345...6789:sepolia - alice.eth:sepolia -#Rollup# +Rollup - 0x12345...6789:chainId - 0x12345...6789:arbitrum.eth - alice.eth:arbitrum.eth -#Rollup Sepolia +Rollup Sepolia - 0x12345...6789:arbitrum.sepolia -#My ENS name is registered on rollupX, but I want to receive funds on rollupY -- alice.base.eth:arbitrum.eth +My ENS name is registered on rollup1, but I want to receive funds on rollup2 +- alice.rollup1.eth:rollup2.eth ``` +### CHECKSUM +TODO: add more explanation here -## Rationale +Two desired properties: +1) checksums are MANDATORY +2) checksum hash goes over the entire address, so users can't just go and replace a component and expect it to stay valid - +Any ENS name today can be resolved to a chain identifier as in [ENSIP-11](https://docs.ens.domains/ensip/11) or to an address as in [ENSIP-9](https://docs.ens.domains/ensip/9). +We could imagine having a name `user.eth` that points to a record of the form `{address ; chain_id}`. Given such an address a wallet can verify it resolves to a valid account. +The advantage of this format is that it is very flexible and can accommodate a number of use cases, however it can also lead to confusion for users because a name does not necessarily resolve to a valid account. The same `user.eth` could lead to a website, a NFT or multiple addresses. -TBD +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. -## Backwards Compatibility +When given a `user@rollup.eth`, 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. - +In order to avoid contacting an external http gateway, we could define the gateway to be a ENS contract on the L2. In this way a wallet operator would need to only rely on a node following the L1 and a node following the L2. -No backward compatibility issues found. +### L1 resolution -## Test Cases +Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a [centralized list](https://chainid.network/chains.json), which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP. - +In the above proposal the ENS TLD and chain name coincide which may be confusing or incorrect in some cases. A more explicit approach could be to have an additional suffix for the chain name. +Example: +``` +name.eth.mainnet -> {L1_chain_id : 0x1; L1_ens_address : } +name.eth.sepolia -> {L1_chain_id : 0xaa36a7; L1_ens_address : } +``` +### Note: default fallbacks -## Reference Implementation +If a user receives a legacy address without chain name, the wallet can: +Refuse the address (safest) +Default to Mainnet (unambiguous) +Dynamically default to same chainID as sender (ambiguous and context-dependent but probably compatible with current use-cases) - +### Supported today -## Security Considerations +For example a user might configure its name with multiple address such as +``` +rollup1.user.eth -> {address : address; chain_id : chain_id} +rollup2.user.eth -> {address : address; chain_id : chain_id} +``` +Given `user.eth` as recipient a wallet could prompt the user to select a destination chain. +Otherwise the user can be more explicit and give as recipient `rollup1.user.eth`. + +### Note: Speculative + +Alternatively we could store multiple addressed under the same domain as +``` +user.eth -> { rollup1 : address * chain_id ; + rollup2 : address * chain_id } +``` +if a syntax to access ENS records could be standardized, the user could be asked to be paid at +`user.eth/rollup1` + +### URL compatibility + +It would be very desirable to maintain compatibility with the syntax defined by the [Uniform Resource Identifier](https://www.rfc-editor.org/rfc/rfc3986) standard, so that in the future a schema could be supported. + +Example of a link to require a payment of 10 tokens to the `user` address living in `rollup`: +``` +evm://user@rollup.eth.mainnet/transfer?amount=10 +``` + +### Resolution step-by-step example + +1. Check the type of `chain` + - if typeof(chain) == “ENS name”: go to step 2 + - if typeof(chain) == “L1 TLD”: go to step 3 + - if typeof(chain) == “chainId”: go to step 4 +2. Resolve the ENS name's `text(chainENSName, ‘chain_id’)` record using [ENSIP-10](https://docs.ens.domains/ensip/10) and skip to step 4 +3. Use an offline mapping of `TLD => chainId` to find the relevant chainId. +4. Check if `account` is an ENS name, if not end the resolution process. +5. Generate the cointype using the chainId via ENSIP-11: `coinType = 0x80000000 | chainId` +6. Verify the bridge address by resolving `[chainId].id.eth`'s `name(name, 60)` record using [ENSIP-10](https://docs.ens.domains/ensip/10) +7. Check if this name matches the ENS name representing the chain, continue otherwise consider the resolution a failure and error. +8. Resolve the ENS name's `addr(name, cointype)` + +## Rationale -Needs discussion. +TBD + +## Backwards Compatibility + +No backward compatibility issues found. + +## Security Considerations + +tbd ## Copyright From 7db61f032dd39a66b8a68e46489bb69755350329 Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 01:47:01 -0800 Subject: [PATCH 04/37] Update erc-chain_specific_addresses --- ERCS/erc-chain_specific_addresses | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index 7733d9933cf..4f5000bb45f 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -216,15 +216,7 @@ evm://user@rollup.eth.mainnet/transfer?amount=10 ## Rationale - - -TBD +todo ## Backwards Compatibility @@ -232,7 +224,7 @@ No backward compatibility issues found. ## Security Considerations -tbd +todo ## Copyright From d1eb6b8e4b6cb146b6b6300ae86c6cd7fce6f719 Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 01:52:09 -0800 Subject: [PATCH 05/37] Update erc-chain_specific_addresses --- ERCS/erc-chain_specific_addresses | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index 4f5000bb45f..a39b67eee01 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -12,7 +12,7 @@ requires: 7785 ## Abstract -This document builds off of ERC-7785 (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: +This proposal builds off of ERC-7785 (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: - A unified format for accounts that specifies, together with the address, the chain where the address lives. - The use of human-readable chain names and how they can be resolved to chain identifiers using ENS on L1. - The use of human-readable account names and how they can be resolved to addresses using ENS on L2. @@ -21,7 +21,7 @@ This document builds off of ERC-7785 (on-chain configs) to provide a standard an 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. -The mapping from chain names to identifiers has, since [EIP-155], been maintained off chain using a centralized list. This solution has two main shortcomings: +The mapping from chain names to identifiers has, since EIP-155, been maintained off chain using a centralized list. This solution has two main shortcomings: - It does not scale with the growing number of L2s. - The list maintainer is a trusted centralized entity. @@ -62,7 +62,7 @@ Note the difference between `ens-name`, which is a full ENS name, and `ens-subdo A few examples below. -Option 1: using @ +Option 1: using @ to separate address and chain ``` Mainnet - 0x12345...6789@0x1 @@ -216,7 +216,7 @@ evm://user@rollup.eth.mainnet/transfer?amount=10 ## Rationale -todo +TODO ## Backwards Compatibility @@ -224,7 +224,7 @@ No backward compatibility issues found. ## Security Considerations -todo +TODO ## Copyright From 6595ed256d173fe1a1168448c7c2619d141cb49c Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 01:56:48 -0800 Subject: [PATCH 06/37] Update erc-chain_specific_addresses --- ERCS/erc-chain_specific_addresses | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index a39b67eee01..9b68ee6a440 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -216,7 +216,13 @@ evm://user@rollup.eth.mainnet/transfer?amount=10 ## Rationale -TODO +### Separator Choice + +The colon (`:`) may be a reasonable choice for separator because it is not an allowed character in ENS names, it is familiar (eg. IPv6), and isn't as overloaded as the `@` symbol. + +#### Alternative: `@` + +The `@` symbol may be a reasonable choice as it is arguably more human-readable, is already a common choice for addresses, and finds use in email and several federated communication protocols. The English reading (foo-**AT**-example-DOT-com) is natural and implies a hierarchy between the left and the right components. ## Backwards Compatibility From 9482704f1543b50f6c22ef3656e8a34584b8a297 Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 02:09:46 -0800 Subject: [PATCH 07/37] rationale update --- ERCS/erc-chain_specific_addresses | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index 9b68ee6a440..f27ac6de8e1 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -216,12 +216,10 @@ evm://user@rollup.eth.mainnet/transfer?amount=10 ## Rationale -### Separator Choice +#### Using @ vs : for the separator The colon (`:`) may be a reasonable choice for separator because it is not an allowed character in ENS names, it is familiar (eg. IPv6), and isn't as overloaded as the `@` symbol. -#### Alternative: `@` - The `@` symbol may be a reasonable choice as it is arguably more human-readable, is already a common choice for addresses, and finds use in email and several federated communication protocols. The English reading (foo-**AT**-example-DOT-com) is natural and implies a hierarchy between the left and the right components. ## Backwards Compatibility From ec2bd975dacea4de68d61e12052bbfadc45cdd8d Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 02:12:28 -0800 Subject: [PATCH 08/37] require EIPs --- ERCS/erc-chain_specific_addresses | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses index f27ac6de8e1..a3eae2c9306 100644 --- a/ERCS/erc-chain_specific_addresses +++ b/ERCS/erc-chain_specific_addresses @@ -7,7 +7,7 @@ status: Draft type: Standards Track category: ERC created: 2024-11-27 -requires: 7785 +requires: 55, 137, 155, 7785 --- ## Abstract From 32b82765e27916921a526a81b1763bf9d3c455de Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Wed, 27 Nov 2024 09:56:53 -0500 Subject: [PATCH 09/37] Rename erc-chain_specific_addresses to erc-chain_specific_addresses.md --- ...c-chain_specific_addresses => erc-chain_specific_addresses.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ERCS/{erc-chain_specific_addresses => erc-chain_specific_addresses.md} (100%) diff --git a/ERCS/erc-chain_specific_addresses b/ERCS/erc-chain_specific_addresses.md similarity index 100% rename from ERCS/erc-chain_specific_addresses rename to ERCS/erc-chain_specific_addresses.md From d988615f2d3357160a1443dfe7bfc009230327ae Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Mon, 2 Dec 2024 09:50:09 -0800 Subject: [PATCH 10/37] add EIP number Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- ERCS/erc-chain_specific_addresses.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ERCS/erc-chain_specific_addresses.md b/ERCS/erc-chain_specific_addresses.md index a3eae2c9306..ea3eeec6788 100644 --- a/ERCS/erc-chain_specific_addresses.md +++ b/ERCS/erc-chain_specific_addresses.md @@ -1,4 +1,5 @@ --- +eip: 7828 title: Chain-specific addresses using ENS description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin) From 680bd56e60f062c367ddc7b7eede76b3e384efd8 Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Mon, 2 Dec 2024 09:51:58 -0800 Subject: [PATCH 11/37] add eth magicians URL --- ERCS/erc-chain_specific_addresses.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-chain_specific_addresses.md b/ERCS/erc-chain_specific_addresses.md index ea3eeec6788..78e9c5e3c42 100644 --- a/ERCS/erc-chain_specific_addresses.md +++ b/ERCS/erc-chain_specific_addresses.md @@ -3,7 +3,7 @@ eip: 7828 title: Chain-specific addresses using ENS description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses/21930 status: Draft type: Standards Track category: ERC From f860b00ae6bffe69f5b5cef22411c87ff59b9c16 Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Mon, 2 Dec 2024 09:52:33 -0800 Subject: [PATCH 12/37] Rename erc-chain_specific_addresses.md to erc-7828.md --- ERCS/{erc-chain_specific_addresses.md => erc-7828.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename ERCS/{erc-chain_specific_addresses.md => erc-7828.md} (100%) diff --git a/ERCS/erc-chain_specific_addresses.md b/ERCS/erc-7828.md similarity index 100% rename from ERCS/erc-chain_specific_addresses.md rename to ERCS/erc-7828.md From 314898631b82f3a5f88fb3fed15e99d20ffdbf0f Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Mon, 2 Dec 2024 21:04:27 -0800 Subject: [PATCH 13/37] Update ERCS/erc-7828.md Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com> --- ERCS/erc-7828.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 78e9c5e3c42..a6cee9bbaa9 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -3,7 +3,7 @@ eip: 7828 title: Chain-specific addresses using ENS description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin) -discussions-to: https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses/21930 +discussions-to: https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses-using-ens/21930 status: Draft type: Standards Track category: ERC From bb75a00c06fde2e1f844bc48c5afd5c46766cf10 Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Tue, 3 Dec 2024 10:15:05 -0500 Subject: [PATCH 14/37] Update erc-7828.md --- ERCS/erc-7828.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index a6cee9bbaa9..748a51983b2 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -13,7 +13,7 @@ requires: 55, 137, 155, 7785 ## Abstract -This proposal builds off of ERC-7785 (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: +This proposal builds off of [ERC-7785](./eip-7785.md) (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: - A unified format for accounts that specifies, together with the address, the chain where the address lives. - The use of human-readable chain names and how they can be resolved to chain identifiers using ENS on L1. - The use of human-readable account names and how they can be resolved to addresses using ENS on L2. @@ -22,12 +22,12 @@ This proposal builds off of ERC-7785 (on-chain configs) to provide a standard an 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. -The mapping from chain names to identifiers has, since EIP-155, been maintained off chain using a centralized list. This solution has two main shortcomings: +The mapping from chain names to identifiers has, since [EIP-155](./eip-155.md), been maintained off chain using a centralized list. This solution has two main shortcomings: - It does not scale with the growing number of L2s. - The list maintainer is a trusted centralized entity. Instead of using chain identifiers, which are not human readable, the address could be extended with a human-readable chain name, which can then be resolved to a chain identifier. -The mapping from chain names to identifiers can be resolved off-chain using existing centralized lists such as [Ethereum Lists](https://github.com/ethereum-lists/chains) or on-chain using ENS (see EIP-7785). +The mapping from chain names to identifiers can be resolved off-chain using existing centralized lists or on-chain using ENS (see EIP-7785). In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. However it would be desirable if the address name could be registered on a L2. @@ -111,7 +111,7 @@ My ENS name is registered on rollup1, but I want to receive funds on rollup2 - alice.rollup1.eth:rollup2.eth ``` ### CHECKSUM -TODO: add more explanation here + Two desired properties: 1) checksums are MANDATORY @@ -120,7 +120,7 @@ Two desired properties: ### A special case for ENS resolution -Any ENS name today can be resolved to a chain identifier as in [ENSIP-11](https://docs.ens.domains/ensip/11) or to an address as in [ENSIP-9](https://docs.ens.domains/ensip/9). +Any ENS name today can be resolved to a chain identifier or to an address. We could imagine having a name `user.eth` that points to a record of the form `{address ; chain_id}`. Given such an address a wallet can verify it resolves to a valid account. The advantage of this format is that it is very flexible and can accommodate a number of use cases, however it can also lead to confusion for users because a name does not necessarily resolve to a valid account. The same `user.eth` could lead to a website, a NFT or multiple addresses. @@ -130,7 +130,7 @@ When given a `user@rollup.eth`, the wallet can resolve `rollup.eth` to get a cha ### L2 resolution -In case an address is not registered on L1, but only on a L2, the resolution can be processed using [CCIP-Read EIP](https://eips.ethereum.org/EIPS/eip-3668) and [ENSIP-10 Wildcard Resolution](https://docs.ens.domains/ensip/10). +In case an address is not registered on L1, but only on a L2, the resolution can be processed using [ERC-3668](./eip-3668.md) and [ERC-2544](./eip-2544.md)'s Wildcard Resolution. In the previous example `user@rollup.eth`, `user` would not be registered on L1. In this case the wallet can resolve `rollup.eth` to get a chain identifier as before and when attempting to resolve `user.rollup.eth` to get an address, it would fail and be redirected to the L2 gateway. Any answer from the gateway needs to be verified as explained in the EIP. @@ -141,7 +141,7 @@ In order to avoid contacting an external http gateway, we could define the gatew ### L1 resolution -Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a [centralized list](https://chainid.network/chains.json), which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP. +Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a centralized list, which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP. Mapping: ``` @@ -207,11 +207,11 @@ evm://user@rollup.eth.mainnet/transfer?amount=10 - if typeof(chain) == “ENS name”: go to step 2 - if typeof(chain) == “L1 TLD”: go to step 3 - if typeof(chain) == “chainId”: go to step 4 -2. Resolve the ENS name's `text(chainENSName, ‘chain_id’)` record using [ENSIP-10](https://docs.ens.domains/ensip/10) and skip to step 4 +2. Resolve the ENS name's `text(chainENSName, ‘chain_id’)` record using [ERC-2544](./eip-2544.md) and skip to step 4 3. Use an offline mapping of `TLD => chainId` to find the relevant chainId. 4. Check if `account` is an ENS name, if not end the resolution process. 5. Generate the cointype using the chainId via ENSIP-11: `coinType = 0x80000000 | chainId` -6. Verify the bridge address by resolving `[chainId].id.eth`'s `name(name, 60)` record using [ENSIP-10](https://docs.ens.domains/ensip/10) +6. Verify the bridge address by resolving `[chainId].id.eth`'s `name(name, 60)` record using [ERC-2544](./eip-2544.md) 7. Check if this name matches the ENS name representing the chain, continue otherwise consider the resolution a failure and error. 8. Resolve the ENS name's `addr(name, cointype)` @@ -229,7 +229,7 @@ No backward compatibility issues found. ## Security Considerations -TODO + ## Copyright From 105cc6d870e9ae0aecf44cee0b2e722fa16f09b3 Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Tue, 3 Dec 2024 10:15:48 -0500 Subject: [PATCH 15/37] Update erc-7828.md --- ERCS/erc-7828.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 748a51983b2..a2bc5f6ea5b 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -1,7 +1,7 @@ --- eip: 7828 title: Chain-specific addresses using ENS -description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. +description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin) discussions-to: https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses-using-ens/21930 status: Draft From d740aa0e761f9d2132cff070a85e3c47ee404fdd Mon Sep 17 00:00:00 2001 From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> Date: Tue, 3 Dec 2024 10:16:21 -0500 Subject: [PATCH 16/37] Update erc-7828.md --- ERCS/erc-7828.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index a2bc5f6ea5b..a9d96117b2d 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -27,7 +27,7 @@ The mapping from chain names to identifiers has, since [EIP-155](./eip-155.md), - The list maintainer is a trusted centralized entity. Instead of using chain identifiers, which are not human readable, the address could be extended with a human-readable chain name, which can then be resolved to a chain identifier. -The mapping from chain names to identifiers can be resolved off-chain using existing centralized lists or on-chain using ENS (see EIP-7785). +The mapping from chain names to identifiers can be resolved off-chain using existing centralized lists or on-chain using ENS (see ERC-7785). In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. However it would be desirable if the address name could be registered on a L2. From 5a08fa5b0f15bb9c9087f702d2f89cb8cbefe4c8 Mon Sep 17 00:00:00 2001 From: teddy Date: Fri, 11 Apr 2025 14:17:39 -0300 Subject: [PATCH 17/37] remove least normative & open discussons --- ERCS/erc-7828.md | 86 +----------------------------------------------- 1 file changed, 1 insertion(+), 85 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index a9d96117b2d..3c1b08c273d 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -47,7 +47,6 @@ Desired properties: 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. ### Format - Valid addresses MUST include the identifier of the chain they belong to. ``` @@ -61,9 +60,7 @@ account ::= @ 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. -A few examples below. - -Option 1: using @ to separate address and chain +A few examples below: ``` Mainnet - 0x12345...6789@0x1 @@ -87,29 +84,6 @@ My ENS name is registered on rollup1, but I want to receive funds on rollup2 - alice.rollup1.eth@rollup2.eth ``` -Option 2: using : instead of @ -``` -Mainnet -- 0x12345...6789:0x1 -- 0x12345...6789:eth -- alice.eth:eth - -Testnet (Sepolia) -- 0x12345...6789:0xaa36a7 -- 0x12345...6789:sepolia -- alice.eth:sepolia - -Rollup -- 0x12345...6789:chainId -- 0x12345...6789:arbitrum.eth -- alice.eth:arbitrum.eth - -Rollup Sepolia -- 0x12345...6789:arbitrum.sepolia - -My ENS name is registered on rollup1, but I want to receive funds on rollup2 -- alice.rollup1.eth:rollup2.eth -``` ### CHECKSUM @@ -135,10 +109,6 @@ In case an address is not registered on L1, but only on a L2, the resolution can In the previous example `user@rollup.eth`, `user` would not be registered on L1. In this case the wallet can resolve `rollup.eth` to get a chain identifier as before and when attempting to resolve `user.rollup.eth` to get an address, it would fail and be redirected to the L2 gateway. Any answer from the gateway needs to be verified as explained in the EIP. -#### Note: avoiding the http gateway - -In order to avoid contacting an external http gateway, we could define the gateway to be a ENS contract on the L2. In this way a wallet operator would need to only rely on a node following the L1 and a node following the L2. - ### L1 resolution Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a centralized list, which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP. @@ -153,54 +123,6 @@ eth -> {L1_chain_id : 0x1; L1_ens_address : } sepolia -> {L1_chain_id : 0xaa36a7; L1_ens_address : } ``` -### Note: clashes of L1 and TLD - -In the above proposal the ENS TLD and chain name coincide which may be confusing or incorrect in some cases. A more explicit approach could be to have an additional suffix for the chain name. -Example: -``` -name.eth.mainnet -> {L1_chain_id : 0x1; L1_ens_address : } -name.eth.sepolia -> {L1_chain_id : 0xaa36a7; L1_ens_address : } -``` -### Note: default fallbacks - -If a user receives a legacy address without chain name, the wallet can: -Refuse the address (safest) -Default to Mainnet (unambiguous) -Dynamically default to same chainID as sender (ambiguous and context-dependent but probably compatible with current use-cases) - -### Advanced patterns - -The `@` syntax described in this EIP is a restricted resolution case for ENS names whose main purpose it to be user-friendly. We can however support more advanced pattern in ENS. - -### Supported today - -For example a user might configure its name with multiple address such as -``` -rollup1.user.eth -> {address : address; chain_id : chain_id} -rollup2.user.eth -> {address : address; chain_id : chain_id} -``` -Given `user.eth` as recipient a wallet could prompt the user to select a destination chain. -Otherwise the user can be more explicit and give as recipient `rollup1.user.eth`. - -### Note: Speculative - -Alternatively we could store multiple addressed under the same domain as -``` -user.eth -> { rollup1 : address * chain_id ; - rollup2 : address * chain_id } -``` -if a syntax to access ENS records could be standardized, the user could be asked to be paid at -`user.eth/rollup1` - -### URL compatibility - -It would be very desirable to maintain compatibility with the syntax defined by the [Uniform Resource Identifier](https://www.rfc-editor.org/rfc/rfc3986) standard, so that in the future a schema could be supported. - -Example of a link to require a payment of 10 tokens to the `user` address living in `rollup`: -``` -evm://user@rollup.eth.mainnet/transfer?amount=10 -``` - ### Resolution step-by-step example 1. Check the type of `chain` @@ -217,12 +139,6 @@ evm://user@rollup.eth.mainnet/transfer?amount=10 ## Rationale -#### Using @ vs : for the separator - -The colon (`:`) may be a reasonable choice for separator because it is not an allowed character in ENS names, it is familiar (eg. IPv6), and isn't as overloaded as the `@` symbol. - -The `@` symbol may be a reasonable choice as it is arguably more human-readable, is already a common choice for addresses, and finds use in email and several federated communication protocols. The English reading (foo-**AT**-example-DOT-com) is natural and implies a hierarchy between the left and the right components. - ## Backwards Compatibility No backward compatibility issues found. From d987f632873beef49cfb634c3fefdab4a3275bda Mon Sep 17 00:00:00 2001 From: teddy Date: Fri, 11 Apr 2025 18:39:55 -0300 Subject: [PATCH 18/37] syntax & high-level registry list spec --- ERCS/erc-7828.md | 82 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 60 insertions(+), 22 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 3c1b08c273d..e5a525b9ecd 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -12,14 +12,12 @@ requires: 55, 137, 155, 7785 --- ## Abstract - This proposal builds off of [ERC-7785](./eip-7785.md) (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: - A unified format for accounts that specifies, together with the address, the chain where the address lives. - The use of human-readable chain names and how they can be resolved to chain identifiers using ENS on L1. - The use of human-readable account names and how they can be resolved to addresses using ENS on L2. ## 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. The mapping from chain names to identifiers has, since [EIP-155](./eip-155.md), been maintained off chain using a centralized list. This solution has two main shortcomings: @@ -41,24 +39,35 @@ Desired properties: - checksums are MANDATORY - checksum hash goes over the entire address, so users can't just replace a component and expect it to stay valid - ## 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. ### Format -Valid addresses MUST include the identifier of the chain they belong to. +This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-X]. ``` -L1-TLD ::= eth | sepolia | … -chain_id ::= 0x[a-fA-F0-9]{1,64} -address ::= 0x[a-fA-F0-9]{40} -chain ::= | | . -user ::=
| -account ::= @ +: :=
@# +
: := | +: := | +: := [0-9A-F]{8} + +: := [.-:_%a-zA-Z0-9]* +: := [.-:_a-zA-Z0-9]* +: := . +: := [_a-zA-Z0-9]{1,10} ``` -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. +Where: + +- `` : Corresponds to a full, resolvable name on the registry defined by its `L0-TLD` +- ``, `` and `` are defined to maintain backwards compatibility with [ERC-X], and their semantics remain the same. +- ``: Corresponds to an entry in the centralized [name resolver registry] + +- ``: Is a valid punycode string without `.` separators. + +Note the difference between ``, which is a fully qualified name, and `subdomain` that is just a segment of a name between dots. E.g. `user.app.eth` is a scoped name, `user` and `app` are subdomains. + +This allows for Interoperable Addresses' text representation to mix and match 'resolved' and 'unresolved' usages in both the chain and address parts. A few examples below: ``` @@ -84,13 +93,10 @@ My ENS name is registered on rollup1, but I want to receive funds on rollup2 - alice.rollup1.eth@rollup2.eth ``` -### CHECKSUM - - -Two desired properties: -1) checksums are MANDATORY -2) checksum hash goes over the entire address, so users can't just go and replace a component and expect it to stay valid +### Checksum +Addreses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-X] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. +This has the property of the checksum changing if any part of the address or chainid is modified, making dangerous manual modification of addresses an error case for wallet users, and also mitigates collisions where the same name is registered to separate addresses on ### A special case for ENS resolution @@ -123,8 +129,30 @@ eth -> {L1_chain_id : 0x1; L1_ens_address : } sepolia -> {L1_chain_id : 0xaa36a7; L1_ens_address : } ``` -### Resolution step-by-step example +### The Name Resolver Registry +We propose for this ERC to strive to reach Final status instead of becoming a Living document, and maintain a separate dictionary for the different name resolving protocols or methods, similar to ethereum-lists/chains. + +The keys of this list will be ``s, and their associated values should be: +- Chain naming section + - The set of CASA namespaces on which the registry can provide names for chains. + - An unambiguously implementable specification of how to obtain a name for a chain id. + - An unambiguously implementable specification of how to obtain a chain id, given a network name. + - The sources of truth the algorithms above should use. +- Address naming section + - The set of CASA namespaces on which the registry can provide names for addresses + - An unambiguously implementable specification of how to obtain a name for an address. + - An unambiguously implementable specification of how to obtain a machine address, given a name. + - The sources of truth the algorithms above should use. + + + +It is worth noting that: +- The same `` can map to different algorithms and/or data for chains and addresses. e.g. if ERC-7785 is published as an ENS product, using `.eth` on a chain name will use a different algorithm for resolution than if the same TLD were used on an address. +- A given protocol may have more than one TLD assigned to it, to avoid having to store the chainid & address of the name resolver on the Interoperable Address itself. An example of this would be to use different addresses for the testnet & mainnet ENS deployments. + +This is an easier list to maintain than ethereum-lists/chains, since it does not have to list every single chain, and the problem of knowing which contracts are trustworthy as naming registries is one wallets would have to tackle anyway. +### Resolution step-by-step example 1. Check the type of `chain` - if typeof(chain) == “ENS name”: go to step 2 - if typeof(chain) == “L1 TLD”: go to step 3 @@ -138,15 +166,25 @@ sepolia -> {L1_chain_id : 0xaa36a7; L1_ens_address : } 8. Resolve the ENS name's `addr(name, cointype)` ## Rationale +- We chose to use a centralized list of name registries, aka a name registry 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. -## Backwards Compatibility +## Open Discussions +- Further constrain the syntax of human-readable names to minimize: + - Collisions on names by e.g. UTS46 case foldig + - Addresses that are valid ERC-7828 but cant be squeezed into ENS or comparable standards -No backward compatibility issues found. +## Backwards Compatibility +The naming scheme herein defined can represent all names supported by [ERC-X] ## Security Considerations - + ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). + + +[ERC-X]: ./ERC-X.md +[ERC-7785]: ./ERC-7785.md +[name resolver registry]: TODO From d542aef642f1d00affcbedf6ef1689b631658b1a Mon Sep 17 00:00:00 2001 From: teddy Date: Fri, 11 Apr 2025 19:14:09 -0300 Subject: [PATCH 19/37] human readable name examples --- ERCS/erc-7828.md | 56 +++++++++++------------------------------------- 1 file changed, 12 insertions(+), 44 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index e5a525b9ecd..5ada8c00d54 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -72,25 +72,24 @@ This allows for Interoperable Addresses' text representation to mix and match 'r A few examples below: ``` Mainnet -- 0x12345...6789@0x1 -- 0x12345...6789@eth -- alice.eth@eth +- 0x12345...6789@eip155:1#FFFFFFFF +- 0x12345...6789@eth.short#FFFFFFFF +- alice.eth@eth.short#FFFFFFFF Testnet (Sepolia) -- 0x12345...6789@0xaa36a7 -- 0x12345...6789@sepolia -- alice.eth@sepolia +- 0x12345...6789@eip155:11155111#00000000 +- alice.testeth@sep.short#00000000 Rollup -- 0x12345...6789@chainId -- 0x12345...6789@arbitrum.eth -- alice.eth@arbitrum.eth +- 0x12345...6789@eip155:4270#AAAAAAAA +- 0x12345...6789@arb-nova.short#AAAAAAAA +- alice.eth@arb-nova.short#AAAAAAAA -Rollup Sepolia -- 0x12345...6789@arbitrum.sepolia +Assuming ERC-7785 starts listing chains at l2.eth +- alice.eth@arb-nova.l2.eth#AAAAAAAA -My ENS name is registered on rollup1, but I want to receive funds on rollup2 -- alice.rollup1.eth@rollup2.eth +My ENS name is registered on rollup1 (via ENSIP-10 & ENSIP-16), but I want to receive funds on rollup2 +- alice.rollup1.eth@rollup2.short#BBBBBBBB ``` ### Checksum @@ -98,37 +97,6 @@ Addreses must be serialized to the `ChainType, ChainReferenceLength, ChainRefere This has the property of the checksum changing if any part of the address or chainid is modified, making dangerous manual modification of addresses an error case for wallet users, and also mitigates collisions where the same name is registered to separate addresses on -### A special case for ENS resolution - -Any ENS name today can be resolved to a chain identifier or to an address. -We could imagine having a name `user.eth` that points to a record of the form `{address ; chain_id}`. Given such an address a wallet can verify it resolves to a valid account. -The advantage of this format is that it is very flexible and can accommodate a number of use cases, however it can also lead to confusion for users because a name does not necessarily resolve to a valid account. The same `user.eth` could lead to a website, a NFT or multiple addresses. - -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 `user@rollup.eth`, 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. - -### L2 resolution - -In case an address is not registered on L1, but only on a L2, the resolution can be processed using [ERC-3668](./eip-3668.md) and [ERC-2544](./eip-2544.md)'s Wildcard Resolution. - -In the previous example `user@rollup.eth`, `user` would not be registered on L1. -In this case the wallet can resolve `rollup.eth` to get a chain identifier as before and when attempting to resolve `user.rollup.eth` to get an address, it would fail and be redirected to the L2 gateway. Any answer from the gateway needs to be verified as explained in the EIP. - -### L1 resolution - -Ethereum Mainnet and its testnets can be resolved to their corresponding chain identifiers using a centralized list, which remains unchanged from how it works today. Other L1 registrations are out of scope for this EIP. - -Mapping: -``` -L1-TLD -> {L1_chain_id : chain_id; L1_ens_address : address;} -``` -Example: -``` -eth -> {L1_chain_id : 0x1; L1_ens_address : } -sepolia -> {L1_chain_id : 0xaa36a7; L1_ens_address : } -``` - ### The Name Resolver Registry We propose for this ERC to strive to reach Final status instead of becoming a Living document, and maintain a separate dictionary for the different name resolving protocols or methods, similar to ethereum-lists/chains. From 471fc39a7be9685fdbb7dddfa64c9db25a833fce Mon Sep 17 00:00:00 2001 From: teddy Date: Fri, 11 Apr 2025 19:31:41 -0300 Subject: [PATCH 20/37] wip: offchain examples --- ERCS/erc-7828.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 5ada8c00d54..cbf07b174a8 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -90,6 +90,13 @@ Assuming ERC-7785 starts listing chains at l2.eth My ENS name is registered on rollup1 (via ENSIP-10 & ENSIP-16), but I want to receive funds on rollup2 - alice.rollup1.eth@rollup2.short#BBBBBBBB + +Non-evm chain +bc1..23@bip122:000000000019d6689c085ae165831e93#CCCCCCCC +alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC + +Assuming the shortcode list adds a few other CAIP namespaces +alice.eth@btc.short ``` ### Checksum From 1af7ca42d18865830ed8c3cdfeeecbb2e9376703 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 12:51:56 -0300 Subject: [PATCH 21/37] feat: example registry registry entries --- ERCS/erc-7828.md | 56 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 52 insertions(+), 4 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index cbf07b174a8..c791e81b685 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -92,22 +92,24 @@ My ENS name is registered on rollup1 (via ENSIP-10 & ENSIP-16), but I want to re - alice.rollup1.eth@rollup2.short#BBBBBBBB Non-evm chain -bc1..23@bip122:000000000019d6689c085ae165831e93#CCCCCCCC -alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC +- bc1..23@bip122:000000000019d6689c085ae165831e93#CCCCCCCC +- alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC Assuming the shortcode list adds a few other CAIP namespaces -alice.eth@btc.short +- alice.eth@btc.short#CCCCCCCC ``` ### Checksum Addreses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-X] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. -This has the property of the checksum changing if any part of the address or chainid is modified, making dangerous manual modification of addresses an error case for wallet users, and also mitigates collisions where the same name is registered to separate addresses on +This has the property of the checksum changing if any part of the address or chainid is modified, making dangerous manual modification of addresses an error case for wallet users, and also mitigates collisions where the same name is registered to different addresses on different registries ### The Name Resolver Registry + We propose for this ERC to strive to reach Final status instead of becoming a Living document, and maintain a separate dictionary for the different name resolving protocols or methods, similar to ethereum-lists/chains. The keys of this list will be ``s, and their associated values should be: +- 2-byte binary id, for storing intended registry in Interoperable Addresses v2 (defined below) - Chain naming section - The set of CASA namespaces on which the registry can provide names for chains. - An unambiguously implementable specification of how to obtain a name for a chain id. @@ -127,6 +129,52 @@ It is worth noting that: This is an easier list to maintain than ethereum-lists/chains, since it does not have to list every single chain, and the problem of knowing which contracts are trustworthy as naming registries is one wallets would have to tackle anyway. +### Example entries for the `L0-TLD` list + +#### `.short` +Binary id: `0x0000` + +##### Chain naming + +###### Supported CASA namespaces +Only those explicitly listed here + +###### Resolution algorithm +Simply refer to the table below + +| shortname | CAIP-2 namespace | CAIP-2 reference (text) | +| :-- | :--: | :--: | +| `eth` | `eip155` | `1` | +| `oeth` | `eip155` | `10` | +| `arb-nova` | `eip155` | `4270` | +| `btc` | `bip122` | `000000000019d6689c085ae165831e93` | +| `solana` | `solana` | `5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` | + + + +##### Address naming +Not supported + +#### `.eth` +Binary id: `0x0001` + +###### Supported CASA namespaces +`eip155` and anything supported by SLIP-0044 +Note that in the case of chains supported by SLIP-0044 + +##### Chain naming +Not currently supported, TBD in ERC-7785 + +##### Address naming + +Resolution and reverse-resolution of chain names is to be executed as defined in ENSIP-16, ENSIP-11 and ENSIP-10. + +Some caveats for ENS support are: +- ENSIP-6 and ENSIP-17 are explicitly not supported, as they define names on different TLDs. +- While ENS could add support for other TLDs for forward resolution, this standard would require another entry on this list to support them. This does not apply to _reverse_, resolution, since those names are not ever displayed. +- For addresses on chains that are both supported by SLIP-0044 and the special scheme for the eip155 namespace defined in ENSIP-11, the latter should be used. + + ### Resolution step-by-step example 1. Check the type of `chain` - if typeof(chain) == “ENS name”: go to step 2 From dce9e3c61c3cca4fc1b4d2fa0734382131e66a0c Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 13:14:52 -0300 Subject: [PATCH 22/37] feat: interoperable addresses v2 --- ERCS/erc-7828.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index c791e81b685..bcd658e68c7 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -175,6 +175,24 @@ Some caveats for ENS support are: - For addresses on chains that are both supported by SLIP-0044 and the special scheme for the eip155 namespace defined in ENSIP-11, the latter should be used. +### Interoperable Address v2 definition +To allow for addresses to be serialized from human-readable names to an Interoperable Address, and then back to _the same_ human-readable name we define a new version of Interoperable Addresses which includes information on the desired naming registry. + +Note that this is OPTIONAL, and wallets MAY disregard the extra information and use the registries they prefer instead, and/or serialize to Interoperable Addresses version 1. +``` +┌─────────┬───────────┬──────────────────────┬────────────────┬───────────────┬─────────┬───────────────┬─────────────────┐ +│ Version │ ChainType │ ChainReferenceLength │ ChainReference │ AddressLength │ Address │ ChainResolver │ AddressResolver │ +└─────────┴───────────┴──────────────────────┴────────────────┴───────────────┴─────────┴───────────────┴─────────────────┘ +``` + +Where: + +- `Version` : A 2-byte version identifier. must be big-endian unsigned integer `2`. +- `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength`, `Address`: Same as in [ERC-X] +- `ChainResolver`: 2-byte identifier of the method used to resolve the chain to a human-readable string, from the name registry registry. +- `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the name registry registry. + + ### Resolution step-by-step example 1. Check the type of `chain` - if typeof(chain) == “ENS name”: go to step 2 From 7725151ff607da7301093babfbb3a5f94178e365 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 14:14:12 -0300 Subject: [PATCH 23/37] feat: forward resolution --- ERCS/erc-7828.md | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index bcd658e68c7..47f92278a2c 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -131,6 +131,9 @@ This is an easier list to maintain than ethereum-lists/chains, since it does not ### Example entries for the `L0-TLD` list +> [!NOTE] +> This list does not define an example for the case where no resolution is desired, as in that case an Interoperable Address v2 can be used instead + #### `.short` Binary id: `0x0000` @@ -193,29 +196,34 @@ Where: - `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the name registry registry. -### Resolution step-by-step example -1. Check the type of `chain` - - if typeof(chain) == “ENS name”: go to step 2 - - if typeof(chain) == “L1 TLD”: go to step 3 - - if typeof(chain) == “chainId”: go to step 4 -2. Resolve the ENS name's `text(chainENSName, ‘chain_id’)` record using [ERC-2544](./eip-2544.md) and skip to step 4 -3. Use an offline mapping of `TLD => chainId` to find the relevant chainId. -4. Check if `account` is an ENS name, if not end the resolution process. -5. Generate the cointype using the chainId via ENSIP-11: `coinType = 0x80000000 | chainId` -6. Verify the bridge address by resolving `[chainId].id.eth`'s `name(name, 60)` record using [ERC-2544](./eip-2544.md) -7. Check if this name matches the ENS name representing the chain, continue otherwise consider the resolution a failure and error. -8. Resolve the ENS name's `addr(name, cointype)` +### Forward resolution step-by-step example +1. Let the user input an address name. Assume it's `alice.eth` +2. Let the user select a chain. Assume it's `oeth.short` +3. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 2. For this example it's `.short`. +4. Look up the result from the step above on the Name Registry Registry to know what to do with the entirety of the result from step 2. In this case, the hardcoded table says it corresponds to + - chain namespace: `eip155` + - chain reference: `10` (chainid of OP Mainnet) +5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS +6. As per ENSIP-11, convert the eip155 chainid into an ENSIP-11-specific `coinType`: `0x80000000 & 0x0000000A == 0x8000000A` +7. Compute the namehash of the result of step 1, according to ENSIP-1. +8. Call `addr(bytes32 node, uint256 coinType)` with the results of steps 7 and 6, respectively. This will return the 20 bytes of alice's OP Mainnet address, assume it's `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` + - Failure mode: if result is address zero, that means the name is not registered and resolution cant be finished. +9. Begin serialization into an Interoperable Address v2 by appending the version: `[0002]` +10. Serialize `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-X]: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]` +11. Append the binary id for the `ChainResolver` and `AddressResolver` from the Name Resolver Registry: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0000 0001]` +12. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` +13. Compute the checksum as described in [ERC-X]: `0xC69BEB13` and display it to the user. ## Rationale - We chose to use a centralized list of name registries, aka a name registry 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 - Further constrain the syntax of human-readable names to minimize: - - Collisions on names by e.g. UTS46 case foldig + - Collisions on names by e.g. UTS46 case folding - Addresses that are valid ERC-7828 but cant be squeezed into ENS or comparable standards ## Backwards Compatibility -The naming scheme herein defined can represent all names supported by [ERC-X] +The naming scheme herein defined can represent all names supported by [ERC-X] by displaying raw addresses without resolution ## Security Considerations From d8d631166944cb24287ba199a1676086946c486e Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 17:41:43 -0300 Subject: [PATCH 24/37] feat: reverse resolution --- ERCS/erc-7828.md | 51 +++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 7 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 47f92278a2c..feac733d075 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -170,7 +170,7 @@ Not currently supported, TBD in ERC-7785 ##### Address naming -Resolution and reverse-resolution of chain names is to be executed as defined in ENSIP-16, ENSIP-11 and ENSIP-10. +Resolution and reverse-resolution of chain names is to be executed as defined in ENSIP-19, ENSIP-16, ENSIP-11 and ENSIP-10. Some caveats for ENS support are: - ENSIP-6 and ENSIP-17 are explicitly not supported, as they define names on different TLDs. @@ -206,13 +206,46 @@ Where: 5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS 6. As per ENSIP-11, convert the eip155 chainid into an ENSIP-11-specific `coinType`: `0x80000000 & 0x0000000A == 0x8000000A` 7. Compute the namehash of the result of step 1, according to ENSIP-1. -8. Call `addr(bytes32 node, uint256 coinType)` with the results of steps 7 and 6, respectively. This will return the 20 bytes of alice's OP Mainnet address, assume it's `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` +8. Query the ENS registry for the appropiate resolver by calling `resolver(bytes32 node)` with the result of the step above +9. Call `addr(bytes32 node, uint256 coinType)` on the contract returned on the step above with the results of steps 7 and 6, respectively. This will return the 20 bytes of alice's OP Mainnet address, assume it's `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` - Failure mode: if result is address zero, that means the name is not registered and resolution cant be finished. -9. Begin serialization into an Interoperable Address v2 by appending the version: `[0002]` -10. Serialize `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-X]: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]` -11. Append the binary id for the `ChainResolver` and `AddressResolver` from the Name Resolver Registry: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0000 0001]` -12. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` -13. Compute the checksum as described in [ERC-X]: `0xC69BEB13` and display it to the user. +10. Begin serialization into an Interoperable Address v2 by appending the version: `[0002]` +11. Serialize `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-X]: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]` +12. Append the binary id for the `ChainResolver` and `AddressResolver` from the Name Resolver Registry: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0000 0001]` +13. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` +14. Compute the checksum as described in [ERC-X]: `0xC69BEB13` and display it to the user. + +### Reverse Resolution step-by-step example +Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` + +1. Pick the first two bytes corresponding to the version: `0x0002`. Remaining payload: `0000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` +2. Parse the `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-X]. Remaining payload `00000001` + 1. `ChainType`: `0x0000` -> `eip155` + 2. `ChainReferenceLength`: `0x01` -> 1 + 3. `ChainReference`: `0x0A` -> 10 (OP Mainnet) + 4. `AddressLength`: `0x14` -> 20 bytes, consistent with `eip155` + 4. `Address`: `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` -> alice's address +3. Since we know the address to be v2, defined above, pick the next two bytes as the `ChainResolver`: `0x0000` -> shortname list. Remaining payload: `0001` +4. Pick the next two bytes as `AddressResolver`: `0x0001` -> ENS. No remaining payload, parsing finished. +5. Look up the output of step 3 in the name registry registry. It instructs to use the hard-coded shortcode list, with TLD `.short` +6. Serialize the chain type (2.1) and chain reference (2.3) to CAIP-2 following [ERC-X]: `eip155:10` +7. Look up the type reference on the shortcode list, and obtain the full name to use: `oeth.short` +8. Look up the output of step 4 in the name registry registry. It instructs to use ENS. + +9. Convert the output from steps 2.1 and 2.3 to an ENSIP-11 `coinType` +10. Compute the namehash of `
..reverse`, where: + - `` is the RFC-4648 base16 representation of the concatenated `ChainType` and `ChainReference`[^1] + - `
` is the RFC-4648 base16 representation of the `Address` [^1] +11. Query the ENS registry for the appropriate resolver by calling `resolver(bytes32 node)` with the result of the step above +12. Call `name(bytes32 node)` on the contract obtained in the step above, with the result of step 10 as the argument. + - If the empty string is returned, it means there isn't a name registered for that address, and it should be displayed raw. +13. Check forward resolution of the name as described in ENSIP-11 and repeated in the section above. + - If it resolves to the same address, then proceed normally + - If it resolves to a different address, including an empty bytes array, display the address raw and optionally show a warning to the user. +14. Compute the checksum as described in [ERC-X]: `0xC69BEB13`. +15. Format the address in the format `
@#` and display it to the user: `alice.eth@oeth.short#C69BEB13` + +[^1]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. ## Rationale - We chose to use a centralized list of name registries, aka a name registry 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. @@ -221,6 +254,10 @@ Where: - 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 custom serialization logic for a few address types and it'd be very convenient if it used the same CASA profile as [ERC-X] + - 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-X]. + - ENSIP-19 does not extensively define address or name serialization for the reverse registrar node name ## Backwards Compatibility The naming scheme herein defined can represent all names supported by [ERC-X] by displaying raw addresses without resolution From f6e7bfaaa32706ad04174c8abf6045b874ff79e4 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 17:49:33 -0300 Subject: [PATCH 25/37] fix: proofreading --- ERCS/erc-7828.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index feac733d075..22cb69b800e 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -121,7 +121,6 @@ The keys of this list will be ``s, and their associated values should be - An unambiguously implementable specification of how to obtain a machine address, given a name. - The sources of truth the algorithms above should use. - It is worth noting that: - The same `` can map to different algorithms and/or data for chains and addresses. e.g. if ERC-7785 is published as an ENS product, using `.eth` on a chain name will use a different algorithm for resolution than if the same TLD were used on an address. @@ -133,6 +132,7 @@ This is an easier list to maintain than ethereum-lists/chains, since it does not > [!NOTE] > This list does not define an example for the case where no resolution is desired, as in that case an Interoperable Address v2 can be used instead + #### `.short` Binary id: `0x0000` @@ -192,15 +192,15 @@ Where: - `Version` : A 2-byte version identifier. must be big-endian unsigned integer `2`. - `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength`, `Address`: Same as in [ERC-X] -- `ChainResolver`: 2-byte identifier of the method used to resolve the chain to a human-readable string, from the name registry registry. -- `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the name registry registry. +- `ChainResolver`: 2-byte identifier of the method used to resolve the chain to a human-readable string, from the [name resolver registry]. +- `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the [name resolver registry]. ### Forward resolution step-by-step example 1. Let the user input an address name. Assume it's `alice.eth` 2. Let the user select a chain. Assume it's `oeth.short` 3. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 2. For this example it's `.short`. -4. Look up the result from the step above on the Name Registry Registry to know what to do with the entirety of the result from step 2. In this case, the hardcoded table says it corresponds to +4. Look up the result from the step above on the [name resolver registry] to know what to do with the entirety of the result from step 2. In this case, the hardcoded table says it corresponds to - chain namespace: `eip155` - chain reference: `10` (chainid of OP Mainnet) 5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS @@ -227,10 +227,10 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA 4. `Address`: `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` -> alice's address 3. Since we know the address to be v2, defined above, pick the next two bytes as the `ChainResolver`: `0x0000` -> shortname list. Remaining payload: `0001` 4. Pick the next two bytes as `AddressResolver`: `0x0001` -> ENS. No remaining payload, parsing finished. -5. Look up the output of step 3 in the name registry registry. It instructs to use the hard-coded shortcode list, with TLD `.short` +5. Look up the output of step 3 in the [name resolver registry]. It instructs to use the hard-coded shortcode list, with TLD `.short` 6. Serialize the chain type (2.1) and chain reference (2.3) to CAIP-2 following [ERC-X]: `eip155:10` 7. Look up the type reference on the shortcode list, and obtain the full name to use: `oeth.short` -8. Look up the output of step 4 in the name registry registry. It instructs to use ENS. +8. Look up the output of step 4 in the [name resolver registry]. It instructs to use ENS. 9. Convert the output from steps 2.1 and 2.3 to an ENSIP-11 `coinType` 10. Compute the namehash of `
..reverse`, where: @@ -248,7 +248,7 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA [^1]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. ## Rationale -- We chose to use a centralized list of name registries, aka a name registry 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. +- 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 - Further constrain the syntax of human-readable names to minimize: @@ -263,7 +263,6 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA The naming scheme herein defined can represent all names supported by [ERC-X] by displaying raw addresses without resolution ## Security Considerations - ## Copyright From c27ef1bc11dc5e3433d3bee6074d4f9e6287fce0 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 20:39:09 -0300 Subject: [PATCH 26/37] non-normative parts & proofreading --- ERCS/erc-7828.md | 47 +++++++++++++++++++++++++---------------------- 1 file changed, 25 insertions(+), 22 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 22cb69b800e..ad6402314c0 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -12,32 +12,32 @@ requires: 55, 137, 155, 7785 --- ## Abstract -This proposal builds off of [ERC-7785](./eip-7785.md) (on-chain configs) to provide a standard and human-readable format for chain-specific L2 addresses: +This proposal builds off of [ERC-X] (Interoperable Addresses) and [ERC-7785] (on-chain configs) to provide a standard and human-readable format for chain-specific addresses which provides: - A unified format for accounts that specifies, together with the address, the chain where the address lives. -- The use of human-readable chain names and how they can be resolved to chain identifiers using ENS on L1. -- The use of human-readable account names and how they can be resolved to addresses using ENS on L2. +- The use of human-readable chain names and how they can be resolved to chain identifiers. +- The use of human-readable account names and how they can be resolved to addresses. +- A centralized index of chain and account resolution methods, way smaller in scope than ethereum-lists/chains ## 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. -The mapping from chain names to identifiers has, since [EIP-155](./eip-155.md), been maintained off chain using a centralized list. This solution has two main shortcomings: - - It does not scale with the growing number of L2s. - - The list maintainer is a trusted centralized entity. +The mapping from chain names to identifiers has, since [EIP-155](./eip-155.md), been maintained off chain using a centralized list. This solution has a few shortcomings: +- It does not scale with the growing number of L2s. +- The list maintainer is a trusted centralized entity. +- It does not (currently) support non-EVM chains, even when naming systems (such as ENS) do. Instead of using chain identifiers, which are not human readable, the address could be extended with a human-readable chain name, which can then be resolved to a chain identifier. -The mapping from chain names to identifiers can be resolved off-chain using existing centralized lists or on-chain using ENS (see ERC-7785). +The mapping from chain names to identifiers can be resolved via a variety of methods which are coupled to the name's TLD. -In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. However it would be desirable if the address name could be registered on a L2. +In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. By coupling the TLD to the resolving method used, this standard could leverage current and future features of ENS and other naming registries. Desired properties: -- a unified format to represent any address on L1 or L2 -- the ability to use chain names in addition to identifiers -- the chain portion can be a domain name, or just the suffix for a "base chain" (eg. `eth`, `myfavoriterollup.eth`, `sepolia`, `my_l3.base.superchain.eth`) -- the address portion can be either the appropriate type of address for the chain (0x... for EVM chains, otherwise eg. for starknet something else), or a domain name (ENS or other) -- the ability to resolve ENS names on the L2 -- the address portion and the chain portion should be resolved separately -- checksums are MANDATORY -- checksum hash goes over the entire address, so users can't just replace a component and expect it to stay valid +- A unified format to represent any address on L1, L2 or beyond. +- The chain portion can be an ERC-7785 domain name when that standard is ready, or use solutions similar to ethereum-lists/chains in the immediate future. +- The address portion can be either the appropriate type of address for the chain, or a domain name. +- The address portion and the chain portion should be resolved separately. +- Checksum hash goes over the entire address & chain, so users can't just replace a component and expect it to stay valid. +- Addresses can be serialized to binary and then de-serialized back to text retaining the same human-readable name, even if serialization and de-serialization happen on different wallets. ## 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. @@ -54,16 +54,15 @@ This standard defines a sub-syntax with extra semantics on top of the syntax def : := [.-:_%a-zA-Z0-9]* : := [.-:_a-zA-Z0-9]* : := . -: := [_a-zA-Z0-9]{1,10} +: := [a-zA-Z][-a-zA-Z0-9]{0,9} +: := [a-zA-Z][-a-zA-Z0-9]* ``` Where: -- `` : Corresponds to a full, resolvable name on the registry defined by its `L0-TLD` +- `` : Corresponds to a full, resolvable name on the defined by its `L0-TLD` - ``, `` and `` are defined to maintain backwards compatibility with [ERC-X], and their semantics remain the same. - ``: Corresponds to an entry in the centralized [name resolver registry] - -- ``: Is a valid punycode string without `.` separators. Note the difference between ``, which is a fully qualified name, and `subdomain` that is just a segment of a name between dots. E.g. `user.app.eth` is a scoped name, `user` and `app` are subdomains. @@ -99,6 +98,9 @@ Assuming the shortcode list adds a few other CAIP namespaces - alice.eth@btc.short#CCCCCCCC ``` +> [!NOTE] +> This standard does not explicitly define a hierarchical name structure for anything other than the top level domain, however it allows the underlying naming scheme to be hierarchical as in the ENS-in-rollup example. + ### Checksum Addreses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-X] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. @@ -153,7 +155,7 @@ Simply refer to the table below | `btc` | `bip122` | `000000000019d6689c085ae165831e93` | | `solana` | `solana` | `5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` | - + ##### Address naming Not supported @@ -263,7 +265,8 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA The naming scheme herein defined can represent all names supported by [ERC-X] by displaying raw addresses without resolution ## 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. +- Maintaining a list of chain/name registries instead of a list of chains means it'd have to be updated less frequently, allowing for more extensive review of new entries. ## Copyright From 6e2f92b08ea2d6dea123382464b871ffd5fbfa02 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 20:42:01 -0300 Subject: [PATCH 27/37] fix: feedback from racu --- ERCS/erc-7828.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index ad6402314c0..169175a974c 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -104,7 +104,7 @@ Assuming the shortcode list adds a few other CAIP namespaces ### Checksum Addreses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-X] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. -This has the property of the checksum changing if any part of the address or chainid is modified, making dangerous manual modification of addresses an error case for wallet users, and also mitigates collisions where the same name is registered to different addresses on different registries +This ensures that the checksum changes if any part of the address or chain ID is modified, turning dangerous manual edits into detectable errors for wallet users. ### The Name Resolver Registry From 90a842a5d1992c51937ec734ca81a4627cca4112 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 14 Apr 2025 20:47:40 -0300 Subject: [PATCH 28/37] chore: update authors --- ERCS/erc-7828.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 169175a974c..e99fc742a8c 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -2,7 +2,7 @@ eip: 7828 title: Chain-specific addresses using ENS description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. -author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin) +author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin), Teddy (@0xteddybear), Joxes (@Joxess), Racu (@0xRacoon) discussions-to: https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses-using-ens/21930 status: Draft type: Standards Track From 46eecaf55a967acc8dea11b3dac65625db42780f Mon Sep 17 00:00:00 2001 From: teddy Date: Thu, 17 Apr 2025 12:53:07 -0300 Subject: [PATCH 29/37] chore: reference Interoperable Address ERC --- ERCS/erc-7828.md | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index e99fc742a8c..744fd2e3aef 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -43,7 +43,7 @@ Desired properties: 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. ### Format -This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-X]. +This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-7930]. ``` : :=
@# @@ -61,7 +61,7 @@ This standard defines a sub-syntax with extra semantics on top of the syntax def Where: - `` : Corresponds to a full, resolvable name on the defined by its `L0-TLD` -- ``, `` and `` are defined to maintain backwards compatibility with [ERC-X], and their semantics remain the same. +- ``, `` and `` are defined to maintain backwards compatibility with [ERC-7930], and their semantics remain the same. - ``: Corresponds to an entry in the centralized [name resolver registry] Note the difference between ``, which is a fully qualified name, and `subdomain` that is just a segment of a name between dots. E.g. `user.app.eth` is a scoped name, `user` and `app` are subdomains. @@ -102,7 +102,7 @@ Assuming the shortcode list adds a few other CAIP namespaces > This standard does not explicitly define a hierarchical name structure for anything other than the top level domain, however it allows the underlying naming scheme to be hierarchical as in the ENS-in-rollup example. ### Checksum -Addreses must be serialized to the `ChainType, ChainReferenceLength, ChainReference, AddressLength, Address` format proposed in [ERC-X] as Interoperable Addresses v1, and the 4-byte checksum MUST be displayed as part of the address as described in the syntax above. +Addreses 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. This ensures that the checksum changes if any part of the address or chain ID is modified, turning dangerous manual edits into detectable errors for wallet users. @@ -191,9 +191,9 @@ Note that this is OPTIONAL, and wallets MAY disregard the extra information and ``` Where: - + - `Version` : A 2-byte version identifier. must be big-endian unsigned integer `2`. -- `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength`, `Address`: Same as in [ERC-X] +- `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength`, `Address`: Same as in [ERC-7930] - `ChainResolver`: 2-byte identifier of the method used to resolve the chain to a human-readable string, from the [name resolver registry]. - `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the [name resolver registry]. @@ -212,16 +212,16 @@ Where: 9. Call `addr(bytes32 node, uint256 coinType)` on the contract returned on the step above with the results of steps 7 and 6, respectively. This will return the 20 bytes of alice's OP Mainnet address, assume it's `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` - Failure mode: if result is address zero, that means the name is not registered and resolution cant be finished. 10. Begin serialization into an Interoperable Address v2 by appending the version: `[0002]` -11. Serialize `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-X]: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]` +11. Serialize `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-7930]: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]` 12. Append the binary id for the `ChainResolver` and `AddressResolver` from the Name Resolver Registry: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0000 0001]` 13. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` -14. Compute the checksum as described in [ERC-X]: `0xC69BEB13` and display it to the user. +14. Compute the checksum as described in [ERC-7930]: `0xC69BEB13` and display it to the user. ### Reverse Resolution step-by-step example Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` 1. Pick the first two bytes corresponding to the version: `0x0002`. Remaining payload: `0000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` -2. Parse the `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-X]. Remaining payload `00000001` +2. Parse the `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-7930]. Remaining payload `00000001` 1. `ChainType`: `0x0000` -> `eip155` 2. `ChainReferenceLength`: `0x01` -> 1 3. `ChainReference`: `0x0A` -> 10 (OP Mainnet) @@ -230,7 +230,7 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA 3. Since we know the address to be v2, defined above, pick the next two bytes as the `ChainResolver`: `0x0000` -> shortname list. Remaining payload: `0001` 4. Pick the next two bytes as `AddressResolver`: `0x0001` -> ENS. No remaining payload, parsing finished. 5. Look up the output of step 3 in the [name resolver registry]. It instructs to use the hard-coded shortcode list, with TLD `.short` -6. Serialize the chain type (2.1) and chain reference (2.3) to CAIP-2 following [ERC-X]: `eip155:10` +6. Serialize the chain type (2.1) and chain reference (2.3) to CAIP-2 following [ERC-7930]: `eip155:10` 7. Look up the type reference on the shortcode list, and obtain the full name to use: `oeth.short` 8. Look up the output of step 4 in the [name resolver registry]. It instructs to use ENS. @@ -244,7 +244,7 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA 13. Check forward resolution of the name as described in ENSIP-11 and repeated in the section above. - If it resolves to the same address, then proceed normally - If it resolves to a different address, including an empty bytes array, display the address raw and optionally show a warning to the user. -14. Compute the checksum as described in [ERC-X]: `0xC69BEB13`. +14. Compute the checksum as described in [ERC-7930]: `0xC69BEB13`. 15. Format the address in the format `
@#` and display it to the user: `alice.eth@oeth.short#C69BEB13` [^1]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. @@ -257,12 +257,12 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA - 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 custom serialization logic for a few address types and it'd be very convenient if it used the same CASA profile as [ERC-X] - - 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-X]. + - ENSIP-11 defines custom serialization logic for a few address types and it'd be very convenient if it used the same CASA profile as [ERC-7930] + - 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]. - ENSIP-19 does not extensively define address or name serialization for the reverse registrar node name ## Backwards Compatibility -The naming scheme herein defined can represent all names supported by [ERC-X] by displaying raw addresses without resolution +The naming scheme herein defined can represent all names supported by [ERC-7930] by displaying raw addresses without resolution ## 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. @@ -272,7 +272,6 @@ The naming scheme herein defined can represent all names supported by [ERC-X] by Copyright and related rights waived via [CC0](../LICENSE.md). - -[ERC-X]: ./ERC-X.md +[ERC-7930]: ./ERC-7930.md [ERC-7785]: ./ERC-7785.md [name resolver registry]: TODO From 2e193e7c91fdf28809b1c5b6185eddcd0f8cdf2b Mon Sep 17 00:00:00 2001 From: teddy Date: Thu, 17 Apr 2025 13:41:26 -0300 Subject: [PATCH 30/37] chore: clarify ENS usage for reverse resolution --- ERCS/erc-7828.md | 35 ++++++++++++++++++++--------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 744fd2e3aef..478a586aeac 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -164,8 +164,9 @@ Not supported Binary id: `0x0001` ###### Supported CASA namespaces -`eip155` and anything supported by SLIP-0044 -Note that in the case of chains supported by SLIP-0044 +`eip155` and anything supported by SLIP-0044 for forward resolution (Interoperable Address -> human-readable name) + +`eip155` chains explicitly supported by ENS by deployment of `L2ReverseRegistrar` and registration on ENS registry for reverse resolution (human-readable name -> Interoperable Address) ##### Chain naming Not currently supported, TBD in ERC-7785 @@ -206,7 +207,7 @@ Where: - chain namespace: `eip155` - chain reference: `10` (chainid of OP Mainnet) 5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS -6. As per ENSIP-11, convert the eip155 chainid into an ENSIP-11-specific `coinType`: `0x80000000 & 0x0000000A == 0x8000000A` +6. As per ENSIP-11, convert the eip155 chainid into an ENSIP-11-specific `coinType`: `0x80000000 & 0x0000000A == 0x8000000A` [^1] 7. Compute the namehash of the result of step 1, according to ENSIP-1. 8. Query the ENS registry for the appropiate resolver by calling `resolver(bytes32 node)` with the result of the step above 9. Call `addr(bytes32 node, uint256 coinType)` on the contract returned on the step above with the results of steps 7 and 6, respectively. This will return the 20 bytes of alice's OP Mainnet address, assume it's `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` @@ -217,6 +218,8 @@ Where: 13. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` 14. Compute the checksum as described in [ERC-7930]: `0xC69BEB13` and display it to the user. +[^1]: While this sees production usage, it is not consistent with the design principles behnd [ERC-7930] and assumes 32-bit chainids, which are not compatible with an [ERC-7785] future. We recommend using something closer to what is described in footnote 2. + ### Reverse Resolution step-by-step example Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` @@ -233,21 +236,23 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA 6. Serialize the chain type (2.1) and chain reference (2.3) to CAIP-2 following [ERC-7930]: `eip155:10` 7. Look up the type reference on the shortcode list, and obtain the full name to use: `oeth.short` 8. Look up the output of step 4 in the [name resolver registry]. It instructs to use ENS. - -9. Convert the output from steps 2.1 and 2.3 to an ENSIP-11 `coinType` -10. Compute the namehash of `
..reverse`, where: - - `` is the RFC-4648 base16 representation of the concatenated `ChainType` and `ChainReference`[^1] - - `
` is the RFC-4648 base16 representation of the `Address` [^1] -11. Query the ENS registry for the appropriate resolver by calling `resolver(bytes32 node)` with the result of the step above -12. Call `name(bytes32 node)` on the contract obtained in the step above, with the result of step 10 as the argument. - - If the empty string is returned, it means there isn't a name registered for that address, and it should be displayed raw. -13. Check forward resolution of the name as described in ENSIP-11 and repeated in the section above. +9. Convert the output from steps 2.1 and 2.3 to a reverse lookup string of the form `
..reverse`: `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.0000010A.reverse` + - `` is the RFC-4648 base16 representation of the concatenated `ChainType`, `ChainReferenceLength` and `ChainReference` [^2] + - `
` is the RFC-4648 base16 representation of the `Address` [^2] +10. Compute the namehash of the result of the step above. +11. Perform ENSIP-10 resolution of the name above in the Ethereum Mainnet ENS registry to find the address of the `L2ReverseRegistrar`. + 1. Call `resolver(AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.0000010A.reverse)` on the mainnet ENS registry. It'll return the zero address, since there is no resovler registered on that address specifically. + 2. Call `resolver(0000010A.reverse)` on the mainnet ENS registry. It'll return `0x00000beef055f7934784d6d81b6bc86665630dba`, the address of the `L2ReverseRegistrar` *on network `0000010A`* +12. Verify the return of the `coinType` method of the `L2ReverseRegistrar` matches the coinType as serialized in step 9. [^2] + +13. Call `nameForAddr(bytes address)` [^2] with the address as serialized in step 9. This will return the human-readable name `alice.eth`. +14. Check forward resolution of the name as described in ENSIP-11 and repeated in the section above. - If it resolves to the same address, then proceed normally - If it resolves to a different address, including an empty bytes array, display the address raw and optionally show a warning to the user. -14. Compute the checksum as described in [ERC-7930]: `0xC69BEB13`. -15. Format the address in the format `
@#` and display it to the user: `alice.eth@oeth.short#C69BEB13` +15. Compute the checksum as described in [ERC-7930]: `0xC69BEB13`. +16. Format the address in the format `
@#` and display it to the user: `alice.eth@oeth.short#C69BEB13` -[^1]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. +[^2]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. ## 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. From 37e44e0444c2f763e3b9d0c2beff00f61b5df072 Mon Sep 17 00:00:00 2001 From: teddy Date: Thu, 17 Apr 2025 13:58:39 -0300 Subject: [PATCH 31/37] chore: update front matter --- ERCS/erc-7828.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 478a586aeac..ba0ffb551d1 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -1,8 +1,8 @@ --- eip: 7828 -title: Chain-specific addresses using ENS -description: A unified chain-specific address format that allows specifying the account as well as the chain on which that account intends to transact. -author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin), Teddy (@0xteddybear), Joxes (@Joxess), Racu (@0xRacoon) +title: Human readable names for Interoperable Addresses +description: An iteration of Interoperable Address' format that allows resolution to shorter, hierarchical strings using naming registries +author: Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin), Teddy (@0xteddybear), Joxes (@Joxess), Racu (@0xRacoon), Skeletor Spaceman (@0xskeletor-spaceman), TiTi (@0xtiti), Gori (@0xGorilla), Ardy (@0xArdy), Onizuka (@onizuka-wl) discussions-to: https://ethereum-magicians.org/t/erc-7828-chain-specific-addresses-using-ens/21930 status: Draft type: Standards Track @@ -12,7 +12,7 @@ requires: 55, 137, 155, 7785 --- ## Abstract -This proposal builds off of [ERC-X] (Interoperable Addresses) and [ERC-7785] (on-chain configs) to provide a standard and human-readable format for chain-specific addresses which provides: +This proposal builds off of [ERC-7930] (Interoperable Addresses) and [ERC-7785] (on-chain configs) to provide a standard and human-readable format for chain-specific addresses which provides: - A unified format for accounts that specifies, together with the address, the chain where the address lives. - The use of human-readable chain names and how they can be resolved to chain identifiers. - The use of human-readable account names and how they can be resolved to addresses. From 1b68784afbb5a658cc2154d432719d7d3d3d86eb Mon Sep 17 00:00:00 2001 From: teddy Date: Wed, 23 Apr 2025 14:08:30 -0300 Subject: [PATCH 32/37] chore: update motivation --- ERCS/erc-7828.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index ba0ffb551d1..05e16fb2623 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -31,6 +31,8 @@ The mapping from chain names to identifiers can be resolved via a variety of met In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. By coupling the TLD to the resolving method used, this standard could leverage current and future features of ENS and other naming registries. +Moreover, the above can be leveraged to allow for a name to represent the same entity corresponding to different addresses on different chains, mitigating the risk of sending funds to an address the intended recipient doesn't actually control. + Desired properties: - A unified format to represent any address on L1, L2 or beyond. - The chain portion can be an ERC-7785 domain name when that standard is ready, or use solutions similar to ethereum-lists/chains in the immediate future. From 0a71c7a55036511a225f98df1e99f4f73d79eb27 Mon Sep 17 00:00:00 2001 From: teddy Date: Thu, 1 May 2025 21:05:55 -0300 Subject: [PATCH 33/37] chore: typos --- ERCS/erc-7828.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 05e16fb2623..01fbb902521 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -208,7 +208,7 @@ Where: 4. Look up the result from the step above on the [name resolver registry] to know what to do with the entirety of the result from step 2. In this case, the hardcoded table says it corresponds to - chain namespace: `eip155` - chain reference: `10` (chainid of OP Mainnet) -5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS +5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS. 6. As per ENSIP-11, convert the eip155 chainid into an ENSIP-11-specific `coinType`: `0x80000000 & 0x0000000A == 0x8000000A` [^1] 7. Compute the namehash of the result of step 1, according to ENSIP-1. 8. Query the ENS registry for the appropiate resolver by calling `resolver(bytes32 node)` with the result of the step above @@ -220,7 +220,7 @@ Where: 13. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` 14. Compute the checksum as described in [ERC-7930]: `0xC69BEB13` and display it to the user. -[^1]: While this sees production usage, it is not consistent with the design principles behnd [ERC-7930] and assumes 32-bit chainids, which are not compatible with an [ERC-7785] future. We recommend using something closer to what is described in footnote 2. +[^1]: While this sees production usage, it is not consistent with the design principles behind [ERC-7930] and assumes 32-bit chainids, which are not compatible with an [ERC-7785] future. We recommend using something closer to what is described in footnote 2. ### Reverse Resolution step-by-step example Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` From 1f9eb33296dc8340e36cbf54e59534253817771f Mon Sep 17 00:00:00 2001 From: teddy Date: Thu, 1 May 2025 21:06:28 -0300 Subject: [PATCH 34/37] feat: security consideration on unicode collisions --- ERCS/erc-7828.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 01fbb902521..2913a9e5e00 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -274,6 +274,9 @@ The naming scheme herein defined can represent all names supported by [ERC-7930] ## 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. - Maintaining a list of chain/name registries instead of a list of chains means it'd have to be updated less frequently, allowing for more extensive review of new entries. +- Wallet developers should be aware of possible unicode glyph collisions in resolved names and warn users about them in order to keep checksums effective, since an attacker could, in order to impersonate `alice.eth@chain.short#00112233`: + - Mine an address on `chain.short` such that the checksum of the Interoperable Address is `00112233`. + - Register `аlice.eth` (using the russian vowel `а` instead of the latin `a`), and point it to the address above. ## Copyright From f360799ab557659c8486c2ce6e3a446ac95f500e Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 5 May 2025 17:58:29 -0300 Subject: [PATCH 35/37] fix: replace separator and fix grammar --- ERCS/erc-7828.md | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index 2913a9e5e00..b79ab542eb4 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -48,16 +48,17 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S This standard defines a sub-syntax with extra semantics on top of the syntax defined in [ERC-7930]. ``` -: :=
@# +: :=
"<>" "#"
: := | : := | : := [0-9A-F]{8} -: := [.-:_%a-zA-Z0-9]* -: := [.-:_a-zA-Z0-9]* +: := [.-:_%a-zA-Z0-9]+ +: := [.-:_a-zA-Z0-9]+ : := . -: := [a-zA-Z][-a-zA-Z0-9]{0,9} -: := [a-zA-Z][-a-zA-Z0-9]* +: := [a-zA-Z][-a-zA-Z0-9]{1,9} +: := ( . )? + := [a-zA-Z][-a-zA-Z0-9]+ ``` Where: @@ -73,31 +74,31 @@ This allows for Interoperable Addresses' text representation to mix and match 'r A few examples below: ``` Mainnet -- 0x12345...6789@eip155:1#FFFFFFFF -- 0x12345...6789@eth.short#FFFFFFFF -- alice.eth@eth.short#FFFFFFFF +- 0x12345...6789<>eip155:1#FFFFFFFF +- 0x12345...6789<>eth.short#FFFFFFFF +- alice.eth<>eth.short#FFFFFFFF Testnet (Sepolia) -- 0x12345...6789@eip155:11155111#00000000 -- alice.testeth@sep.short#00000000 +- 0x12345...6789<>eip155:11155111#00000000 +- alice.testeth<>sep.short#00000000 Rollup -- 0x12345...6789@eip155:4270#AAAAAAAA -- 0x12345...6789@arb-nova.short#AAAAAAAA -- alice.eth@arb-nova.short#AAAAAAAA +- 0x12345...6789<>eip155:4270#AAAAAAAA +- 0x12345...6789<>arb-nova.short#AAAAAAAA +- alice.eth<>arb-nova.short#AAAAAAAA Assuming ERC-7785 starts listing chains at l2.eth -- alice.eth@arb-nova.l2.eth#AAAAAAAA +- alice.eth<>arb-nova.l2.eth#AAAAAAAA My ENS name is registered on rollup1 (via ENSIP-10 & ENSIP-16), but I want to receive funds on rollup2 -- alice.rollup1.eth@rollup2.short#BBBBBBBB +- alice.rollup1.eth<>rollup2.short#BBBBBBBB Non-evm chain -- bc1..23@bip122:000000000019d6689c085ae165831e93#CCCCCCCC -- alice.eth@bip122:000000000019d6689c085ae165831e93#CCCCCCCC +- bc1..23<>bip122:000000000019d6689c085ae165831e93#CCCCCCCC +- alice.eth<>bip122:000000000019d6689c085ae165831e93#CCCCCCCC Assuming the shortcode list adds a few other CAIP namespaces -- alice.eth@btc.short#CCCCCCCC +- alice.eth<>btc.short#CCCCCCCC ``` > [!NOTE] @@ -252,7 +253,7 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA - If it resolves to the same address, then proceed normally - If it resolves to a different address, including an empty bytes array, display the address raw and optionally show a warning to the user. 15. Compute the checksum as described in [ERC-7930]: `0xC69BEB13`. -16. Format the address in the format `
@#` and display it to the user: `alice.eth@oeth.short#C69BEB13` +16. Format the address in the format `
<>#` and display it to the user: `alice.eth<>oeth.short#C69BEB13` [^2]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. @@ -274,7 +275,7 @@ The naming scheme herein defined can represent all names supported by [ERC-7930] ## 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. - Maintaining a list of chain/name registries instead of a list of chains means it'd have to be updated less frequently, allowing for more extensive review of new entries. -- Wallet developers should be aware of possible unicode glyph collisions in resolved names and warn users about them in order to keep checksums effective, since an attacker could, in order to impersonate `alice.eth@chain.short#00112233`: +- Wallet developers should be aware of possible unicode glyph collisions in resolved names and warn users about them in order to keep checksums effective, since an attacker could, in order to impersonate `alice.eth<>chain.short#00112233`: - Mine an address on `chain.short` such that the checksum of the Interoperable Address is `00112233`. - Register `аlice.eth` (using the russian vowel `а` instead of the latin `a`), and point it to the address above. From 34cc645f6d9a382abb5b9d8b83934ecff7d159b0 Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 5 May 2025 18:28:16 -0300 Subject: [PATCH 36/37] fix: minor issues --- ERCS/erc-7828.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index b79ab542eb4..fd3025883fd 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -12,7 +12,7 @@ requires: 55, 137, 155, 7785 --- ## Abstract -This proposal builds off of [ERC-7930] (Interoperable Addresses) and [ERC-7785] (on-chain configs) to provide a standard and human-readable format for chain-specific addresses which provides: +This proposal builds off of [ERC-7930] (Interoperable Addresses & Names) to provide a standard and human-readable format for chain-specific addresses which provides: - A unified format for accounts that specifies, together with the address, the chain where the address lives. - The use of human-readable chain names and how they can be resolved to chain identifiers. - The use of human-readable account names and how they can be resolved to addresses. @@ -53,19 +53,19 @@ This standard defines a sub-syntax with extra semantics on top of the syntax def : := | : := [0-9A-F]{8} -: := [.-:_%a-zA-Z0-9]+ -: := [.-:_a-zA-Z0-9]+ +: := [.-:_%a-zA-Z0-9]* +: := [.-:_a-zA-Z0-9]* : := . : := [a-zA-Z][-a-zA-Z0-9]{1,9} -: := ( . )? +: := ( . ) ? := [a-zA-Z][-a-zA-Z0-9]+ ``` Where: -- `` : Corresponds to a full, resolvable name on the defined by its `L0-TLD` +- `` : Corresponds to a full, resolvable name on the resolver defined by its `L0-TLD`. - ``, `` and `` are defined to maintain backwards compatibility with [ERC-7930], and their semantics remain the same. -- ``: Corresponds to an entry in the centralized [name resolver registry] +- ``: Corresponds to an entry in the centralized [^name resolver registry] Note the difference between ``, which is a fully qualified name, and `subdomain` that is just a segment of a name between dots. E.g. `user.app.eth` is a scoped name, `user` and `app` are subdomains. @@ -105,12 +105,11 @@ Assuming the shortcode list adds a few other CAIP namespaces > This standard does not explicitly define a hierarchical name structure for anything other than the top level domain, however it allows the underlying naming scheme to be hierarchical as in the ENS-in-rollup example. ### Checksum -Addreses 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. +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. This ensures that the checksum changes if any part of the address or chain ID is modified, turning dangerous manual edits into detectable errors for wallet users. ### The Name Resolver Registry - We propose for this ERC to strive to reach Final status instead of becoming a Living document, and maintain a separate dictionary for the different name resolving protocols or methods, similar to ethereum-lists/chains. The keys of this list will be ``s, and their associated values should be: @@ -258,7 +257,7 @@ Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAA [^2]: This is a clarification & recommendation on top of ENSIP-19, which is in Draft status and is somewhat ambiguous. ## 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. +- 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 - Further constrain the syntax of human-readable names to minimize: @@ -283,6 +282,8 @@ The naming scheme herein defined can represent all names supported by [ERC-7930] Copyright and related rights waived via [CC0](../LICENSE.md). + +[^name resolver registry]: Defined in github's ethereum-lists/chains repository as a living document. + [ERC-7930]: ./ERC-7930.md [ERC-7785]: ./ERC-7785.md -[name resolver registry]: TODO From 98ecaddeac894c0b42501bb0fe87f89c58b36e5d Mon Sep 17 00:00:00 2001 From: teddy Date: Mon, 5 May 2025 18:38:58 -0300 Subject: [PATCH 37/37] feat: allow for no resolution of address/chainid --- ERCS/erc-7828.md | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/ERCS/erc-7828.md b/ERCS/erc-7828.md index fd3025883fd..511914f6028 100644 --- a/ERCS/erc-7828.md +++ b/ERCS/erc-7828.md @@ -134,12 +134,16 @@ This is an easier list to maintain than ethereum-lists/chains, since it does not ### Example entries for the `L0-TLD` list +#### No resolution +Binary id: `0x0000` + +To be used in v2 Interoperable Addresses to indicate that no resolution is desired, and the 7930-style raw chain identifier used in the Interoperable Name instead. + > [!NOTE] -> This list does not define an example for the case where no resolution is desired, as in that case an Interoperable Address v2 can be used instead - +> In the case where both `ChainResolver` and `AddressResolver` are set to this value, the resulting Interoperable Name would match an Interoperable Name from ERC-7930 #### `.short` -Binary id: `0x0000` +Binary id: `0x0001` ##### Chain naming @@ -163,7 +167,7 @@ Simply refer to the table below Not supported #### `.eth` -Binary id: `0x0001` +Binary id: `0x0002` ###### Supported CASA namespaces `eip155` and anything supported by SLIP-0044 for forward resolution (Interoperable Address -> human-readable name) @@ -197,15 +201,15 @@ Where: - `Version` : A 2-byte version identifier. must be big-endian unsigned integer `2`. - `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength`, `Address`: Same as in [ERC-7930] -- `ChainResolver`: 2-byte identifier of the method used to resolve the chain to a human-readable string, from the [name resolver registry]. -- `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the [name resolver registry]. +- `ChainResolver`: 2-byte identifier of the method used to resolve the chain to a human-readable string, from the [^name resolver registry]. +- `AddressResolver`: 2-byte identifier of the method used to resolve the address to a human-readable string, from the [^name resolver registry]. ### Forward resolution step-by-step example 1. Let the user input an address name. Assume it's `alice.eth` 2. Let the user select a chain. Assume it's `oeth.short` 3. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 2. For this example it's `.short`. -4. Look up the result from the step above on the [name resolver registry] to know what to do with the entirety of the result from step 2. In this case, the hardcoded table says it corresponds to +4. Look up the result from the step above on the [^name resolver registry] to know what to do with the entirety of the result from step 2. In this case, the hardcoded table says it corresponds to - chain namespace: `eip155` - chain reference: `10` (chainid of OP Mainnet) 5. Look up the TLD (characters from the last dot up to the end of the string) of the result of step 1. For this example it's `.eth`, meaning we should attempt resolution via ENS. @@ -217,27 +221,27 @@ Where: 10. Begin serialization into an Interoperable Address v2 by appending the version: `[0002]` 11. Serialize `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-7930]: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ]` 12. Append the binary id for the `ChainResolver` and `AddressResolver` from the Name Resolver Registry: `[ 0002 0000 01 0A 14 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0000 0001]` -13. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` +13. Interoperable Address is complete: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000002` 14. Compute the checksum as described in [ERC-7930]: `0xC69BEB13` and display it to the user. [^1]: While this sees production usage, it is not consistent with the design principles behind [ERC-7930] and assumes 32-bit chainids, which are not compatible with an [ERC-7785] future. We recommend using something closer to what is described in footnote 2. ### Reverse Resolution step-by-step example -Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` +Starting from the Interoperable Address serialized above: `0x00020000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00010002` -1. Pick the first two bytes corresponding to the version: `0x0002`. Remaining payload: `0000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00000001` -2. Parse the `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-7930]. Remaining payload `00000001` +1. Pick the first two bytes corresponding to the version: `0x0002`. Remaining payload: `0000010A14AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA00010002` +2. Parse the `ChainType`, `ChainReferenceLength`, `ChainReference`, `AddressLength` and `Address` according to [ERC-7930]. Remaining payload `00010002` 1. `ChainType`: `0x0000` -> `eip155` 2. `ChainReferenceLength`: `0x01` -> 1 3. `ChainReference`: `0x0A` -> 10 (OP Mainnet) 4. `AddressLength`: `0x14` -> 20 bytes, consistent with `eip155` 4. `Address`: `0xaAaAaAaaAaAaAaaAaAAAAAAAAaaaAaAaAaaAaaAa` -> alice's address -3. Since we know the address to be v2, defined above, pick the next two bytes as the `ChainResolver`: `0x0000` -> shortname list. Remaining payload: `0001` -4. Pick the next two bytes as `AddressResolver`: `0x0001` -> ENS. No remaining payload, parsing finished. -5. Look up the output of step 3 in the [name resolver registry]. It instructs to use the hard-coded shortcode list, with TLD `.short` +3. Since we know the address to be v2, defined above, pick the next two bytes as the `ChainResolver`: `0x0001` -> shortname list. Remaining payload: `0002` +4. Pick the next two bytes as `AddressResolver`: `0x0002` -> ENS. No remaining payload, parsing finished. +5. Look up the output of step 3 in the [^name resolver registry]. It instructs to use the hard-coded shortcode list, with TLD `.short` 6. Serialize the chain type (2.1) and chain reference (2.3) to CAIP-2 following [ERC-7930]: `eip155:10` 7. Look up the type reference on the shortcode list, and obtain the full name to use: `oeth.short` -8. Look up the output of step 4 in the [name resolver registry]. It instructs to use ENS. +8. Look up the output of step 4 in the [^name resolver registry]. It instructs to use ENS. 9. Convert the output from steps 2.1 and 2.3 to a reverse lookup string of the form `
..reverse`: `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.0000010A.reverse` - `` is the RFC-4648 base16 representation of the concatenated `ChainType`, `ChainReferenceLength` and `ChainReference` [^2] - `
` is the RFC-4648 base16 representation of the `Address` [^2]