64 lines
3.1 KiB
Markdown
64 lines
3.1 KiB
Markdown
---
|
|
eip: 2935
|
|
title: Save historical block hashes in state
|
|
author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak)
|
|
discussions-to: https://ethereum-magicians.org/t/eip-2935-save-historical-block-hashes-in-state/4565
|
|
status: Stagnant
|
|
type: Standards Track
|
|
category: Core
|
|
created: 2020-09-03
|
|
---
|
|
|
|
## Simple Summary
|
|
|
|
Store historical block hashes in a contract, and modify the `BLOCKHASH (0x40)` opcode to read this contract.
|
|
|
|
## 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.
|
|
|
|
Additional secondary motivations include:
|
|
|
|
* 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.
|
|
|
|
## 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.
|
|
|
|
## Rationale
|
|
|
|
Very similar ideas were proposed before in EIP-98 and EIP-210. 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
|
|
|
|
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.
|
|
|
|
## Backwards Compatibility
|
|
|
|
The range of `BLOCKHASH` is increased by this opcode, but behavior within the previous 256-block range remains unchanged.
|
|
|
|
## Test Cases
|
|
|
|
TBD
|
|
|
|
## Implementation
|
|
|
|
TBD
|
|
|
|
## 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)).
|
|
|
|
## Copyright
|
|
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|