Update EIP-2935: Cleanup references and add some blockhash opcode cla…

…rifications

Merged by EIP-Bot.

EIPS/eip-2935.md

@@ -14,11 +14,13 @@ created: 2020-09-03
 
 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).
+
 ## 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 `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.
 
 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.
 
@@ -27,24 +29,26 @@ A side benefit of this approach could be that it allows building/validating proo
 | Parameter | Value |
 | - | - |
 | `FORK_TIMESTAMP` | TBD |
+| `BLOCKHASH_SERVE_WINDOW` | `256` |
 | `HISTORY_SERVE_WINDOW` | `8192` |
-| `BLOCKHASH_OLD_WINDOW` | `256` |
 | `SYSTEM_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe` |
 | `HISTORY_STORAGE_ADDRESS` | `0x0aae40965e6800cd9b1f4b05ff21581047e3f91e`|
 
-This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length.
+This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length. Note that `HISTORY_SERVE_WINDOW` > `BLOCKHASH_SERVE_WINDOW` (which remains unchanged).
 
-At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the history in the following way:
+At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the state directly in the following way:
 
 ```python
 def process_block_hash_history(block: Block, state: State):
     if block.timestamp >= FORK_TIMESTAMP:
         state.insert_slot(HISTORY_STORAGE_ADDRESS, (block.number-1) % HISTORY_SERVE_WINDOW , block.parent.hash)
 ```
 
+Alternatively clients can also choose to do a system update via a system call to the contract `set` mechanism defined in the following sections.
+
 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.
 
-The `BLOCKHASH` opcode semantics remains the same as before.
+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.
 
 ### Contract Implementation
 
@@ -175,11 +179,13 @@ Some activation scenarios:
 
 ### [EIP-158](./eip-158.md) handling
 
-The bytecode above will be deployed à la [EIP-4788](./eip-4788.md). It just supports a `get` method to resolve block hashes. As such the account at `HISTORY_STORAGE_ADDRESS` will have code and a nonce of 1, and will be exempt from EIP-158 cleanup.
+The bytecode above will be deployed à la [EIP-4788](./eip-4788.md). As such the account at `HISTORY_STORAGE_ADDRESS` will have code and a nonce of 1, and will be exempt from EIP-158 cleanup.
 
 ### Gas costs
 
-The gas cost of the `BLOCKHASH` opcode is unchanged. Importantly the processing at the beginning of the block, i.e. `process_block_hash_history`, will not warm the `HISTORY_STORAGE_ADDRESS` account or its storage slots as per [EIP-2929](./eip-2929.md) rules. As such the first call to the contract will pay for warming up the account and storage slots it accesses.
+The system update at the beginning of the block, i.e. `process_block_hash_history` (or via system call to the contract with `SYSTEM_ADDRESS` caller), will not warm the `HISTORY_STORAGE_ADDRESS` account or its storage slots as per [EIP-2929](./eip-2929.md) rules. As such the first call to the contract will pay for warming up the account and storage slots it accesses.To clarify further any contract call to the `HISTORY_STORAGE_ADDRESS` will follow normal EVM execution semantics.
+
+Since `BLOCKHASH` semantics doesn't change, this EIP has no impact on `BLOCKHASH` mechanism and costs.
 
 ## Rationale