From 55b1608c20138e5360bfb128f8c01ec118d5941c Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Wed, 28 Sep 2022 16:08:20 -0700 Subject: [PATCH 01/16] init chainidsize EIP pr --- EIPS/eip-chainidsize.md | 47 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 EIPS/eip-chainidsize.md diff --git a/EIPS/eip-chainidsize.md b/EIPS/eip-chainidsize.md new file mode 100644 index 0000000000000..a561aeb07e84c --- /dev/null +++ b/EIPS/eip-chainidsize.md @@ -0,0 +1,47 @@ +--- +eip: +title: +description: +author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> +discussions-to: +status: Draft +type: +category (*only required for Standards Track): +created: +requires (*optional): +--- + +This is the suggested template for new EIPs. + +Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. + +The title should be 44 characters or less. It should not repeat the EIP number in title, irrespective of the category. + +## Abstract +Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. + +## Motivation +The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? + +## Specification +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. + +The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). + +## Rationale +The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. + +## Backwards Compatibility +All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. + +## Test Cases +Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. + +## Reference Implementation +An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. + +## Security Considerations +All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. + +## Copyright +Copyright and related rights waived via [CC0](../LICENSE.md). From dc3c10a0c7c6ca81775bf126e05a7af0d51bd36c Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Wed, 28 Sep 2022 16:13:21 -0700 Subject: [PATCH 02/16] Recover the content from #2294 --- EIPS/eip-2294.md | 39 ++++++++++++++++++++++++++++++++++ EIPS/eip-chainidsize.md | 47 ----------------------------------------- 2 files changed, 39 insertions(+), 47 deletions(-) create mode 100644 EIPS/eip-2294.md delete mode 100644 EIPS/eip-chainidsize.md diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md new file mode 100644 index 0000000000000..b1ab2a1da03eb --- /dev/null +++ b/EIPS/eip-2294.md @@ -0,0 +1,39 @@ +``` +eip: 2294 +title: Explicit bound to Chain ID size +author: Bryant Eisenbach (@fubuloubu), Alex Beregszaszi (@axic), Zainan Victor Zhou (@xinbenlv) +discussions-to: +status: Draft +type: Standards Track +category: Core +created: 2019-09-19 +requires: EIP-155 +``` + +## Simple Summary +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. + +## Abstract +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. + +## Motivation +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)](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/109) 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. + +## Specification +The maximum value of Chain ID is `9,223,372,036,854,775,771` (`MAX_CHAIN_ID`). This value is `floor(MAX_UINT64 / 2) - 36`, and is chosen to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed. + +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 `CHAIN_ID * 2 + 36`, so clients must test to ensure no overflow conditions are encountered when the highest value is used. No underflow is possible. + +## Rationale +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. + +## Backwards Compatibility +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. + +## Test Cases +[Aleth PR](https://github.com/ethereum/aleth/pull/5742) + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/EIPS/eip-chainidsize.md b/EIPS/eip-chainidsize.md deleted file mode 100644 index a561aeb07e84c..0000000000000 --- a/EIPS/eip-chainidsize.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -eip: -title: -description: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> -discussions-to: -status: Draft -type: -category (*only required for Standards Track): -created: -requires (*optional): ---- - -This is the suggested template for new EIPs. - -Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. - -The title should be 44 characters or less. It should not repeat the EIP number in title, irrespective of the category. - -## Abstract -Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does. - -## Motivation -The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? - -## Specification -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. - -The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)). - -## Rationale -The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. - -## Backwards Compatibility -All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. - -## Test Cases -Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. - -## Reference Implementation -An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. If the implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. - -## Security Considerations -All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers. - -## Copyright -Copyright and related rights waived via [CC0](../LICENSE.md). From 8995860d22942c6e53f60656817fbeee8c814922 Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Wed, 28 Sep 2022 16:30:58 -0700 Subject: [PATCH 03/16] EIP formating --- EIPS/eip-2294.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index b1ab2a1da03eb..f6059335c69da 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -1,20 +1,18 @@ -``` +--- eip: 2294 title: Explicit bound to Chain ID size +description: Adds a maximum value to the Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter. author: Bryant Eisenbach (@fubuloubu), Alex Beregszaszi (@axic), Zainan Victor Zhou (@xinbenlv) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 status: Draft type: Standards Track category: Core created: 2019-09-19 -requires: EIP-155 -``` - -## Simple Summary -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. +requires: 155 +--- ## Abstract -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. +This EIP restricts the size of [EIP-155](./eip-155.md) Chain ID parameter to a particular maximum value `floor(MAX_UINT64 / 2) - 36`, in order to ensure that there is a standard around how this parameter is to be used between different projects. ## Motivation 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)](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/109) 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. From d795b874a164066fa0a3ccd30ae41fb415d59326 Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Wed, 28 Sep 2022 16:54:29 -0700 Subject: [PATCH 04/16] EIP formatting --- EIPS/eip-2294.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index f6059335c69da..b6ac6a7f31f66 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -33,5 +33,8 @@ This EIP introduces a change that affects previous implementations of this featu ## Test Cases [Aleth PR](https://github.com/ethereum/aleth/pull/5742) +## Security Considerations +No new security risks are introduced by this EIP. + ## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). +Copyright and related rights waived via [CC0](../LICENSE.md). From bee75c27ee6f988cb987ec8495abb6b136cede22 Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Thu, 29 Sep 2022 17:04:44 -0700 Subject: [PATCH 05/16] Update authost list and add credt --- EIPS/eip-2294.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index b6ac6a7f31f66..d179335fa737b 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -2,7 +2,7 @@ eip: 2294 title: Explicit bound to Chain ID size description: Adds a maximum value to the Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter. -author: Bryant Eisenbach (@fubuloubu), Alex Beregszaszi (@axic), Zainan Victor Zhou (@xinbenlv) +author: Zainan Victor Zhou (@xinbenlv), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 status: Draft type: Standards Track @@ -19,6 +19,7 @@ EIP-155 introduces the Chain ID parameter, which is an important parameter used 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. +Originally, this EIP was created by Bryant Eisenbach (@fubuloubu) and Alex Beregszaszi (@axic). ## Specification The maximum value of Chain ID is `9,223,372,036,854,775,771` (`MAX_CHAIN_ID`). This value is `floor(MAX_UINT64 / 2) - 36`, and is chosen to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed. From a3e11256c94af65fb55b332f53f52e5b8e558ca5 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Wed, 5 Oct 2022 13:23:11 -0700 Subject: [PATCH 06/16] Move to Review --- EIPS/eip-2294.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index d179335fa737b..dd403821c55e7 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -4,7 +4,7 @@ title: Explicit bound to Chain ID size description: Adds a maximum value to the Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter. author: Zainan Victor Zhou (@xinbenlv), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 -status: Draft +status: Review type: Standards Track category: Core created: 2019-09-19 From 61aab97f42fed4f2a8ad727a7883e11834a19426 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 10:11:09 -0700 Subject: [PATCH 07/16] Update EIPS/eip-2294.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-2294.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index dd403821c55e7..d179335fa737b 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -4,7 +4,7 @@ title: Explicit bound to Chain ID size description: Adds a maximum value to the Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter. author: Zainan Victor Zhou (@xinbenlv), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 -status: Review +status: Draft type: Standards Track category: Core created: 2019-09-19 From ff760880bfbe4aadb16d2e441932d358cd086a31 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 10:52:17 -0700 Subject: [PATCH 08/16] Update EIPS/eip-2294.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-2294.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index d179335fa737b..2ca26d09d633b 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -12,7 +12,7 @@ requires: 155 --- ## Abstract -This EIP restricts the size of [EIP-155](./eip-155.md) Chain ID parameter to a particular maximum value `floor(MAX_UINT64 / 2) - 36`, in order to ensure that there is a standard around how this parameter is to be used between different projects. +This EIP restricts the size of the [EIP-155](./eip-155.md) Chain ID parameter to a particular maximum value `floor(MAX_UINT64 / 2) - 36`, in order to ensure that there is a standard around how this parameter is to be used between different projects. ## Motivation 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)](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/109) 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. From 55a088cc4340dc51eb8d9ed82ae270b83045d66c Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 10:56:43 -0700 Subject: [PATCH 09/16] Update EIPS/eip-2294.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> --- EIPS/eip-2294.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index 2ca26d09d633b..8b920a4dd3646 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -20,6 +20,7 @@ EIP-155 introduces the Chain ID parameter, which is an important parameter used 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. Originally, this EIP was created by Bryant Eisenbach (@fubuloubu) and Alex Beregszaszi (@axic). + ## Specification The maximum value of Chain ID is `9,223,372,036,854,775,771` (`MAX_CHAIN_ID`). This value is `floor(MAX_UINT64 / 2) - 36`, and is chosen to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed. From e5ff968a84699099f64209c9b7583dfae7693b3a Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 11:02:40 -0700 Subject: [PATCH 10/16] Update eip-2294.md --- EIPS/eip-2294.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index 8b920a4dd3646..ead46e51209d5 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -15,7 +15,15 @@ requires: 155 This EIP restricts the size of the [EIP-155](./eip-155.md) Chain ID parameter to a particular maximum value `floor(MAX_UINT64 / 2) - 36`, in order to ensure that there is a standard around how this parameter is to be used between different projects. ## Motivation -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)](https://ethereum-magicians.org/t/eip-1344-add-chain-id-opcode/1131/109) 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. +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 the 109th comment of [EIP-1344](./eip-1344.md)'s `discussion-to` + +> Allowing it to be 256-bit wide means that the RLP encoding of a transaction must use >256-bit arithmetic to calculate the v field. + +<-- +TODO(xinbenlv): clean up motivation by splitting rationale of design decisions from motivation above. +--> + +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. From 3eb51c48c924c39952e4c35c5221c3d306057662 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 11:03:55 -0700 Subject: [PATCH 11/16] Update eip-2294.md --- EIPS/eip-2294.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index ead46e51209d5..1fd805d5bb50a 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -40,11 +40,8 @@ Without a well-chosen value of Chain ID, there could be differences in the imple ## Backwards Compatibility 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. -## Test Cases -[Aleth PR](https://github.com/ethereum/aleth/pull/5742) - ## Security Considerations -No new security risks are introduced by this EIP. +Needs discussion. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). From bf3ecfa8b2214b8be338704554f173841147fbee Mon Sep 17 00:00:00 2001 From: Zainan Victor Zhou Date: Thu, 6 Oct 2022 17:42:47 -0700 Subject: [PATCH 12/16] Move to Review status --- EIPS/eip-2294.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index 1fd805d5bb50a..fafd3dacca556 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -4,7 +4,7 @@ title: Explicit bound to Chain ID size description: Adds a maximum value to the Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter. author: Zainan Victor Zhou (@xinbenlv), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 -status: Draft +status: Review type: Standards Track category: Core created: 2019-09-19 @@ -20,8 +20,8 @@ EIP-155 introduces the Chain ID parameter, which is an important parameter used > Allowing it to be 256-bit wide means that the RLP encoding of a transaction must use >256-bit arithmetic to calculate the v field. <-- -TODO(xinbenlv): clean up motivation by splitting rationale of design decisions from motivation above. ---> +TODO(xinbenlv): clean up motivation by splitting rationale of design decisions from motivation above. +--> 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. From bbcef64da4b0a9e42008fa19261ae86c833e4e26 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 17:57:17 -0700 Subject: [PATCH 13/16] Update eip-2294.md --- EIPS/eip-2294.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index fafd3dacca556..4792e9bfb0e18 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -19,14 +19,13 @@ EIP-155 introduces the Chain ID parameter, which is an important parameter used > Allowing it to be 256-bit wide means that the RLP encoding of a transaction must use >256-bit arithmetic to calculate the v field. -<-- -TODO(xinbenlv): clean up motivation by splitting rationale of design decisions from motivation above. ---> - 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. +Also, the field `chainID` have experienced increasing useage and dependencies, due more and more contracts are depending on [EIP-1344](./eip-1344.md) to expose CHAIN ID in the smart contract execution. For example when used with [EIP-712](./eip-712.md), [EIP-1271](eip-1272.md) for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yeilds identical result for verification in +all cases. + Originally, this EIP was created by Bryant Eisenbach (@fubuloubu) and Alex Beregszaszi (@axic). ## Specification From c35e56b82543c3776fa5ca9aeca48576df23f177 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Thu, 6 Oct 2022 17:59:17 -0700 Subject: [PATCH 14/16] Update eip-2294.md --- EIPS/eip-2294.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index 4792e9bfb0e18..4fc71a5fdfeb1 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -23,7 +23,7 @@ and suggests a reasonable maximum enforced size in order to ensure that there ar 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. -Also, the field `chainID` have experienced increasing useage and dependencies, due more and more contracts are depending on [EIP-1344](./eip-1344.md) to expose CHAIN ID in the smart contract execution. For example when used with [EIP-712](./eip-712.md), [EIP-1271](eip-1272.md) for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yeilds identical result for verification in +Also, the field `chainID` have experienced increasing useage and dependencies, due more and more contracts are depending on [EIP-1344](./eip-1344.md) to expose CHAIN ID in the smart contract execution. For example when used with [EIP-712](./eip-712.md), [EIP-1271](./eip-1271.md) for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yeilds identical result for verification in all cases. Originally, this EIP was created by Bryant Eisenbach (@fubuloubu) and Alex Beregszaszi (@axic). From 152edee663a695c53a4be33f97467d625cd932ca Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Tue, 18 Oct 2022 10:48:33 -0700 Subject: [PATCH 15/16] Update eip-2294.md --- EIPS/eip-2294.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index 4fc71a5fdfeb1..bc331f99b7ce2 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -12,7 +12,7 @@ requires: 155 --- ## Abstract -This EIP restricts the size of the [EIP-155](./eip-155.md) Chain ID parameter to a particular maximum value `floor(MAX_UINT64 / 2) - 36`, in order to ensure that there is a standard around how this parameter is to be used between different projects. +Starting from `blocknum = FORK_BLKNUM`, this EIP restricts the size of the [EIP-155](./eip-155.md) Chain ID parameter to a particular maximum value `floor(MAX_UINT64 / 2) - 36`, in order to ensure that there is a standard around how this parameter is to be used between different projects. ## Motivation 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 the 109th comment of [EIP-1344](./eip-1344.md)'s `discussion-to` @@ -21,6 +21,9 @@ EIP-155 introduces the Chain ID parameter, which is an important parameter used 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. + +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. + 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. Also, the field `chainID` have experienced increasing useage and dependencies, due more and more contracts are depending on [EIP-1344](./eip-1344.md) to expose CHAIN ID in the smart contract execution. For example when used with [EIP-712](./eip-712.md), [EIP-1271](./eip-1271.md) for on-contract signature verification, chainId has been increasingly introduced for replay attack prevention. It's security critical to ensure clients depending on the chainId computation in cryptography yeilds identical result for verification in @@ -29,15 +32,20 @@ all cases. Originally, this EIP was created by Bryant Eisenbach (@fubuloubu) and Alex Beregszaszi (@axic). ## Specification -The maximum value of Chain ID is `9,223,372,036,854,775,771` (`MAX_CHAIN_ID`). This value is `floor(MAX_UINT64 / 2) - 36`, and is chosen to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed. +Starting from `blocknum = FORK_BLKNUM`, the maximum value of Chain ID is `9,223,372,036,854,775,771` (`MAX_CHAIN_ID`). -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 `CHAIN_ID * 2 + 36`, so clients must test to ensure no overflow conditions are encountered when the highest value is used. No underflow is possible. +1. Compliant client MUST reject a value outside of the range of `[0, MAX_CHAIN_ID]` in a provided transaction starting from `blocknum = FORK_BLKNUM` +2. Compliant client MUST 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 `CHAIN_ID * 2 + 36`, so clients must test to ensure no overflow conditions are encountered when the highest value is used. No underflow is possible. ## Rationale -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. +The `MAX_CHAIN_ID` is calculated to avoid overflow when performing uint64 math. For reference, a value of 0 or less is also disallowed. ## Backwards Compatibility -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. +This EIP introduces a change that affects previous implementations of this feature. However, as of time of writing(2022-10-18) 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. + +If any other chain is operating with a incompatible `chainId`, we advised they make proper arrangement when this EIP becomes adopted. ## Security Considerations Needs discussion. From e72a825d51dd5b5ebb7d1df4cd60f4b551ead3fb Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Tue, 18 Oct 2022 13:10:10 -0700 Subject: [PATCH 16/16] Update eip-2294.md --- EIPS/eip-2294.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2294.md b/EIPS/eip-2294.md index bc331f99b7ce2..51ff7af437146 100644 --- a/EIPS/eip-2294.md +++ b/EIPS/eip-2294.md @@ -4,7 +4,7 @@ title: Explicit bound to Chain ID size description: Adds a maximum value to the Chain ID parameter to avoid potential encoding issues that may occur when using large values of the parameter. author: Zainan Victor Zhou (@xinbenlv), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 -status: Review +status: Draft type: Standards Track category: Core created: 2019-09-19