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

EIPS/eip-2935.md

@@ -1,8 +1,8 @@
 ---
 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
-author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria)
+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), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer)
 discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565
 status: Draft
 type: Standards Track
@@ -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 `HISTORY_SERVE_WINDOW` 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 `HISTORY_SERVE_WINDOW` 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_OLD_WINDOW` | `256` |
 
 This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length.
 
@@ -40,7 +41,7 @@ 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 `HISTORY_SERVE_WINDOW - 1` ancestors as well
     if block.parent.timestamp < FORK_TIMESTAMP:
         ancestor = block.parent
         for i in range(HISTORY_SERVE_WINDOW - 1):
@@ -52,25 +53,94 @@ 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 `HISTORY_SERVE_WINDOW` > `BLOCKHASH_OLD_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 - HISTORY_SERVE_WINDOW, 0)
+  if arg >= block.number or (arg + HISTORY_SERVE_WINDOW) < block.number
     return 0
 
   return state.load_slot(HISTORY_STORAGE_ADDRESS, arg % HISTORY_SERVE_WINDOW)
 ```
 
+Exact evm assembly that can be used for the blockhash contract:
+
+```
+// check for <=32 (<33) byte size or else revert
+calldatasize
+push1 0x21
+gt
+push1 0x0a
+// jump and skip revert
+jumpi
+
+push0
+push0
+revert
+
+// check if  blocknumber > input or else return 0
+jumpdest
+push0
+calldataload
+number
+gt
+push1 0x1a
+jumpi
+
+// return 0
+push0
+push0
+mstore
+push1 0x20
+push0
+return
+
+// check if input + 8125 > blocknumber (input >= blocknumber - 8124) or else return 0
+jumpdest
+number
+push2 0x2001
+push0
+calldataload
+add
+gt
+push1 0x2e
+jumpi
+
+// return 0
+push0
+push0
+mstore
+push1 0x2e
+push0
+return
+
+// mod 8192 and sload
+jumpdest
+push2 0x2000
+push0
+calldataload
+mod
+sload
+
+// load into mem and return 32 bytes
+push0
+mstore
+push1 0x20
+push0
+return
+
+stop
+```
+
 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 `10000`, block `1808-9999`'s hashes will be presisted in the slot and `BLOCKHASH` for `1807` or less would resolve to `0` as only `HISTORY_SERVE_WINDOW` are persisted.
 
 ### [EIP-158](./eip-158.md) handling
 
@@ -82,7 +152,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 corresponding accesses (and gas charges) of `SLOAD`.
 
 ## Rationale
 
@@ -99,11 +169,12 @@ Second concern was how to best transition the BLOCKHASH resolution logic post fo
 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.
 
-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 `HISTORY_SERVE_WINDOW` being relatively limited. Most clients write this into their flat db/memory caches and just requires reading last `HISTORY_SERVE_WINDOW` from the chain history.
 
 ## 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 upto `HISTORY_SERVE_WINDOW` on the fork block. However the gas charges will also get bumped as per the additional `SLOAD` costs.
 
 ## Test Cases