extend history retention to 8192 and modify blockhash to charge additional sload gas

EIPS/eip-2935.md

@@ -1,7 +1,7 @@
 ---
 eip: 2935
-title: Save historical block hashes in state
-description: store previous block hashes as storage slots of a system contract to allow for stateless execution
+title: Serve historical block hashes from state
+description: Store and serve last 8192 block hashes as storage slots of a system contract to allow for stateless execution
 author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria)
 discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565
 status: Draft
@@ -12,23 +12,24 @@ created: 2020-09-03
 
 ## Abstract
 
-Store last 256 historical block hashes in a contract, and modify the `BLOCKHASH (0x40)` opcode to read and serve from this contract storage.
+Store last `8192` historical block hashes in a contract, and modify the `BLOCKHASH (0x40)` opcode to read and serve from this contract storage.
 
 ## Motivation
 
-Currently BLOCKHASH opcode accesses history to resolve hash of the block number in EVM. However a more stateless client friendly way is to maintain and serve these hashes from state.
+Currently `BLOCKHASH` opcode accesses history to resolve hash of the block number in EVM. However a more stateless client friendly way is to maintain and serve these hashes from state.
 
-Although this is possible even in Merkle trie state, but Verkle trie state further allows bundling the BLOCKHASH witnesses (along with other witnesses) in an efficient manner making it worthwhile to have these in state.
+Although this is possible even in Merkle trie state, but Verkle trie state further allows bundling the `BLOCKHASH` witnesses (along with other witnesses) in an efficient manner making it worthwhile to have these in state.
 
-A side benefit of this approach could be that it allows building/validating proofs related to last 256 ancestors directly against the current state.
+A side benefit of this approach could be that it allows building/validating proofs related to last `8192` ancestors directly against the current state.
 
 ## Specification
 
 | Parameter | Value |
 | - | - |
 | `FORK_TIMESTAMP` | TBD |
 | `HISTORY_STORAGE_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe`|
-| `HISTORY_SERVE_WINDOW` | `256` |
+| `HISTORY_SERVE_WINDOW` | `8192` |
+| `BLOCKHASH_PERSIST_WINDOW` | `256` |
 
 This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length.
 
@@ -40,10 +41,10 @@ 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)
 
-    # If this is the first fork block, add the parent's direct 255 ancestors as well
+    # If this is the fork block, add the parent's direct `BLOCKHASH_PERSIST_WINDOW - 1` ancestors as well
     if block.parent.timestamp < FORK_TIMESTAMP:
         ancestor = block.parent
-        for i in range(HISTORY_SERVE_WINDOW - 1):
+        for i in range(BLOCKHASH_PERSIST_WINDOW - 1):
             # stop at genesis block
             if ancestor.number == 0:
                 break
@@ -52,7 +53,7 @@ def process_block_hash_history(block: Block, state: State):
             state.insert_slot(HISTORY_STORAGE_ADDRESS, ancestor.number % HISTORY_SERVE_WINDOW, 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 `BLOCKHASH_PERSIST_WINDOW` ancestors (up until genesis).
 
 For resolving the `BLOCKHASH` opcode this fork onwards (`block.timestamp >= FORK_TIMESTAMP`), switch the logic to:
 
@@ -70,7 +71,7 @@ Some activation scenarios:
  * 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 `743` or less would resolve to `0` as only `HISTORY_SERVE_WINDOW` can be served.
+ * for activation at block `1000`, block `744-999`'s hashes will be presisted in the slot and `BLOCKHASH` for `743` or less would resolve to `0` as only `BLOCKHASH_PERSIST_WINDOW` are persisted.
 
 ### [EIP-158](./eip-158.md) handling
 
@@ -82,7 +83,7 @@ This address is currently exempt from [EIP-158](./eip-158.md) cleanup in Kaustin
 
 ### Gas costs and witnesses
 
-We propose not to modify any gas costs since clients can directly resolve `BLOCKHASH` from an in-memory maintained structure or do a direct actual `SLOAD` or even a "system" execution of the deployed contract's `get`. However, for purposes of bundling block witnesses for stateless clients (for e.g. in Verkle activated networks), client should record corresponding witness accesses and bundle in the witnesses along with the corresponding proofs.
+Since now `BLOCKHASH` is served from state, the clients now **additionally** charge the corresponding warm or cold `SLOAD` costs. For verkle based networks this would imply doing and bundling similar accesses (and gas charges) to `SLOAD`.
 
 ## Rationale
 
@@ -96,14 +97,15 @@ However after weighing pros and cons, we decided to go with just a limited ring
 
 Second concern was how to best transition the BLOCKHASH resolution logic post fork by:
 
-1. Either waiting for  `HISTORY_SERVE_WINDOW` blocks for the entire relevant history to persist
-2. Storing of all last `HISTORY_SERVE_WINDOW` block hashes on the fork block.
+1. Either waiting for  `BLOCKHASH_PERSIST_WINDOW` blocks for the entire relevant history to persist
+2. Storing of all last `BLOCKHASH_PERSIST_WINDOW` block hashes on the fork block.
 
-We choose to go with later as it 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 `HISTORY_SERVE_WINDOW` being small.
+We choose to go with later as it alleviates the need to detect fork activation height to transition to the new logic in backward compatible manner as the entire `BLOCKHASH` requisite history will be available from the first block of the fork itself.
+The cost of doing so is marginal considering the `BLOCKHASH_PERSIST_WINDOW` being small and clients should already have it handy for resolving upto `BLOCKHASH_PERSIST_WINDOW` depth.
 
 ## Backwards Compatibility
 
-The behavior of `BLOCKHASH` opcode remains same and this EIP doesn't affect backward compatibility with the contracts deployed or the gas consumption costs as the resolution of the opcode is handled "directly" by the clients.
+The behavior of `BLOCKHASH` opcode gets extended in backward compatible manner as the history it can serve will get extended with each block post the fork upto `HISTORY_SERVE_WINDOW`. However the gas charges will get bumped as per the additional `SLOAD` costs.
 
 ## Test Cases