Herodotus Docs
Home
  • Introduction
  • FAQ
  • developers
    • Storage Proofs
      • Workflow
      • Workflow Examples
      • Accessing Block Hash
    • Storage Proof API
      • Interactive Docs
      • Step by step example
    • Turbo
      • Supported Networks
      • Turbo zksync demo
    • Data Processor
      • Why use HDP?
      • Getting Started
      • HDP Jargon
        • What is a Data Lake?
        • What is a Module?
        • Cairo1/Cairo0 Interoperability
      • Architecture
      • Additional Resources
    • Data Processor API
      • Program Registry API
      • Interactive Docs
    • Data Structure Indexer API
      • Interactive Docs
    • Supported Networks
    • Contract Addresses
    • API Status
  • Scaling Solutions
    • Integrity Verifier
  • Protocol Design
    • Architecture
      • Smart Contracts
      • OP Stack
    • Historical Block Hash Accumulator
      • Merkle Mountain Ranges
      • Initial Accumulation Event
    • Timestamp to Block Mapper
      • Edge Cases
  • Security
    • Audits
  • GitHub
  • Twitter
  • LinkedIn
  • Telegram
  • Media Kit
Powered by GitBook
On this page
  1. Protocol Design

Historical Block Hash Accumulator

PreviousOP StackNextMerkle Mountain Ranges

Last updated 7 months ago

Using ZK-STARKs and Cairo, we developed a system where we provably traverse the Ethereum blockchain by checking the cryptographic linkage between block headers. Essentially, we are proving that the parent hash of the latest block is actually the previous block's hash. We do this process several million times until we reach the genesis block.

While traversing the block headers, we build two Merkle Mountain Range(MMR) accumulators, one with the Keccak256 hash and one with the Poseidon hash containing only the provably valid Ethereum block hashes.

Conducting this traversal process every single time a historical block hash is needed would be immensely computationally and financially expensive. This is precisely why we employ accumulators. Using MMR accumulators ensures that we undertake this process only once. Thanks to the append-friendly nature of MMRs, we can easily expand the range of blocks covered by the accumulator in the future.

We opt for two accumulators to guarantee compatibility with a broad spectrum of Ethereum rollups and reduce expenses on our supported blockchains. For example, the Keccack256 version of the MMR will be used on Ethereum and many of its EVM-based rollups, while the Poseidon version of the MMR will be used on Starknet and other zk-rollups.

Reading arbitrary historical block hashes will become possible by verifying an inclusion proof against the Keccack256 or Poseidon root of the MMR.

This is a crucial development for storage proofs since they can be verified against historical block hashes present within the accumulator!

The Herodotus Historical Block Hash Accumulators essentially enable without any protocol-level changes.

EIP-2935