What is the value-add to this specification that we get by segregating by networks that have a field colloquially called “chain ID”? Networks with a “network ID” (which functions identically to chain ID in this context) don’t count and should get their own top level name (like Morden)? What about when we have two networks that have a chain ID but collide with each other (there is no guarantee that chain IDs don’t collide, you only need to avoid collisions when you have multiple chains that share a network protocol)?
Could we achieve the same goal by saying “any network that has a numeric identifier”? This would at least be a bit more consistent and useful, because it allows us to do some grouping without having to set such an arbitrary group boundary and ensure that the second field is a number.
What was the outcome of this discussion? I’ve encountered the error “ProviderError: only replay-protected (EIP-155) transactions allowed over RPC” when trying to do keyless deployment, similar to what’s done in your deterministic deployment proxy, so was wishing EIP-155 wasn’t so enforced.
Last I heard, Ethereum doesn’t have a concrete plan to deprecate old transaction types. Individual nodes for some blockchains disable the propagation of legacy transaction types, but I don’t think any Ethereum client does that by default (I could be wrong on this).
The fundamental problem is that if the chain you are aiming for forked 10 minutes ago, and you ended up sending all your money to e.g. the Eth PoW chain because you didn’t realise that, it might not be what you meant to do.
It seems a problem well worth solving, and one that doesn’t seem even a bit solved today (the EEA spec / EIP 3220 nods toward dealing with forking, but I don’t think it solves it properly).
ChainIDs aren’t guaranteed not to collide by the structure of the network (yet, anyways)-- they are collision-protected by the curation of the registry and social norms/assumptions around it. Registries aren’t the most dEcEnTrAlIzEd way of organizing a namespace, but they are a classic conflict resolution mechanism, and they can (in the best of cases) be fairly transparent and credibly neutral if operated well. Registries basically organize all the chaos of the first two worldwide webs; IANA is basically critical infrastructure if we’re being honest.
If a network wants to re-use a chainId that’s already been registered by another network, then things would certainly get complicated (you’d basically have to find some other way to disambiguate which network the node you’re talking to is in). One could argue that the registry is a “polite software”/opt-in governance model and that it only works as well as it does because registering a network on it is a requirement for many DEXs and block explorer support. But curiously, chainId collisions and impersonations don’t come up nearly as often as you’d expect them to. After the EthPOW fork, there was briefly a concern that they would actually keep chainId 1 and start harvesting signatures (remember those janky websites that were essentially phish farms where you could sell the POW copy of your Eth Mainnet assets?), but eventually they switched to 10001.
For clarity, my issue isn’t with having a registry, or even having a semi-centralized registry (though censorship resistant registries I do think are very important) but with the concept of namespaces as proposed by this standard, and with using chainId as the unique identifier for chains (rather than native token ticker or simply its name).