Storage Proof

A data availability proof cryptographically guarantees that all data for a block (like transaction data) is published and accessible to the network, even if a single node doesn't download it. This prevents malicious validators from hiding transaction data while producing a valid block header. Key techniques include erasure coding and data availability sampling (DAS), where light clients sample small random chunks to probabilistically verify the whole dataset is available.

A state proof verifies that a specific piece of information (e.g., an account balance or a smart contract storage slot) is part of a known, committed state. It typically uses a Merkle proof, where a prover provides the hashes along the path from the data leaf to the trusted Merkle root. This allows light clients or other chains to trustlessly verify state membership without running a full node.

A validity proof uses zero-knowledge cryptography (like zk-SNARKs or zk-STARKs) to prove the correct execution of a computation over some data. In storage contexts, this can prove that state transitions (e.g., processing a batch of transactions) were performed correctly according to the rules, based on the available data. This provides succinct verifiability, where verifying the proof is much faster than re-executing the computation.

Proof of Space demonstrates that a prover has allocated a specific amount of storage capacity. Proof of Replication proves that data is stored in a uniquely encoded, physically independent replica, preventing Sybil attacks where the same storage is claimed for multiple copies. These proofs are core to Filecoin-style decentralized storage networks, ensuring providers are physically storing the data they承诺 to store.

A proof of custody is a challenge-response protocol where a verifier challenges a storage provider to prove they are actually storing the specific data at the time of the challenge, not just when they initially committed to it. This deters lazy validation and generation attacks, where a provider might quickly regenerate data from a seed instead of storing it persistently. It ensures continuous, honest storage.

Storage proofs enable trust-minimized bridges. A light client on Chain B can verify a Merkle inclusion proof from Chain A's consensus to validate that a transaction was finalized, without relying on a multisig committee. For example, a zkBridge uses validity proofs to verify the state of another chain. This reduces the attack surface compared to purely economic or trusted validator-based bridges.

A core application of storage proofs in blockchain scaling. Light clients or validators use erasure coding and random sampling to probabilistically verify that all data for a block is available, without downloading it entirely. This is the security model for data availability layers like Celestia and Ethereum's danksharding roadmap.

• Purpose: Prevents data withholding attacks where a block producer publishes a block header but withholds transaction data.
• Mechanism: The block data is expanded using erasure coding. Nodes request small, random chunks; successful retrieval of all sampled chunks provides high statistical certainty the full data is available.

zk-Rollups like StarkNet and zkSync use storage proofs, specifically validity proofs, to post succinct verification of state changes to a base layer (e.g., Ethereum). The proof cryptographically attests that a batch of transactions was executed correctly, with the new state root posted on-chain.

• On-Chain Verifier: A smart contract on L1 verifies a zk-SNARK or zk-STARK proof.
• Data Availability: For validium models, storage proofs for data availability are handled off-chain by a committee, while zkRollups typically post call data to Ethereum.

Protocols like Filecoin and Arweave use storage proofs to create persistent, verifiable markets for data storage. Filecoin's Proof-of-Replication (PoRep) and Proof-of-Spacetime (PoSt) are storage proofs that cryptographically verify a miner is physically storing a unique copy of client data over time.

• PoRep: Proves initial, unique encoding of data onto storage hardware.
• PoSt: Proves continuous storage of that data through random challenges over time.
• Outcome: Enables a trustless marketplace where payment is contingent on provable storage.

Storage proofs enable light clients to securely verify events from another blockchain without running a full node. A light client syncs only block headers. To verify a transaction or state, it requests a Merkle proof (a type of storage proof) against a trusted block header.

• Example: The Ethereum Beacon Chain's light client protocol uses sync committees and Merkle proofs.
• Bridge Use Case: A light client bridge on Chain A can verify the inclusion of a deposit event on Chain B using a Merkle proof from Chain B's block header, enabling trust-minimized cross-chain communication.

A specialized storage proof used in Ethereum's sharding design to ensure validators in a committee have actually downloaded and are holding the data for a shard block they are attesting to. It deters lazy validators who might attest to data availability without actually storing it.

• Challenge: A validator must compute a custody bit using a secret key and the shard data.
• Purpose: Makes data withholding attacks economically costly, as malicious validators would be slashed for failing a subsequent proof-of-custody challenge.

Advanced storage proofs, sometimes called state proofs or universal verification, allow one chain to verify the state of another. This goes beyond simple transaction inclusion to prove the result of a state transition.

• Technology: Often implemented using zk-SNARKs/STARKs or optimistic verification with fraud proofs.
• Example: A smart contract on Ethereum could verify a zk-proof demonstrating an account's balance on another L2 or a separate blockchain, enabling complex cross-chain logic without trusted intermediaries.

A cryptographic method allowing one party (the prover) to prove to another (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself. Storage proofs often leverage ZKPs to create succinct, verifiable commitments about the state of a database or file, enabling privacy and scalability.

• Key Property: Completeness, Soundness, Zero-Knowledge.
• Example Use: Proving you possess a file without transmitting it.

A hierarchical data structure where every leaf node is a hash of a data block, and every non-leaf node is a hash of its child nodes. It is the foundational data structure for most storage proofs, allowing efficient and secure verification that a specific piece of data is part of a larger set.

• Core Function: Generates a single root hash that commits to the entire dataset.
• Verification: Providing a Merkle proof (a path of hashes) proves inclusion.

The guarantee that all data necessary to validate a blockchain's state is published and accessible to network participants. Storage proofs are crucial for data availability sampling (DAS), where light clients can probabilistically verify that full data is available without downloading it entirely.

• Problem Solved: Ensuring block producers have actually published transaction data.
• Link to Proofs: Proofs can attest that specific data is available at a given location.

A function that requires a prescribed number of sequential steps to evaluate, but whose output can be verified quickly. In the context of storage, VDFs can be used to create proofs of elapsed time, which are useful for proving that data has been stored continuously for a duration or for generating unbiased randomness from on-chain sources.

• Key Property: Sequentiality, ensuring a mandatory time cost.
• Storage Application: Proofs of continuous availability or retrievability.

A compact proof that allows a verifier to check that a prover (e.g., a storage provider) still possesses and can retrieve a specific file in its entirety. It is a specialized form of storage proof focused on long-term data integrity and is more efficient than simply transferring the file.

• Mechanism: Often uses erasure coding and spot-checking via challenge-response protocols.
• Use Case: Verifying backups in decentralized storage networks like Filecoin.

A cryptographic commitment (typically a Merkle root hash) that represents the entire state of a system, such as all account balances and smart contract storage in an Ethereum-like blockchain. Storage proofs are used to verify transactions or claims against this root without needing the full state.

• Function: Acts as the single source of truth for a blockchain's state at a given block.
• Proof Type: A Merkle-Patricia proof is used to prove membership in the Ethereum state trie.