Here are two mutually exclusive scenarios the EIP try to prevent/resolve
With the increasing number of chains, in particular in the post-sharding future of EVMs, some people want to use some hash function for collision resilient hashing functions e.g. keccak256(<human-readable-string") as a way to generate new chainIds which will be the full space of uint256
ChainId was being used be added to the parity bit for signatures e.g. EIP-712 which has a ceiling of floor(MAX_UINT64 / 2) - 36 unless we manipulate the algorithm.
These two requirement for chainId space must be resolved and I urge that we make a decision before Shanghai hardfork
One major concern I have with limiting chain IDs to ~63 bits is that you cannot then have a hash used as a chainID. I would want the limit to be 256, 384, or 512, or unspecified.
~63 bits of entropy is not sufficient collision resistance for a hash function, reasonable use or not.
What may be needed is for clients to present loud warning messages when chain IDs that are not supported by hardware wallets are used (and I think 32 bits is the real limit for that). Just a loud obnoxious warning if block height is < 100k (i.e. soon enough to reconsider your chain), not a hard block.
In today’s ACD, @xinbenlv advocated to prioritize EIP-2294 into shanghai fork. @MariusVanDerWijden responded that if it’s low cost, let’s do it, but don’t need to have a deadline to be shipped before Shanghai fork. @MicahZoltu responded support EIP-2294 that bounds chainId at its current proposed ceiling. Because it has been a de facto rule. @MicahZoltu further proposed that we don’t need to do any coding immediately, just need to agree as a group and call it a rule. @shemnon responded whether we should accept such bounding just because no one has ever used any chainId above bounds. Ask to think twice.
Perhaps we need to limit chainIDs expressable by transaction types.
For Type 0/legacy (Frontier) transactions the metamask limit is enforced, since integer math needs to be performed on the chain ID.
For Type 1 (Berlin) and Type 2 (London) transactions a 256 bit limit is enforced. There is no math done for these transactions: it is a binary blob moved around without encoding. The limit here comes from EVM limits of 256 bits returned from the CHAINID operation.
The impact being if you want to use a hashed ChainID you must use a modern transaction container.