extend history retention to 8192 and modify blockhash to charge addit…

…ional sload gas (#4) * extend history retention to 8192 and modify blockhash to charge additional sload gas * title * fix cleanup * add missing contributor names Co-authored-by: Ignacio Hagopian <[email protected]> * further update on discussion * update * update * update * add contract assembley * apply feedback * add helpful comments * fix the comment vals * update the assembely as per feedback * improv * add and generate deployment tx, inputdata and sender/contract address --------- Co-authored-by: Guillaume Ballet <[email protected]> Co-authored-by: Ignacio Hagopian <[email protected]>
ethereum · Apr 12, 2024 · 2b73ecb · 2b73ecb
1 parent 8e3730f
commit 2b73ecb
Showing 1 changed file with 112 additions and 16 deletions.
diff --git a/EIPS/eip-2935.md b/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_STORAGE_ADDRESS` | `0x25a219378dad9b3503c8268c9ca836a52427a4fb`|
+| `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,119 @@ 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)
 ```
 
+### Contract Implementation
+
+Exact evm assembly that can be used for the contract to resolve `BLOCKHASH`
+
+```
+// check if inputsize>32 revert
+push1 0x20
+calldatasize
+gt
+push1 0x31
+jumpi
+
+// check if input > blocknumber-1 then return 0
+push1 0x1
+number
+sub
+push0
+calldataload
+gt
+push1 0x29
+jumpi
+
+// check if blocknumber > input + 8192 then return 0
+push0
+calldataload
+push2 0x2000
+add
+number
+gt
+push1 0x29
+jumpi
+
+// mod 8192 and sload
+push2 0x2000
+push0
+calldataload
+mod
+sload
+
+// load into mem and return 32 bytes
+push0
+mstore
+push1 0x20
+push0
+return
+
+// return 0
+jumpdest
+push0
+push0
+mstore
+push1 0x20
+push0
+return
+
+// revert
+jumpdest
+push0
+push0
+revert
+
+stop
+```
+
+Corresponding bytecode:
+`60203611603157600143035f35116029575f356120000143116029576120005f3506545f5260205ff35b5f5f5260205ff35b5f5ffd00`
+
+#### Deployment
+
+A special synthetic address is generated by working backwards from the desired deployment transaction:
+
+```json
+{
+  "type": "0x0",
+  "nonce": "0x0",
+  "to": null,
+  "gas": "0x3d090",
+  "gasPrice": "0xe8d4a51000",
+  "maxPriorityFeePerGas": null,
+  "maxFeePerGas": null,
+  "value": "0x0",
+  "input": "0x60368060095f395ff360203611603157600143035f35116029575f356120000143116029576120005f3506545f5260205ff35b5f5f5260205ff35b5f5ffd00",
+  "v": "0x1b",
+  "r": "0x539",
+  "s": "0x1b9b6eb1f0",
+  "hash": "7ba81426bfa88a2cf4ea5c9abbbe83619505acd1173bc8450f93cf17cde3784b",
+}
+```
+
+Note, the input in the transaction has a simple constructor prefixing the desired runtime code.
+
+The sender of the transaction can be calculated as `0xa4690f0ed0d089faa1e0ad94c8f1b4a2fd4b0734`. The address of the first contract deployed from the account is `rlp([sender, 0])` which equals `0x25a219378dad9b3503c8268c9ca836a52427a4fb`. This is how `HISTORY_STORAGE_ADDRESS` is determined. Although this style of contract creation is not tied to any specific initcode like create2 is, the synthetic address is cryptographically bound to the input data of the transaction (e.g. the initcode).
+
+
 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 +177,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 +194,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