Update EIP-2294: Move to Review (ethereum#5763)

* init chainidsize EIP pr

* Recover the content from ethereum#2294

* EIP formating

* EIP formatting

* Update authost list and add credt

* Move to Review

* Update EIPS/eip-2294.md

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>

* Update EIPS/eip-2294.md

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>

* Update EIPS/eip-2294.md

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>

* Update eip-2294.md

* Update eip-2294.md

* Move to Review status

* Update eip-2294.md

* Update eip-2294.md

* update format

* Fix typos

* Fix typos

Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>

EIPS/eip-2294.md

@@ -4,51 +4,56 @@ 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
 requires: 155
 ---
 
 ## Abstract
+
 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`
 
-> 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.
+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. 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.
 
 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.
+Without a well-chosen value of Chain ID, there could be differences in the implementation of [EIP-155](./eip-155.md) (and [EIP-1344](./eip-1344.md) 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
+Also, the field `chainID` have experienced increasing usage 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 yields identical result for verification in
 all cases.
 
 Originally, this EIP was created by Bryant Eisenbach (@fubuloubu) and Alex Beregszaszi (@axic).
 
 ## Specification
+
 Starting from `blocknum = FORK_BLKNUM`, the maximum value of Chain ID is `9,223,372,036,854,775,771` (`MAX_CHAIN_ID`).
 
 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. 
+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
+
 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, 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.
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).