[pull] master from ethereum:master

EIPS/eip-8032.md

@@ -46,7 +46,7 @@ Account RLP descriptors receive an optional `storage_count` field, corresponding
 
 At `FORK_TIMESTAMP`, the transition is activated.
 
-The transition process involves reading all accounts and count the number of storage slots for accounts with non-empty storage root hashes, which in turns populate the `storage_count` field in the account.
+The transition process involves reading all accounts and count the number of storage slots for accounts with non-empty storage root hashes, which in turn populates the `storage_count` field in the account.
 
 The progress of the transition is stored at system contract at `TRANSITION_REGISTRY_ADDRESS`.
 
@@ -127,9 +127,9 @@ def calculate_storage_delta(prestate_value, poststate_value):
         return 0    # No change in slot occupancy
 ```
 
-During a transition, the transition is advanced *first* before applying the storage deltas, but *after* executing all transactions, so the gas costs of a contract that is sweeped by the iterator in this block are only applied for the *next* block. Update semantics when a transition is occuring:
+During a transition, the transition is advanced *first* before applying the storage deltas, but *after* executing all transactions, so the gas costs of a contract that is sweeped by the iterator in this block are only applied for the *next* block. Update semantics when a transition is occurring:
 
-- For accounts that have finished iterated (i.e. `cursor_account_hash` > `acc_hash` ), all storage deltas are applied.
+- For accounts that have been iterated (i.e. `cursor_account_hash` > `acc_hash` ), all storage deltas are applied.
 - For accounts that have not been iterated at all (i.e. `acc_hash` > `cursor_account_hash`), none of the storage deltas are applied.
 - For the account currently being iterated (i.e. `cursor_account_hash` == `acc_hash`), storage deltas are applied only to the slots that have already been accounted for (i.e. `cursor_slot_hash` > `slot_hash`).
 
@@ -174,7 +174,7 @@ This is a conservative upper bound. In practice, most contracts have far fewer s
 
 ## Rationale
 
-The intent is to create friction in when growing the state size of a contract, thus limiting the number of such contracts. Going over the limit, some contract developers might want to use another contract to start fresh, which comes at the cost of paying for contract creation, and for any call into the previous instance of the contract.
+The intent is to create friction when growing the state size of a contract, thus limiting the number of such contracts. Going over the limit, some contract developers might want to use another contract to start fresh, which comes at the cost of paying for contract creation, and for any call into the previous instance of the contract.
 
 `ACTIVATION_THRESHOLD` is chosen to not penalize the contracts that are large, but do provide useful value. The idea is to disincentivize spam contracts that grow larger than useful contracts, the latter being legitimately big due to the value they bring to their users and the wider ecosystem. This means that this constant could be increased as the state grows.
 
@@ -204,7 +204,7 @@ Under a unified tree, the per-write computational and I/O cost of `SSTORE` no lo
 
 ### Compatibility with EIP-2926
 
-Because [EIP-2926](./eip-2926.md) also requires an account transition to chunkify the bytecode and additional additional fields, scheduling both EIPs in the same fork enables a single, combined transition. This removes duplicated work, reduces client complexity and the number of tree transitions in the future.
+Because [EIP-2926](./eip-2926.md) also requires an account transition to chunkify the bytecode and additional fields, scheduling both EIPs in the same fork enables a single, combined transition. This removes duplicated work, reduces client complexity and the number of tree transitions in the future.
 
 ## Backwards Compatibility