Update EIP-1011: remove repetitive words (ethereum#8373)

EIPS: remove repetitive words

Signed-off-by: stayweek <[email protected]>

EIPS/eip-1011.md

@@ -342,7 +342,7 @@ Most other decisions were made to minimize changes across clients. For example,
 #### Deploying Casper Contract
 The `MSG_HASHER_CODE` and `PURITY_CHECKER_CODE` both do not require any initialization so the EVM bytecode can simply be placed at `MSG_HASHER_ADDR` and `PURITY_CHECKER_ADDR`. On the other hand, the casper contract _does_ require passing in parameters and initialization of state. This initialization would normally occur by the EVM init code interacting with the CREATE opcode. Due to the nature of this contract being deployed outside of normal block transactions and to a particular address, the EVM init code/CREATE method requires client specific "hacks" to make it work. For simplicity of specifying across clients, the EVM bytecode -- `CASPER_CODE` -- is placed at `CASPER_ADDR` followed by an explicit `CALL` to a one-time `init` method on the casper contract. `init` handles all of the logic that a constructor normally would, accepting contract parameters as arguments and setting initial variable values, and can only be run _once_.
 
-`CASPER_INIT_DATA` is composed of the the byte signature of the `init` method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order:
+`CASPER_INIT_DATA` is composed of the byte signature of the `init` method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order:
 
   * `EPOCH_LENGTH`
   * `WITHDRAWAL_DELAY`

EIPS/eip-1057.md

@@ -326,7 +326,7 @@ uint32_t math(uint32_t a, uint32_t b, uint32_t r)
 
 The flow of the inner loop is:
 * Lane `(loop % LANES)` is chosen as the leader for that loop iteration
-* The leader's `mix[0]` value modulo the number of 256-byte DAG entries is is used to select where to read from the full DAG
+* The leader's `mix[0]` value modulo the number of 256-byte DAG entries is used to select where to read from the full DAG
 * Each lane reads `DAG_LOADS` sequential words, using `(lane ^ loop) % LANES` as the starting offset within the entry.
 * The random sequence of math and cache accesses is performed
 * The DAG data read at the start of the loop is merged at the end of the loop

EIPS/eip-161.md

@@ -66,4 +66,4 @@ On 2016-11-24, a consensus bug occurred due to two implementations having differ
 1. EIP-158 issue and discussion: https://github.com/ethereum/EIPs/issues/158
 2. EIP-161 issue and discussion: https://github.com/ethereum/EIPs/issues/161
 3. https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/
-> Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.
+> Details: Geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an out-of-gas exception. An additional issue was found in Parity, where the Parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new Geth behavior matches Parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes.

EIPS/eip-1706.md

@@ -26,7 +26,7 @@ https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_consta
 
 ## Specification
 
-Add the following condition to to the SSTORE opcode gas cost calculation:
+Add the following condition to the SSTORE opcode gas cost calculation:
 
 * If *gasleft* is less than or equal to 2300, fail the current call frame
   with 'out of gas' exception.

EIPS/eip-1930.md

@@ -127,7 +127,7 @@ This solution does not require to compute a ```E``` value and thus do not relies
 But this check still pass if the gas given was less AND the external call reverted or succeeded EARLY (so that the gas left after the call > txGas / 63).
 This can be an issue if the code executed as part of the CALL is reverting as a result of a check against the gas provided. Like a meta transaction in a meta transaction.
 
-Similarly to the the previous solution, an EVM mechanism would be much better.
+Similarly to the previous solution, an EVM mechanism would be much better.
 
 ## Backwards Compatibility
 

EIPS/eip-2539.md

@@ -194,7 +194,7 @@ Error cases:
 
 ### Prevention of DDoS on error handling
 
-This precompile performs extensive computations and in case of any errors during execution it MUST consume all gas from the the gas schedule for the corresponding operation.
+This precompile performs extensive computations and in case of any errors during execution it MUST consume all gas from the gas schedule for the corresponding operation.
 
 ### Gas schedule
 

EIPS/eip-3026.md

@@ -190,7 +190,7 @@ Error cases:
 
 ### Prevention of DDoS on error handling
 
-This precompile performs extensive computations and in case of any errors during execution it **MUST** consume all gas from the the gas schedule for the corresponding operation.
+This precompile performs extensive computations and in case of any errors during execution it **MUST** consume all gas from the gas schedule for the corresponding operation.
 
 ### Gas schedule
 

EIPS/eip-4396.md

@@ -150,7 +150,7 @@ Under PoS, each slot has a [fixed assigned timestamp](https://github.com/ethereu
 ### Suppressing Base Fee Increases
 As discussed in the rationale, a high value for `MAX_GAS_TARGET_PERCENT` during times of many offline block proposers results in a small remaining signal space for genuine demand increases that should result in base fee increases. This in turn decreases the cost for block proposers for suppresing these base fee increases, instead forcing the fallback to a first-price priority fee auction.
 
-While the arguments of incentive incompatibility for base fee suppression of the the base EIP-1559 case still apply here, with a decreasing cost of this individually irrational behavior the risk for overriding psychological factors becomes more significant.
+While the arguments of incentive incompatibility for base fee suppression of the base EIP-1559 case still apply here, with a decreasing cost of this individually irrational behavior the risk for overriding psychological factors becomes more significant.
 
 Even in such a case the system degradation would however be graceful, as it would only temporarily suspend the base fee burn. As soon as the missing block proposers would come back online, the system would return to its ordinary EIP-1559 equilibrium.
 

EIPS/eip-6690.md

@@ -56,7 +56,7 @@ An arithmetic operation is performed on inputs at index `x`/`y` placing the resu
 | `SETUPX_BASE_GAS` | 3 | base gas cost for `SETUPX` opcode |
 | `EVMMAX_MAX_MEM` | 65,536 bytes | maximum amount of EVMMAX memory that can be used in a call frame |
 | `MAX_MOD_SIZE` | 4096 bits | tentative modulus size limit (can probably be removed because `EVMMAX_MAX_MEM_SIZE` effectively caps the modulus size) |
-| `MULMODX_SUBQUADRATIC_START` | 50 | modulus size in in multiples of 8 bytes where we switch to subquadratic mulmont cost model |
+| `MULMODX_SUBQUADRATIC_START` | 50 | modulus size in multiples of 8 bytes where we switch to subquadratic mulmont cost model |
 | `SYSTEM_WORD_SIZE_BITS` | varies depending on the system | word size in bits of a client's CPU |
 
 ### Context Variables

EIPS/eip-6916.md

@@ -56,7 +56,7 @@ To ensure a successful reset, `ForkDigest` needs to be unique for each iteration
 
 The update of `genesis.validators[0]` changes the state, therefore, clients have to be able to generate or download the latest genesis state. Generating the genesis ssz is not considered a standard client feature and adding it enables to trustlessly create the latest genesis state at the price of certain complexity. An alternative solution is to obtain it from a third party, either by downloading the ssz file from a server or using the checkpoint sync feature with an endpoint serving the genesis state. This became an accepted practice with Holešky testnet and the existing feature can be used for obtaining genesis states for automatically reset testnets. It also allows maintainers to update the genesis validator set without requiring new client releases. The full implementation of the recommended practice for obtaining the latest CL state should behave as follows:
 
-* When the the testnet flag is provided and client supports checkpoint sync of genesis, automatically use the hardcoded checkpoint endpoint to download the latest genesis state using the checkpoint sync feature
+* When the testnet flag is provided and client supports checkpoint sync of genesis, automatically use the hardcoded checkpoint endpoint to download the latest genesis state using the checkpoint sync feature
   * If user provides a custom checkpoint sync flag, override the default option and use the endpoint provided by user
 * Include a backup download option pointing to an url with the latest testnet release, a publicly distributed ssz file, and trigger this option if the checkpoint state sync fails or make it the default if client doesn't support genesis checkpoint sync
 * If the client includes a feature for generating the genesis, use it to verify parameters in the downloaded state and issue an error if values or checksum don't correspond