Cross-Chain Storage Proofs

Storage Proofs allow smart contracts on one blockchain to securely access and verify data from another blockchain. This cross-chain functionality is crucial for building interoperable decentralized applications. Let's explore how this process works and the role of key smart contracts involved.

The Basic Flow

1. Data Request: A smart contract on Chain B (e.g., Starknet) needs to verify data from Chain A (e.g., Ethereum).

2. Proof Generation: Off-chain systems generate cryptographic proofs of the requested data from Chain A.

3. Proof Submission: These proofs are submitted to Chain B.

4. Verification: Smart contracts on Chain B verify the proofs and make the data available for use.

Key Smart Contracts

Several smart contracts work together to make this process secure and efficient:

CommitmentsInbox (on Chain B)

• Purpose: Receives and processes data from Chain A.

• Function:

  1. Accepts block headers and other critical data from Chain A.

  2. Verifies the authenticity of this data using cryptographic signatures.

  3. Stores the verified data for further use.

HeadersStore (on Chain B)

• Purpose: Efficiently stores and manages a large number of block headers from Chain A.

• Function:

  1. Uses a data structure called a Merkle Mountain Range (MMR) to store block headers.

  2. Allows for efficient verification of historical block headers.

FactsRegistry (on Chain B)

• Purpose: Stores and manages verified blockchain data from Chain A.

• Function:

  1. Stores proven account balances, storage values, and other blockchain data.

  2. Provides functions for other smart contracts to access this verified data.

L1MessagesProxy (on Chain A)

• Purpose: Facilitates sending messages from Chain B back to Chain A.

• Function:

  1. Aggregates messages from Chain B.

  2. Sends these messages to Chain A in a gas-efficient manner.

The Cross-Chain Proof Process

1. Initiation: A smart contract on Chain B requests data from Chain A.

2. Data Transmission:

   • The L1MessagesProxy on Chain A collects relevant block headers and data.

   • This information is sent to the CommitmentsInbox on Chain B.

3. Data Processing:

   • The CommitmentsInbox verifies the incoming data.

   • Verified block headers are stored in the HeadersStore.

4. Proof Generation and Verification:

   • Off-chain systems generate cryptographic proofs of the requested data.

   • These proofs are submitted to Chain B.

   • The FactsRegistry verifies these proofs against the data in the HeadersStore.

5. Data Availability:

   • Once verified, the data is stored in the FactsRegistry.

   • Smart contracts on Chain B can now access and use this verified data from Chain A.

Security and Efficiency

This system ensures security through cryptographic verification at each step. It's also designed for efficiency:

• Only essential data (like block headers) is regularly transmitted between chains.

• Complex proofs are generated off-chain to minimize on-chain computation.

• Data structures like the Merkle Mountain Range allow for efficient storage and verification of large amounts of historical data.

By using this system of smart contracts and cryptographic proofs, Herodotus enables secure and efficient cross-chain data access, opening up new possibilities for blockchain interoperability.