Storage Proofs
HomeDashboard
  • Getting Started
    • Introduction
    • Use Cases
    • Quick Start Guide
    • Key Concepts
  • Storage Proofs
    • Overview
    • Workflow
      • Workflow Examples
    • Accessing Block Hash
  • Solutions
    • Storage Proof API
      • Authentication
      • Payload Examples
    • Turbo
      • Workflow
      • RPC Endpoint
      • Turbo Compute
  • Architecture
    • Overview
    • Smart Contracts
    • Cross-Chain Storage Proofs
      • Native Messaging Systems
      • OP Stack Chains
  • Guides
    • Using Storage Proof API
    • Integrating Storage Proofs
    • Building a Storage Proof Powered Bridge
    • Writing Turbo Smart Contracts
    • Sending Turbo Transactions
  • References
    • Contract Addresses
    • Supported Networks
    • Glossary
  • Media Links
    • Twitter
    • Telegram
Powered by GitBook
On this page
  1. Storage Proofs

Accessing Block Hash

PreviousWorkflow ExamplesNextStorage Proof API

Last updated 10 months ago

Block hashes are cryptographic fingerprints of a block's content, encapsulating the entirety of a block's information, primarily its header. In the context of storage proofs, accessing the relevant block hash is the critical first step in affirming the integrity and authenticity of any on-chain data. It lays the foundation for all subsequent verification processes in the storage proof workflow.

Smart contracts can retrieve these block hashes through various methods, each with its own trade-offs and considerations. Let's explore these approaches in detail:

Direct Access using EVM opcode

Ethereum Yellow Paper ()

Smart contracts can natively utilize the BLOCKHASH opcode to fetch hashes of the most recent 256 blocks in the Ethereum Virtual Machine (EVM). While straightforward, this method is restricted to a limited timeframe, and accessing older blocks becomes challenging.

This limitation prevents developers from injecting proofs of arbitrary on-chain data into their smart contracts, as they cannot easily verify inclusion proofs against historical block hashes.

Utilizing Third-Party Providers

Alternately, an off-chain actor could forward block hashes on-chain. However, this approach introduces latency and usually requires trusting a third party, a committee or similar. Additionally, it potentially introduces vulnerabilities tied to economic incentives or adversarial behaviours.

The Historical Block Hash Accumulator can be used to circumvent these issues. It enables on-chain smart contracts to derive older block hashes by validating them against a stored accumulator root (MMR Root). The methodology eliminates the need to trust external actors and widens the accessible range of block hashes without sacrificing security.

This approach uses a Merkle Mountain Range (MMR) data structure where block hashes are continuously added, and the MMR root is periodically committed on-chain. Smart contracts can then verify any historical block hash against this root, maintaining the trustless nature of blockchain interactions while providing efficient access to historical data.

Root of Merkle Mountain Range Accumulator
Historical Block Hash Accumulator
https://ethereum.github.io/yellowpaper/paper.pdf