docs: clarify JSON-RPC references and grammar in EIP-2294

EIPS/eip-2294.md

@@ -12,15 +12,15 @@ requires: 155
 
 ## Abstract
 
-This EIP informationally defines the "Safe Range" and "Max Range" of ChainId based on a few known restrictions such as [EIP-155](./eip-155.md) and major wallet and JsonPRC representation of ChainId.
+This EIP informationally defines the "Safe Range" and "Max Range" of ChainId based on a few known restrictions such as [EIP-155](./eip-155.md) and major wallet and JSON-RPC representation of ChainId.
 
 ## Motivation
 
-1. We want chainId to be safe across the different components of the ecosystem such as smart contract, wallet, dApp and JsonPRC etc.
+1. We want chainId to be safe across the different components of the ecosystem such as smart contract, wallet, dApp and JSON-RPC etc.
 2. We want to enable Cross-Chain function call
 3. We want to ensure [EIP-712](./eip-712.md) domains have a clear definition of how to pack ChainID.
-4. Enable possbile expansion of chains, such as increasing amount of L2s, L3s, or shards of Ethereum mainnets.
-5. Enable hashed based temparary chain: 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.
+4. Enable possible expansion of chains, such as increasing amount of L2s, L3s, or shards of Ethereum mainnets.
+5. Enable hashed based temporary chain: 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
 
@@ -43,7 +43,7 @@ and suggests a reasonable maximum enforced size in order to ensure that there ar
 
 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.
 
-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), [ERC-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
+Also, the field `chainID` has 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), [ERC-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.
 
 ## Backwards Compatibility

EIPS/eip-3855.md

@@ -23,7 +23,7 @@
 We have conducted an analysis on Mainnet (block ranges 8,567,259…8,582,058 and 12,205,970…12,817,405), and ~11.5% of all the `PUSH*` instructions executed push a value of zero.
 
 The main motivations for this change include:
 1. Reducing contract code size.
 2. Reducing the risk of contracts (mis)using various instructions as an optimisation measure. Repricing/changing those instructions can be more risky.
 3. Reduce the need to use `DUP` instructions for duplicating zeroes.
 
@@ -47,7 +47,7 @@
 
 ## Backwards Compatibility
 
-This EIP introduces a new opcode which did not exists previously. Already deployed contracts using this opcode could change their behaviour after this EIP.
+This EIP introduces a new opcode which did not exist previously. Already deployed contracts using this opcode could change their behaviour after this EIP.
 
 ## Test Cases