Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
EIP-2294: Explicit bound to Chain ID size #2294
Adds a maximum value to the EIP-155 Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter.
This EIP restricts the size of EIP-155 Chain ID parameter to a particular maximum value, in order to ensure that there is a standard around how this parameter is to be used between different projects.
EIP-155 introduces the Chain ID parameter, which is an important parameter used for domain separation (replay protection) of Ethereum protocol signed messages. However, it does not specify any properties about the size that this parameter takes. @axic mentions this concern in EIP-1344 (comment) and suggests a reasonable maximum enforced size in order to ensure that there are no issues when encoding this parameter. This would allow a sufficient amount of different values for this parameter, which is typically chosen by community consensus as a genesis parameter for a given chain and thus does not change often.
There have been suggestions of using a hash-based identifier in place on Chain ID to allow the value to adapt over time to different contentious forks and other scenarios. This proposal does not describe this behavior, but ~63 bits of entropy should be enough to ensure that no collisions are likely for reasonable (e.g. non-malicious) uses of this feature for that purpose.
The maximum value of Chain ID is 9,223,372,036,854,775,771 (
A client should reject a value outside of this range in a provided transaction, and disallow a genesis configuration with a value for Chain ID outside of this limit. Due to how the calculation for chain ID is performed, the maximum value seen during the arithmetic is
Without a well-chosen value of Chain ID, there could be differences in the implementation of EIP-155 (and EIP-1344 by derivative) in both client codebase and external tooling that could lead to consensus-critical vulnerabilities being introduced to the network. By making this limit explicit, we avoid this scenario for Ethereum and any project which uses the Ethereum codebase.
This EIP introduces a change that affects previous implementations of this feature. However, since no known chain makes use of a value outside of the suggested bounds, there should not be an issue in adopting this limit on the size of this parameter, therefore the impact should be non-existent.
Copyright and related rights waived via CC0.