Update EIP-2935: Move to Draft

EIPS/eip-2935.md

@@ -1,62 +1,218 @@
 ---
 eip: 2935
-title: Save historical block hashes in state
-author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak)
+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: Stagnant
+status: Draft
 type: Standards Track
 category: Core
 created: 2020-09-03
 ---
 
-## Simple Summary
+## Abstract
 
-Store historical block hashes in a contract, and modify the `BLOCKHASH (0x40)` opcode to read this contract.
+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
 
-There is increasingly a desire to remove the need for most clients to store history older than some relatively short duration (often between 1 week and 1 year) to save disk space. This requires some form of layer-2 network to help clients access historical information. These protocols can be made much simpler if blocks contained a quick Merkle path to historical blocks.
+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.
 
-Additional secondary motivations include:
+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.
 
-* The protocol can be used to make more secure efficient light clients with flyclient-like technology (while the "optimal" flyclient protocol is fairly complex, large security gains over the status quo (trusted "canonical hash trees") can be made cheaply)
-* Improving cleanness of the protocol, as the BLOCKHASH opcode would then access state and not history.
+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_BLKNUM` | TBD |
-| `HISTORY_STORAGE_ADDRESS` | `0xfffffffffffffffffffffffffffffffffffffffe`|
-
-At the start of processing any block where `block.number > FORK_BLKNUM` (ie. before processing any transactions), run `sstore(HISTORY_STORAGE_ADDRESS, block.number - 1, block.prevhash)`.
-
-When `block.number > FORK_BLKNUM + 256`, change the logic of the `BLOCKHASH` opcode as follows: if `FORK_BLKNUM <= arg < block.number`, return `sload(HISTORY_STORAGE_ADDRESS, arg)`. Otherwise return 0.
+| `FORK_TIMESTAMP` | TBD |
+| `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.
+
+
+At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the history 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)
+
+    # 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):
+            # stop at genesis block
+            if ancestor.number == 0:
+                break
+
+            ancestor = ancestor.parent
+            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` > `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 + 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 `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
+
+This address is currently exempt from [EIP-158](./eip-158.md) cleanup in Kaustinen Verkle Testnet but we plan to address this in the following way:
+
+* Deploy a contract à la [EIP-4788](./eip-4788.md) which just supports `get` method to resolve the BLOCKHASH as per the logic defined in `resolve_blockhash` (and use the generated address as the BLOCKHASH contract address).
+* While the clients are expected to directly read from state (or maintain and serve from memory) to resolve BLOCKHASH opcode, this contract's `get` could be invoked by transaction (via another contract or directly) leading to a normal contract execution (and gas consumption) as per the semantics of the contract call.
+
+
+### Gas costs and witnesses
+
+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
 
-Very similar ideas were proposed before in EIP-98 and EIP-210. This EIP is a simplification, removing two sources of needless complexity:
+Very similar ideas were proposed before in [EIP-210](./eip-210.md) et al. This EIP is a simplification, removing two sources of needless complexity:
 
 1. Having a tree-like structure with multiple layers as opposed to a single list
 2. Writing the EIP in EVM code
+3. Serial unbounded storage of hashes for a deep access to the history
+
+However after weighing pros and cons, we decided to go with just a limited ring buffer to only serve the requisite `HISTORY_SERVE_WINDOW` as [EIP-4788](./eip-4788.md) and beacon state accumulators allow (albeit a bit more complex) proof against any ancestor since merge.
 
-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.
+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.
+
+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 range of `BLOCKHASH` is increased by this opcode, but behavior within the previous 256-block range remains unchanged.
+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
 
 TBD
 
-## Implementation
+## Reference Implementation
 
-TBD
+ * PR 28878 of go-ethereum
+ * Active on verkle-gen-devnet-5 for its verkle implementation
 
 ## Security Considerations
 
-Adding ~2.5 million storage slots per year bloats the state somewhat (but not much relative to the hundreds of millions of existing state objects). However, this EIP is not intended to be permanent; when eth1 is merged into eth2, the BLOCKHASH opcode would likely be repurposed to use eth2's built-in history accumulator structure (see [phase 0 spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#slots_per_historical_root)).
+Having contracts (system or otherwise) with hot update paths (branches) poses a risk of "branch" poisioning attacks where attacker could sprinkle trivial amounts of eth around these hot paths (branches). But it has been deemed that cost of attack would escalate significantly to cause any meaningful slow down of state root updates.
 
 ## Copyright