Go to Home
Web3 security pattern.
Pectra Competition
Web3 security pattern.
EIP-2935
EIP-2935 introduces a system contract for retrieving recent block hashes, enhancing Ethereum’s stateless client capabilities.EIP-2935 stores the last 8,191 block hashes in a system contract, improving stateless client support and enabling efficient state proofs.

EIP-2935

Table of Contents

Heading 2
Heading 3
Heading 4

What is this EIP about?

EIP-2935 proposes a system for storing the last 8,191 historical block hashes in the state of Ethereum as part of a system contract. Its purpose is to enhance stateless client support by enabling the retrieval of these historical hashes through a contract, facilitating more efficient state proofs and interactions.

Why is this EIP needed?

Currently, Ethereum relies on clients to maintain access to recent block hashes. This approach is not future-proof, especially with the adoption of stateless clients, which aim to minimize the storage and computational burden on nodes. This proposal addresses the limitation by embedding block hashes directly in the state, improving accessibility and enabling features like extended proof validation and rollup interaction.

  • Domain: Blockchain infrastructure, stateless client optimization, and smart contract interaction.
  • Problem: Stateless clients cannot rely on persistent local storage for block history, making efficient proof generation and verification challenging.
  • Opportunity: By integrating historical block hashes into the Ethereum state, this proposal supports the transition to a stateless architecture and simplifies interaction with historical data.

What does this EIP propose, and how does it function?

Key Technical Details:

  1. Storage Mechanism:
    • A ring buffer of size HISTORY_SERVE_WINDOW = 8,191 stores historical block hashes.
    • The buffer is maintained as part of a system contract at HISTORY_STORAGE_ADDRESS.
  2. Contract Operations:
    • Set: On block processing, the block.parent.hash is written into the contract storage.
    • Get: Queries retrieve block hashes for a specific block number within the last 8,191 blocks.
  3. EVM and Block Processing Changes:
    • The BLOCKHASH opcode remains unchanged for recent blocks.
    • For historical queries, a system contract is called for retrieving the hashes.
  4. Gas and System Integration:
    • Updates to the history contract are system-level operations, excluded from normal gas limits or block gas calculations.
    • A bootstrap period of 8,191 blocks after activation is required to populate the buffer.
Ethereum block hashes are processed, stored in a ring buffer, and accessed via a system contract for historical retrieval.

What are the security implications of this EIP?

  1. Potential Risks:
    • Branch Poisoning Attacks: Attackers could attempt to manipulate the storage by sprinkling small amounts of ETH into "hot" paths. However, the cost of such attacks is prohibitive.
    • System Contract Vulnerabilities: Bugs in the history contract's implementation could impact its reliability.
  2. Mitigation Measures:
    • Ensuring strict validation and testing of the history contract.
    • The contract operates on a well-defined, limited scope, reducing complexity and risk.
    • The proposed size and structure of the ring buffer mitigate issues related to overwriting or saturation.

By addressing the current limitations and enabling stateless execution, EIP-2935 represents a significant step toward making Ethereum more scalable and efficient for future use cases.