From 117933b21665ca7c0d040835a9d19b4a02392f47 Mon Sep 17 00:00:00 2001 From: Sina M <1591639+s1na@users.noreply.github.com> Date: Wed, 21 Aug 2024 18:01:38 +0200 Subject: [PATCH] Update EIP-2935: update mechanism via system call Merged by EIP-Bot. --- EIPS/eip-2935.md | 62 +++++++++++++++++++++++++++++++++++++----------- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-2935.md b/EIPS/eip-2935.md index 5035932804728..a04da454a5a6b 100644 --- a/EIPS/eip-2935.md +++ b/EIPS/eip-2935.md @@ -2,7 +2,7 @@ eip: 2935 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) +author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer), Sina Mahmoodi (@s1na) discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565 status: Review type: Standards Track @@ -34,21 +34,42 @@ A side benefit of this approach could be that it allows building/validating proo This EIP specifies for storing last `HISTORY_SERVE_WINDOW` block hashes in a ring buffer storage of `HISTORY_SERVE_WINDOW` length. Note that `HISTORY_SERVE_WINDOW` > `BLOCKHASH_SERVE_WINDOW` (which remains unchanged). -At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), update the state directly in the following way: +### Block processing -```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) -``` +At the start of processing any block where `block.timestamp >= FORK_TIMESTAMP` (ie. before processing any transactions), call to `HISTORY_STORAGE_ADDRESS` as `SYSTEM_ADDRESS` with the 32-byte input of `block.parent.hash`, a gas limit of `30_000_000`, and `0` value. This will trigger the `set()` routine of the history contract. This is a system operation following the same convention as [EIP-4788](./eip-4788.md) and therefore: + +* the call must execute to completion +* the call does not count against the block's gas limit +* the call does not follow the [EIP-1559](./eip-1559.md) burn semantics - no value should be transferred as part of the call +* if no code exists at `HISTORY_STORAGE_ADDRESS`, the call must fail silently -Alternatively clients can also choose to do a system update via a system call to the contract `set` mechanism defined in the following sections. +Note: Alternatively clients can choose to directly write to the storage of the contract but EVM calling the contract remains preferred. Refer to the rationale for more info. Note that, it will take `HISTORY_SERVE_WINDOW` blocks after `FORK_TIMESTAMP` to completely fill up the ring buffer. The contract will only contain the parent hash of the fork block and no hashes prior to that. -As mentioned earlier the `BLOCKHASH` opcode semantics remains the same as before. However the clients which want to leverage the history from state may do so making sure the query is within `BLOCKHASH_SERVE_WINDOW` and is available in the contract. -### Contract Implementation +### EVM Changes + +The `BLOCKHASH` opcode semantics remains the same as before. + +### Block hash history contract + +The history contract has two operations: `get` and `set`. The `set` operation is invoked only when the `caller` is equal to the `SYSTEM_ADDRESS` as per [EIP-4788](./eip-4788.md). Otherwise the `get` operation is performed. + +#### `get` + +It is used from the EVM for looking up block hashes. + +* Callers provide the block number they are querying in a big-endian encoding. +* If calldata is bigger than 2^64-1, revert. +* For any output outside the range of [block.number-`HISTORY_SERVE_WINDOW`, block.number-1] return 0. + +#### `set` + +* Caller provides `block.parent.hash` as calldata to the contract. +* Set the storage value at `block.number-1 % HISTORY_SERVE_WINDOW` to be `calldata[0:32]`. + +#### Bytecode Exact evm assembly that can be used for the history contract: @@ -136,10 +157,6 @@ stop Corresponding bytecode: `0x3373fffffffffffffffffffffffffffffffffffffffe1460575767ffffffffffffffff5f3511605357600143035f3511604b575f35612000014311604b57611fff5f3516545f5260205ff35b5f5f5260205ff35b5f5ffd5b5f35611fff60014303165500` -#### Contract `get` and `set` mechanism - -The update mechanism is the same as [EIP-4788](./eip-4788.md). While executing the system contract is not future-proof, this update method remains the favored one until the verkle fork. - #### Deployment A special synthetic address is generated by working backwards from the desired deployment transaction: @@ -200,6 +217,23 @@ Second concern was how to best transition the BLOCKHASH resolution logic post fo We choose to go with the former. It simplifies the logic greatly. It will take roughly a day to bootstrap the contract. Given that this is a new way of accessing history and no contract depends on it, it is deemed a favorable tradeoff. +### Inserting the parent block hash + +Clients have generally two options for inserting the parent block hash into state: + +1. Performing a system call to `HISTORY_STORAGE_ADDRESS` and letting that handle the storing in state. +2. Avoid EVM processing and directly write to the state trie. + +The latter option is as follows: + +```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) +``` + +The first option is recommended until the Verkle fork, to stay consistent with [EIP-4788](./eip-4788.md) and to issues for misconfigured networks where this EIP is activated but history contract hasn't been deployed. The recommendation may be reconsidered at the Verkle fork if filtering the system contract code chunks is deemed too complex. + ## Backwards Compatibility This EIP introduces backwards incompatible changes to the block validation rule set. But neither of these changes break anything related to current user activity and experience.