Data Availability

A light-client technique that allows nodes to verify data availability by downloading only small, random chunks of a block. This enables scalability by removing the need for every node to download the entire dataset. Key aspects include:

• Erasure Coding: Data is encoded so the original can be reconstructed from a subset of chunks.
• Probabilistic Security: The probability of an unavailable block going undetected decreases exponentially with more samples.

A trusted, permissioned set of entities that cryptographically attest to the availability of data, often used in Layer 2 rollups. They provide a lighter-weight alternative to full on-chain publication.

• Members sign attestations that data is stored and will be provided upon request.
• Introduces a trust assumption, as users rely on the committee's honesty.
• Offers lower cost and higher throughput than publishing all data directly to a base layer.

Cryptographic proofs, such as KZG commitments or Merkle proofs, that allow verifiers to check the correctness and availability of data without downloading it entirely. These are foundational for validity proofs (ZK-Rollups) and secure sampling.

• KZG Commitments: A polynomial commitment scheme that binds a prover to a specific data block.
• Fraud Proofs: In optimistic systems, allow a challenger to prove a block's data is unavailable by pointing to a missing chunk.

A redundancy technique where original data is expanded into a larger set of encoded chunks. It ensures the data can be recovered even if a significant portion of chunks are missing or withheld.

• Critical for DAS: Makes sampling possible by guaranteeing recovery from a random subset.
• Expansion Factor: A 2x expansion (e.g., 1 MB → 2 MB of chunks) is common, allowing recovery from 50% loss.
• Prevents data withholding attacks by malicious block producers.

The core challenge of ensuring that block producers have actually published all transaction data, preventing them from hiding invalid state transitions. It is distinct from data validity.

• A malicious producer could create a block with an invalid transaction but only publish a valid Merkle root.
• Without the data, network participants cannot reconstruct the state or generate fraud proofs.
• Solving this is essential for the security of light clients and rollups.

A transaction type, pioneered by Ethereum's EIP-4844 (Proto-Danksharding), designed to carry large amounts of data cheaply for Layer 2 rollups. Blobs are separate from regular transaction calldata.

• Cost-Effective: Priced independently and deleted after ~18 days, reducing long-term storage costs.
• Commitment-Based: The blob's commitment is posted on-chain for verification, while the data is distributed via the peer-to-peer network.
• A key step towards full Danksharding and scalable DA.

Ethereum's mainnet acts as the canonical Data Availability layer for L2 rollups like Arbitrum and Optimism. Rollups post compressed transaction data (called calldata) to Ethereum, where it is permanently stored and verifiable. This leverages Ethereum's high security but incurs significant gas costs, making it expensive at scale.

• Mechanism: Data is posted in transaction calldata.
• Security: Inherits Ethereum's consensus and validator set.
• Example: Optimism's Bedrock upgrade posts all transaction batches to Ethereum L1.

A Data Availability Committee (DAC) is a trusted, permissioned set of entities that sign attestations confirming data is available. This is a lighter, more cost-effective alternative to full on-chain posting, used by validiums and some optimistic rollups.

• Trust Model: Relies on a committee's honesty (typically 5-10 known entities).
• Use Case: Polygon zkEVM Validium mode uses a DAC for lower costs.
• Trade-off: Sacrifices some decentralization and cryptographic security for efficiency.

Monolithic, high-throughput blockchains like Solana handle Data Availability internally. All transaction data is published directly to the chain's validators and is available for state execution and reconstruction. The primary challenge is scaling this monolithic data pipeline.

• Model: Integrated execution and data availability.
• Scaling: Relies on hardware advances and network bandwidth.
• Contrast: Unlike modular stacks, this couples DA security directly to the L1's consensus.

A technique where light clients randomly sample small, random chunks of a block's data to probabilistically verify its availability without downloading the entire block. This enables secure scaling by allowing nodes with limited resources to participate in consensus.

• Core Concept: Based on erasure coding, where data is expanded so that any sufficient subset can reconstruct the whole.
• Process: Clients request random pieces; if all samples are returned, the data is highly likely to be fully available.
• Key Benefit: Enables the practical use of data availability committees (DACs) and modular blockchains by reducing verification load.

A permissioned set of known entities tasked with attesting that transaction data for a rollup is available. This is a simpler, trust-minimized alternative to full on-chain data publishing.

• How it Works: A committee of members cryptographically signs attestations that data is available off-chain. The rollup contract verifies a threshold of signatures.
• Trust Assumption: Relies on the honesty of a committee majority, offering weaker guarantees than cryptographic proofs but with lower cost and latency.
• Use Case: Commonly used by optimistic rollups in their early stages (e.g., early Arbitrum Nova) to reduce costs before implementing full DAS.

An Ethereum upgrade that introduced a new transaction type carrying data blobs, which are large, inexpensive data packets intended for rollup data availability.

• Mechanism: Blobs are stored in the Beacon Chain consensus layer for ~18 days and are subject to data availability sampling by consensus validators.
• Purpose: Provides proto-danksharding, a precursor to full danksharding, significantly reducing the cost for L2s to post data to Ethereum.
• Key Feature: Blob data is not accessible to the EVM, making it pure data availability space, which is much cheaper than calldata.

For ZK-Rollups, data availability requirements are intrinsically linked to the type of validity proof used. The need to verify state transitions changes how data is handled.

• ZK-Rollups with On-Chain Data: The most secure model. State diffs and validity proofs are posted on-chain, giving users strong guarantees for self-custody and forced exits.
• Validiums: Use validity proofs for state integrity but keep data off-chain with a Data Availability Committee (DAC). This trades off some decentralization for lower costs.
• Volitions: A hybrid model that lets users choose per transaction between a ZK-Rollup (data on-chain) and a Validium (data off-chain) mode, balancing cost and security.

The core challenge in scaling blockchains is ensuring that block producers (e.g., rollup sequencers) make all transaction data available for verification, without requiring every node to download the entire dataset. If data is withheld, validators cannot detect invalid state transitions, leading to fraud proofs being impossible to construct. This is the fundamental problem that Data Availability Sampling (DAS) and dedicated Data Availability Layers are designed to solve.

A malicious block producer can commit a new state root to L1 without publishing the corresponding transaction data. This creates a data withholding attack, where:

• Other nodes cannot reconstruct the block to verify its correctness.
• Fraud proof systems are rendered useless, as verifiers lack the data to prove fraud.
• This can lead to stolen funds if an invalid state is finalized. The risk is highest for optimistic rollups during their challenge period.

A cryptographic solution where light nodes randomly sample small, random chunks of a block. By using erasure coding to redundantly encode the data, nodes can achieve high statistical certainty (e.g., 99.9%) that all data is available by only downloading a tiny fraction. This is the security model for Celestia and Ethereum's Proto-Danksharding (EIP-4844). It allows scalability while maintaining decentralized verification.

A trusted, permissioned set of entities that sign attestations confirming data is available. Used by some early zk-rollups (e.g., early zkSync) as an interim scaling solution. Security Risks:

• Relies on honest majority assumption of committee members.
• Introduces trust assumptions and potential for collusion.
• Seen as less decentralized than cryptographic approaches like DAS. Most projects aim to migrate from DACs to pure on-chain DA solutions.

EigenLayer's restaking model allows Ethereum stakers to opt-in to secure additional services, including Data Availability layers like EigenDA. Security Considerations:

• Slashing Risk: Operators can be slashed for DA failures, aligning economic security.
• Correlated Slashing: A bug in the AVS (Actively Validated Service) could lead to mass slashing of restaked ETH.
• Dilution of Security: The same stake secures both Ethereum consensus and the DA layer, creating shared risk.

Ethereum's native scaling upgrade introducing blob-carrying transactions. Blobs are large data packets attached to blocks but not executed by the EVM, providing cheap, temporary DA for L2s. Security Model:

• Blobs are subject to Data Availability Sampling by consensus nodes.
• They are automatically deleted after ~18 days, reducing node storage burden.
• This moves rollups from expensive calldata to dedicated blobspace, enhancing security and reducing costs.

A trusted, permissioned set of entities that sign attestations confirming they hold a copy of transaction data for a rollup. This is a simpler, more centralized alternative to a full data availability layer.

• Use Case: Used by some optimistic rollups (e.g., early Arbitrum Nova).
• Trust Assumption: Relies on the honesty of a majority of committee members.

Security mechanisms for rollups that depend on data availability.

• Fraud Proofs (Optimistic Rollups): Require the full transaction data to be available on-chain so any watcher can challenge invalid state transitions.
• Validity Proofs (ZK-Rollups): Require the input data (or a commitment to it) to be available so the zero-knowledge proof can be verified, proving state correctness.

A specialized blockchain whose primary function is to order and guarantee the availability of data for other execution layers (rollups). It decouples data publication from execution.

• Examples: Celestia, Avail, EigenDA.
• Core Function: Provides a secure, scalable, and cost-effective base for sovereign rollups and modular blockchains.