Moved the PR to the ERCs repo - please update to …/ethereum/ERCs/pull/669
Just curious if there are any updates to this EIP? Will this be added as a draft to the EIP website?
ERC-7785 says:
We propose to extend the size of identifiers to 32 bytes
According to EIP-2294: Explicit bound to Chain ID size , safe size of chain id is 31 (sic!) bytes. From that EIP:
(1, 2^31 - 1): “Safe Range”, the higher bound is decided by Javascript number
ERC-7785 may or may not be adopted. It’s just a proposal currently.
A desirable property of a chain id is that it can be embedded in a coin type. A wide (256-bit) chain id makes this impossible (assuming a coin type is a uint256).
Currently, small chain ids embed with 1 << 31 | <chain id>
If we’re fixated on 256 bits, could we modify this proposal such that bit 31 is always set if it is generated via 7785 with a comment that the same bit should be clear if the coin type is non-EVM?
IMO, a smaller bit width should be chosen so there still is room in the coin type space to embed other tagged information.
I’ve pushed a proposal to expand ENS to support an extensible chain format, which could allow for arbitrary-length chainids and possibly adding some metadata as well in the future: Use caip 350 in ENSIP-11 and ENSIP-19 by 0xteddybear · Pull Request #30 · ensdomains/ensips · GitHub
While that’d make the way re refer to chains potentially more consistent across different kind of usages. It wouldn’t be actually necessary to make 7785 work at a technical level:
Assuming the large chainids are the output of a hash function, the higher 28 bytes could be used to tell them apart from short chainids/cointypes. e.g currently ENSIP-11 compliant resolvers take a uint256 where the first 28 bytes are zero and the least significant 4 ones have their meaning determined by ENSIP-11 and ENSIP-9.
Currently, small chain ids are embedded as you say <224 zeros>1<31 bits of chain id>, but if we assume every coin type with upper bits set (>= 2^32) is EVM, there’s no room left for future ideas that want to carve out some part of this space.
The minimal suggestion is that 7785 chain ids have bit 31 force set: keccak256(...) | EVM_BIT, such that if any part of the upper <224 bits> is non-zero, it’s a wide coin type.
This restores the EVM_BIT but we’ve still lost the ability to embed further tags into a coin type. And if another ecosystem wants to expand beyond SLIP-44 and decide to use large coin types, then they have a 50% chance of setting EVM_BIT by accident and appearing like “oh, this is an EVM coin type”.
A better suggestion would be to truncate 7785 to a smaller number of bits, like 128 or 160, so there is ample space for future tagging.
The only oddity is that the EVM_BIT appears in the middle of this hash if we continue that convention.
I can see the following options assuming 160 bits:
<96 zeros><upper [32, 160) bits of chain id>1<lower [0, 31) bits of chain id>
(eg.keccak256(...)[:20] | EVM_BITw/bit 31 ignored)<64 zeros><160 bits of chain id>1<31 zeros>
(keepEVM_BITlogic, shift right by 32 to extract chain id)<95 zeros>1<160 bits of chain id>
(newWIDE_EVM_BIT = 1 << 160)
In all cases, the upper 64-96 bits are available for future use.