@weijia31415 I think it’s very important that any enhancement of Ethereum’s address format includes the ability to encode multiple chain IDs, not just a single chain ID that is possible with EIP-1191. I’d like to experiment to see if it’s possible to devise a scheme that uses EIP-55 style case encoding to encode multiple Chain IDs into today’s Ethereum address format. This would be incompatible with also encoding an EIP-55 checksum into an address, but as we move towards a multi-chain world the need to encode multiple chain IDs in addresses will become more pressing.
I go into more details about why encoding multiple chain IDs in addresses is important in this comment Increasing address size from 20 to 32 bytes - #18 by greg7mdp
Due to the limited space available when using EIP-55 style case encoding to encode additional data into an Ethereum address, we will need the absolutely most compact representation of Chain IDs possible to service this usecase of encoding Chain IDs into Ethereum addresses. To make Chain IDs sufficiently compact to fit more than one into Ethereum’s current address format, we will probable need to set a upper bound on the number of Chain IDs that are available.
So regarding this proposal, perhaps it would also be useful to have a 2 byte representation of each chain ID which would give use 65536 possible Chain IDs to work with for when we encode Chain IDs into ethereum addresses?
Perhaps use 2 of the ‘Reserved’ 7 bytes (see the “Definition of a 32 byte crosschain id” table at the top of this thread) for this purpose? So with this change there would be a 2 byte shorthand for every ChainID that could be encoded in ethereum addresses.
Or reducing “Native Chain ID” from 4 bytes to 2 bytes might be a better option?
Either way, in order to encode multiple Chain IDs into the current ethereum address format, we probably need each Chain ID to be no more than 2 bytes.