From 520176f3159f74debdd14009b2a17899549c53ba Mon Sep 17 00:00:00 2001 From: Josh Rudolf Date: Wed, 27 Nov 2024 00:00:33 -0800 Subject: [PATCH 1/9] 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 2/9] 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 3/9] 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 4/9] 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 5/9] 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 6/9] 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 7/9] 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 8/9] 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 9/9] 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