Add ERC: Onchain registration of chain identifiers #669
Conversation
eip-review-bot
changed the title
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
Co-authored-by: Andrew B Coathup <28278242+abcoathup@users.noreply.github.com>
eip-review-bot
changed the title
|
The commit 2dc2b85 (as a parent of 37d6b72) contains errors. |
Updated Jeff's contact to GH user name Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
Co-authored-by: sampkaML <131076291+sampkaML@users.noreply.github.com>
|
|
||
| Current chain identifiers are usually chosen arbitrarily to be short. While these identifiers are convenient on a small scale, as their number increases it is more desirable to draw them from a larger space. | ||
|
|
||
| We propose to extend the size of identifiers to 32 bytes and to derive them using a cryptographic hash function. |
There was a problem hiding this comment.
Are there any chain_ids registered in eth-lists/chains of this size already? if all keccak chain_id's generated this way have the same length, should eth-lists/chains STOP allowing registrations of that length to prevent [malicious] collisions?
There was a problem hiding this comment.
i like the idea of L2s and L3s using this mechanism and reducing traffic/burden on eth-lists/chains, but eth-lists/chains will still be needed for lots of non-L2 use-cases, so I think the smooth continued operation of eth-lists/chains should be in-scope for this ERC!
There was a problem hiding this comment.
@sampkaML - what are your thoughts on this?
There was a problem hiding this comment.
I agree with preventing eth-lists/chains from allowing registrations of this length due to your stated reason of avoiding [malicious] collisions.
However, regarding the continued use of existing eth-lists/chains and their inclusion within the scope of this ERC, I'm not sure I agree. What would be the downside of allowing the current ones to continue but stopping new registrations unless they follow this new format?
There was a problem hiding this comment.
Simple: not every Eth transaction that needs replay protection is settling on an L2 anchored to mainnet (or to any other EVM chain), and those chains can't use this new registry. Private networks, permissioned networks, EVM-mode L2s of other L1s, all need chainIds (and can't be accessed via a contract that they anchor to on mainnet).
There was a problem hiding this comment.
While I understand the concerns about private networks and other unique use cases, these issues aren't addressed by the current ENS implementation either. Our goal with this ERC isn't to solve every possible problem but to apply the 80/20 rule—improving the system for the vast majority of users. By focusing on the common scenarios where this solution will have the most impact, we can make meaningful progress now and address the remaining specialized cases with tailored solutions in the future.
There was a problem hiding this comment.
@bumblefudge, which chains specifically will be adversely impacted by this change now?
There was a problem hiding this comment.
Hi, I would suggest to think about this EIP as a solution for any EVM, even outside the L1+L2s ecosystem. Some reasons:
- chain teams already submit their info (name, chainID, etc.) to ethereum-lists/chains because that’s the ultimate source of truth for the list of all EVMs, so asking them to submit a transaction in order to do the same thing they would do already seems like a reasonable compromise
- From our research (I work at routescan.io) there are currently roughly 1200 chains live at the moment, of which roughly 85% is EVM, and even though the pace of growth has increased, we don’t forecast millions of chains within the foreseeable future, so increasing the size of the identifiers to 32 bytes may not be needed.
Co-authored-by: Bumblefudge <caballerojuan@pm.me>
|
|
||
| An example for a L2: | ||
| ``` | ||
| chain_id = Keccak-256(CHAIN_NAME, SETTLEMENT_CHAIN_ID, VERSION, DEPLOYER_CONTRACT_ADDRESS, SALT) |
There was a problem hiding this comment.
I would suggest allowing null or 0 input for the SETTLEMENT_CHAIN_ID and DEPLOYER_CONTRACT_ADDRESS, so as to allow non-L2 use cases as well.
Also, I believe another input should be the chainID of the DA its posting data to, since it’s becoming very frequent to see chains not posting data to blobs on L1 but to DAs on other EVMs or even on other VMs (see NEAR or Avail).
This new onchain registry could help a lot block explorer providers like us because it tells us immediately how to index the chain, and if there’s some extra indexing to add to scan the chain properly.
Another useful field could be the ‘stack’ the chain is using: OP Stack, ZK Stack, etc. Again, it helps with identification and categorization. These may be a lot of fields, but as we saw in some cases, chains change their nature: changing stack, posting to a different DA layer, etc. If the chain changes his nature, it needs to change chainID.
We found out that a lot of our customers often re-deploy their testnet chains multiple times under the same chainID, and they have no clue that this is actually a bad idea: a lot of tools use the chainID as the unique identifier for a chain, so if a chain has changed significantly (not referring to an upgrade, but a significant shift like, for example Lisk or Celo moving from L1 to L2), this can lead to tools having to reset their data about that specific chain, when they could simply add a new database / bucket / collection for the new chain, if the chainID were changed.
Some of these fields need to be in the input, so that changing those will change the chainID directly, but some can just be linked to attestations that provide useful information for all infra providers.
There was a problem hiding this comment.
Thank you for your insightful suggestions. I agree that allowing null or zero inputs for SETTLEMENT_CHAIN_ID and DEPLOYER_CONTRACT_ADDRESS would accommodate non-L2 use cases and enhance the versatility of the registry.
However, my main concern is that I prefer not to dictate which inputs are required or optional within this ERC itself. I believe our primary goal should be to offer a flexible framework that includes all these options, allowing future ERCs—such as those focusing on interoperability—to specify the requirements for these variables, including which can be null or zero. This approach ensures that the ERC remains adaptable to a variety of use cases and can evolve with the ecosystem's needs.
There was a problem hiding this comment.
I understand, and I believe this needs to become an ERC as quick as possible so that the conversation with the wide community can start. Let's make it as flexible as possible so that future work can address extensions for interoperability.
@sampkaML So you think other info, like DA layer, tech stack and others could be part of a new attestation-based spec / ERC?
| TODO: Remove this comment before submitting | ||
| --> | ||
|
|
||
| TBD |
There was a problem hiding this comment.
When will the rationale section be filled in? I have some questions around the rationale (see other comments) for certain decisions that I suspect would be covered here
|
|
||
| For example the chain name `rollup` can be converted to a chain identifier on Mainnet by resolving: | ||
| ``` | ||
| rollup.eth -> {version : uint, bridge : address, chain_id : chain_id} |
There was a problem hiding this comment.
How are testnets handed, are they also registed as e.g. rollup-sepolia.eth on mainnet, or are they be registered in the Sepolia or Holesky ENS deployments?
|
|
||
| An example for a L2: | ||
| ``` | ||
| chain_id = Keccak-256(CHAIN_NAME, SETTLEMENT_CHAIN_ID, VERSION, DEPLOYER_CONTRACT_ADDRESS, SALT) |
There was a problem hiding this comment.
What is DEPLOYER_CONTRACT_ADDRESS? It's not defined below
There was a problem hiding this comment.
I believe this is equal to the genesis contract address, it's for L2s/L3s. If it's not intended like this, then further specifications are needed.
|
|
||
| An example for a L2: | ||
| ``` | ||
| chain_id = Keccak-256(CHAIN_NAME, SETTLEMENT_CHAIN_ID, VERSION, DEPLOYER_CONTRACT_ADDRESS, SALT) |
There was a problem hiding this comment.
Is VERSION arbitrarily specified by the rollup, i.e. it refers to the rollup's version, or does it refer to the version of this ERC to support updates to the scheme defined here?
| - `SETTLEMENT_CHAIN_ID` is the id of the L1 where the L2 settles, it could be Mainnet or a testnet. | ||
| - `VERSION` is to separate the domain of the hash function with an arbitrary string | ||
| - `BRIDGE` is the address of the L2 on the L1 |
There was a problem hiding this comment.
A few questions here:
- What does "settle" mean? Is this where calldata / state diffs are posted, or where withdrawal proofs are, etc?
- Is this ERC intended to cover rollups only (seems like yes based on
SETTLEMENT_CHAIN_ID) or any chain (implied by the abstract and motivation)? - What if a chain only posts calldata to an alt-DA layer and has no settlement chain ID? This DA layer could be a centralized server that has no chain ID
- What if a chain has two bridges it accepts deposits from? Or no bridges? See https://youtu.be/Aey1_acXL0k?si=cNdwikh15P6EFNIi
To sidestep these questions, perhaps we simplify this to the approach to unique identification here to just be the chain name, and some type of version identifier. Does adding everything else to the hash add any value? All other metadata can still live onchain in an ENS record of myRollup.eth, but doesn't have to be used to derive the chain ID
There was a problem hiding this comment.
Completely agree here on 3. and 4., but it seems this is a first implementation, hence needs to be as general and flexible as possible.
As I was describing in another comment, the fields could be reduced to three or four and the rest of the information can be posted as metadata included in an attestation, so that this registry truly becomes the ultimate source of truth and hub for all EVM chains.
|
|
||
| ### Chain name resolution | ||
|
|
||
| Any ENS name can resolve to a chain identifier as specified in ENSIP-11. The name should resolve to a record containing not only the chain identifier, but also all the optional information necessary to verify the identifier. |
There was a problem hiding this comment.
How does resolution work? I have not used ENS for resolving anything other than addresses. Do we need to specify custom resolvers, or certain records to store data in?
| ### Bootstrapping and handover | ||
|
|
||
| In order to bootstrap the handling of legacy chain identifiers, we imagine the EF populating the `chainid.reverse` domain, a temporary `l2.eth` for names and then handing them over. | ||
|
|
||
| - EF populates two subdomains `l2.eth` and `chainid.reverse` using Ethereum lists. | ||
| - A rollup registers a `rollup.eth` and points it to their `chain_id. | ||
| - EF hands over to the rollup `rollup.l2.eth` and `chain_id.chainid.reverse` | ||
| - The rollup updates `chain_id.chainid.reverse` to return `rollup.eth` |
There was a problem hiding this comment.
What stops a chain from always using the legacy process and getting whatever chain ID they want? Is this a one time migration somehow? I don't fully understand the EF's role here
There was a problem hiding this comment.
I can tell that a lot of chains use random chainID and don’t care about collision until they reach Mainnet (or a bit after that, unfortunately). Chains that don’t adhere to this registry will always be there, but I guess new ERCs could be implemented that design an ‘enforcement plan’ within and outside the Ethereum ecosystem.
| - The rollup updates `chain_id.chainid.reverse` to return `rollup.eth` | ||
|
|
||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
A lot of tooling currently doesn't support uint256 chain IDs, e.g. see MetaMask: https://github.com/MetaMask/metamask-extension/blob/39528b02100a6003f412bbef5e0b560002c945bc/shared/constants/network.ts#L229-L233
Part of this ERC will require an effort to ensure various tooling developers support uint256 chain IDs
There was a problem hiding this comment.
Ledger only supports up to 4 bytes chainIDs for clear signing!
For ledger it's harder to implement because it's at the level of their hardware/firmware
| - The rollup updates `chain_id.chainid.reverse` to return `rollup.eth` | ||
|
|
||
|
|
||
| ## Security Considerations |
There was a problem hiding this comment.
What happens when an ENS name expires and has a new owner? The new owner can change data, what problems will this cause for users? We may want to consider a way to freeze or lock the data so only a specific address can update it
This ERC proposes deriving chain identifiers by hashing their chain name (along with other relevant information) and using ENS to map chain names to these identifiers, replacing the centralized list currently maintained on GitHub.