EIP-2935: Serve historical block hashes from state

Store and serve last 8192 block hashes as storage slots of a system contract to allow for stateless execution

Abstract

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.

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 HISTORY_SERVE_WINDOW ancestors directly against the current state.

Specification

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:

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:

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 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

Corresponding bytecode: 60203611603157600143035f35116029575f356120000143116029576120005f3506545f5260205ff35b5f5f5260205ff35b5f5ffd00

Deployment

A special synthetic address is generated by working backwards from the desired deployment transaction:

{
  "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 handling

This address is currently exempt from EIP-158 cleanup in Kaustinen Verkle Testnet but we plan to address this in the following way:

• Deploy a contract à la EIP-4788 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-210 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 and beacon state accumulators allow (albeit a bit more complex) proof against any ancestor since merge.

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 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

Reference Implementation

• PR 28878 of go-ethereum
• Active on verkle-gen-devnet-5 for its verkle implementation

Security Considerations

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

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer), "EIP-2935: Serve historical block hashes from state [DRAFT]," Ethereum Improvement Proposals, no. 2935, September 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2935.