Add EIP: Read BLOCKHASH from storage and update cost

EIPS/eip-7709.md

@@ -0,0 +1,138 @@
+---
+eip: 7709
+title: Read BLOCKHASH from storage and update cost
+description: Read the `BLOCKHASH (0x40)` opcode from the EIP-2935 system contract storage and adjust its gas cost to reflect storage access.
+author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer), Gabriel Rocheleau (@gabrocheleau)
+discussions-to: https://ethereum-magicians.org/t/eip-7709-read-blockhash-opcode-from-storage-and-adjust-gas-cost/20052
+status: Draft
+type: Standards Track
+category: Core
+created: 2024-05-18
+requires: 2935, 6800
+---
+
+## Abstract
+
+Update the `BLOCKHASH (0x40)` opcode to read and serve from the system contract storage to allow for stateless execution. Update the `BLOCKHASH (0x40)` opcode gas cost to reflect storage access cost, and include storage accesses in the Verkle block witness.
+
+## Motivation
+
+The `BLOCKHASH (0x40)` opcode currently assumes that the client has knowledge of the previous blocks, which in Verkle, would prevent stateless execution. This EIP assumes that [EIP-2935](./eip-2935.md) has been implemented, and that blockhashes can be retrieved from the systems contract storage. By updating the behavior of `BLOCKHASH (0x40)` to directly read and serve from state through the system contract storage, we allow Verkle blocks to include a storage access witness, which will allow stateless execution.
+
+The motivation behind the updated gas cost is to match the real cost of the operation, which is equivalent to an `SLOAD`.
+
+## Specification
+
+| Parameter                 | Value                                        |
+| ------------------------- | -------------------------------------------- |
+| `FORK_TIMESTAMP`          | TBD                                          |
+| `HISTORY_STORAGE_ADDRESS` | `0x25a219378dad9b3503c8268c9ca836a52427a4fb` |
+| `BLOCKHASH_SERVE_WINDOW`  | `256`                                        |
+| `HISTORY_SERVE_WINDOW`    | `8192`                                       |
+
+The `BLOCKHASH` opcode semantics remains the same as before. From the `fork_block` (first block where `block.timestamp >= FORK_TIMESTAMP`), the `BLOCKHASH` instruction should be updated to retrieve the requested blockhash from the contract storage.
+
+### Contract Implementation
+
+Exact evm assembly that can be used for the contract to resolve `BLOCKHASH`
+
+```
+// check if input > 8 byte value and revert if this isn't the case
+// the check is performed by comparing the biggest 8 byte number with
+// the call data, which is a right-padded 32 byte number.
+push8 0xffffffffffffffff
+push0
+calldataload
+gt
+push1 0x39
+jumpi
+
+// check if input > blocknumber-1 then return 0
+push1 0x1
+number
+sub
+push0
+calldataload
+gt
+push1 0x31
+jumpi
+
+// check if blocknumber > input + 8192 then return 0, no overflow expected for input of 8 bytes
+push0
+calldataload
+push2 0x2000
+add
+number
+gt
+push1 0x31
+jumpi
+
+// mod 8192 and sload
+push2 0x1FFF
+push0
+calldataload
+and
+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
+```
+
+Note that the input contract read `32` bytes input as `calldataload`. Users and clients doing EVM call to this contract should left pad the `arg` correctly.
+
+<!-- TODO: bytecode is based off on first version and will be updated once assembly is locked down as it changes contract sender and address -->
+
+Corresponding bytecode:
+`60203611603157600143035f35116029575f356120000143116029576120005f3506545f5260205ff35b5f5f5260205ff35b5f5ffd00`
+
+#### Deployment
+
+For the fork_block (blocks where `block.timestamp >= FORK_TIMESTAMP`), we consider that the fork (`FORK_TIMESTAMP`) is already in effect for at least `HISTORY_SERVE_WINDOW` blocks (or from genesis if `fork_block < HISTORY_SERVE_WINDOW`). The following changes take effect:
+
+- `BLOCKHASH` SHOULD retrieve blockhashes from the system contract storage and MUST provide the storage access in the Verkle execution witness
+- The gas cost of the `BLOCKHASH` opcode is updated as per specification
+
+### [EIP-158](./eip-158.md) handling
+
+### Gas costs
+
+At FORK_TIMESTAMP, the corresponding storage access witness for the blockhash `SLOAD` lookups must also included in the execution witness, along with their access gas charges.
+
+## Rationale
+
+## Backwards Compatibility
+
+This EIP introduces a significant increase in the cost of `BLOCKHASH`, which could break use-cases that rely on the previous gas cost.
+
+## Test Cases
+
+TBD
+
+## Security Considerations
+
+Having contracts (system or otherwise) with hot update paths (branches) poses a risk of "branch" poisoning 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
+
+Copyright and related rights waived via [CC0](../LICENSE.md).