update

EIPS/eip-2935.md

@@ -29,7 +29,8 @@ Additional secondary motivations include:
 | - | - |
 | `FORK_TIMESTAMP` | TBD |
 | `HISTORY_STORAGE_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe`|
-| `HISTORY_SERVE_WINDOW` | `256` |
+| `MIN_HISTORY_SERVE_WINDOW` | `256` |
+| `MAX_HISTORY_SERVE_WINDOW` | `2**256` |
 
 At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the history in the following way:
 
@@ -41,7 +42,7 @@ def process_block_hash_history(block :Block, state: State):
     # If this is the first fork block, add the parent's direct 255 ancestors as well
     if block.parent.timestamp < FORK_TIMESTAMP:
         ancestor = block.parent
-        for i in range(HISTORY_SERVE_WINDOW - 1):
+        for i in range(MIN_HISTORY_SERVE_WINDOW - 1):
             # stop at genesis block
             if ancestor.number == 0:
                 break
@@ -50,26 +51,27 @@ def process_block_hash_history(block :Block, state: State):
             state.insert_slot(HISTORY_STORAGE_ADDRESS, ancestor.number, ancestor.hash)
 ```
 
-Note that if this is the fork block, then it persists the additional requisite history that could be needed while resolving `BLOCKHASH` opcode for all of the `HISTORY_SERVE_WINDOW` ancestors (up until genesis).
+Note that if this is the fork block, then it persists the additional requisite history that could be needed while resolving `BLOCKHASH` opcode for all of the `MIN_HISTORY_SERVE_WINDOW` ancestors (up until genesis).
 
 For resolving the `BLOCKHASH` opcode this fork onwards (`block.timestamp >= FORK_TIMESTAMP`), switch the logic to:
 
 ```python
 def resolve_blockhash(block: Block, state: State, arg: uint64):
   # check the wrap around range
-  if arg >= block.number or arg < max(block.number - 2**256, 0)
+  if arg >= block.number or arg < max(block.number - MAX_HISTORY_SERVE_WINDOW, 0)
     return 0
 
   return state.load_slot(HISTORY_STORAGE_ADDRESS, arg)
 ```
 
-Note that the above logic allows access deeper than `HISTORY_SERVE_WINDOW` if it exists.
+Note that the above logic allows access deeper than `MIN_HISTORY_SERVE_WINDOW` if it exists all the way upto `MAX_HISTORY_SERVE_WINDOW`.
 
 Edge cases:
 
  * For the fork to be activated at genesis, no history is written to the genesis state, and at the start of block `1`, genesis hash will be written as a normal operation to slot `0`.
  * for activation at block `1`, only genesis hash will be written at slot `0` as there is no additional history that needs to be persisted.
  * for activation at block `32`, block `31`'s hash will be written to slot `31` and additonal history for `0..30`'s hashes will be persisted, so all in all `0..31`'s hashes.
+ * for activation at block `1000`, block `744-999`'s hashes will be presisted in the slot and `BLOCKHASH` for `733` or less would resolve to `0` as only `MIN_HISTORY_SERVE_WINDOW` is persisted.
 
 ### [EIP-158](./eip-158.md) exception
 
@@ -89,11 +91,11 @@ Very similar ideas were proposed before in [EIP-210](./eip-210.md) et al. This E
 
 The former was intended to save space. Since then, however, storage usage has increased massively, to the point where even eg. 5 million new storage slots are fairly negligible compared to existing usage. The latter was intended as a first step toward "writing the Ethereum protocol in EVM" as much as possible, but this goal has since been de-facto abandoned.
 
-Storing of all last `HISTORY_SERVE_WINDOW` block hashes alleviates the need to detect fork activation height to transition to the new logic as the entire required history will be available from the first block of the fork itself. The cost of doing so is marginal considering the `HISTORY_SERVE_WINDOW` being small.
+Storing of all last `MIN_HISTORY_SERVE_WINDOW` block hashes alleviates the need to detect fork activation height to transition to the new logic in backward compatible manner as the entire requisite history will be available from the first block of the fork itself. The cost of doing so is marginal considering the `MIN_HISTORY_SERVE_WINDOW` being small.
 
 ## Backwards Compatibility
 
-The range of `BLOCKHASH` is increased by this opcode, but behavior within the previous 256-block range remains unchanged.
+The range of `BLOCKHASH` is increased by this opcode, but behavior within the previous `MIN_HISTORY_SERVE_WINDOW`-block range remains unchanged.
 
 ## Test Cases