Update EIP-2935: Further cleanup of the text

Merged by EIP-Bot.

EIPS/eip-2935.md

@@ -12,15 +12,13 @@ created: 2020-09-03
 
 ## Abstract
 
-Store last `HISTORY_SERVE_WINDOW` historical block hashes in the storage of a system contract as part of the block processing logic.
-
-This EIP has no impact on `BLOCKHASH` resolution mechanism (hence its range/costs etc).
+Store last `HISTORY_SERVE_WINDOW` historical block hashes in the storage of a system contract as part of the block processing logic. Furthermore this EIP has no impact on `BLOCKHASH` resolution mechanism (and hence its range/costs etc).
 
 ## Motivation
 
 EVM implicitly assumes the client has the recent block (hashes) at hand. This assumption is not future-proof given the prospect of stateless clients. Including the block hashes in the state will allow bundling these hashes in the witness provided to a stateless client. This is already possible in the MPT and will become more efficient post-Verkle.
 
-Extending the range of blocks `BLOCKHASH` can serve is a semantics change. Using the contract storage would allow extending that range in a soft-transition. Rollups can benefit from the longer history window through directly querying this contract.
+Extending the range of blocks which `BLOCKHASH` can serve (`BLOCKHASH_SERVE_WINDOW`) would have been a semantics change. Using extending that via this contract storage would allow a soft-transition. Rollups can benefit from the longer history window through directly querying this contract.
 
 A side benefit of this approach could be that it allows building/validating proofs related to last `HISTORY_SERVE_WINDOW` ancestors directly against the current state.
 
@@ -48,11 +46,11 @@ Alternatively clients can also choose to do a system update via a system call to
 
 Note that, it will take `HISTORY_SERVE_WINDOW` blocks after `FORK_TIMESTAMP` to completely fill up the ring buffer. The contract will only contain the parent hash of the fork block and no hashes prior to that.
 
-As mentioned earlier the `BLOCKHASH` opcode semantics remains the same as before. However the clients which want to leverage the history from state may do so making sure the query is within `BLOCKHASH` range and is available in the contract.
+As mentioned earlier the `BLOCKHASH` opcode semantics remains the same as before. However the clients which want to leverage the history from state may do so making sure the query is within `BLOCKHASH_SERVE_WINDOW` and is available in the contract.
 
 ### Contract Implementation
 
-Exact evm assembly that can be used for the contract to resolve `BLOCKHASH`
+Exact evm assembly that can be used for the history contract:
 
 ```
 // if system call then jump to the set operation
@@ -82,7 +80,7 @@ gt
 push1 0x4b
 jumpi
 
-// check if blocknumber > input + 8192 then return 0, no overflow expected for input of 8 bytes
+// check if blocknumber > input + 8192 then return 0, no overflow expected for input of < max 8 byte value
 push0
 calldataload
 push2 0x2000