ZK-Rollup Data Availability

A flexible architecture that allows users or applications to choose per-transaction whether data is posted on-chain or off-chain. This provides a spectrum of security and cost options.

• User Choice: High-value transactions can opt for secure on-chain DA, while low-value ones use cheaper off-chain DA.
• Granular Control: Balances security and cost-efficiency dynamically.
• Implementation: Pioneered by StarkWare's Volition model.

A permissioned set of known entities tasked with storing and attesting to the availability of off-chain transaction data. A ZK-proof verifies that the committee signed off on the data's availability.

• Trust Model: Security depends on the assumption that a threshold of committee members is honest and available.
• Use Case: Common in enterprise-focused Validium solutions where a known consortium is acceptable.
• Limitation: Introduces a trust assumption compared to purely cryptographic guarantees.

An NFT's history and authenticity are encoded in its on-chain transaction data. Data Availability guarantees this provenance record is permanently accessible. Without it, the link between the off-chain asset (e.g., an image) and its on-chain token can be broken, undermining the core value proposition of NFTs as verifiably unique digital items.

In a ZK-Rollup, a cryptographic proof (ZK-SNARK/STARK) validates state transitions (like NFT transfers). However, the proof only confirms the computation was correct if the input data is available. Publishing the data allows anyone to reconstruct the rollup's state, ensuring the proof is being applied to the correct transactions and preventing a malicious operator from creating valid proofs for invalid state changes.

Users can only securely withdraw their assets from a rollup to the mainnet (Ethereum L1) if they can independently verify their ownership. Data Availability provides the necessary transaction history for users or watchtowers to generate a fraud proof or validity proof of their balance, ensuring exit rights even if the rollup operator is uncooperative or offline.

Publishing data to Ethereum L1 is the primary cost for rollups. Solutions to reduce this cost create DA trade-offs:

• Validium: Uses off-chain DA committees for higher throughput/ lower cost, but introduces trust assumptions for asset safety.
• Volition: Lets users choose per-asset (e.g., a high-value NFT) between on-chain DA (high security) and off-chain DA (lower cost).
• Ethereum EIP-4844 (Proto-Danksharding): Reduces DA costs via dedicated blob storage, making on-chain DA more economical.

Data Availability Sampling is a technique where light nodes can verify data is available by randomly sampling small pieces of the published data. This is a core innovation for Ethereum Danksharding and modular DA layers like Celestia and EigenDA, enabling highly scalable networks where nodes don't need to download all data to trust its availability.

A ZK-Rollup variant where zero-knowledge proofs are posted on-chain, but transaction data is stored off-chain by a committee or Data Availability Committee (DAC).

• Examples: Immutable X, Sorare, some StarkEx applications.
• Mechanism: A DAC of known entities cryptographically attests to data availability. Users must trust the honesty of this committee.
• Trade-off: Dramatically lower fees and higher throughput, but introduces a trust assumption regarding data withholding.

A flexible system pioneered by StarkWare that allows users or applications to choose per-transaction between on-chain DA and Validium-mode (off-chain DA).

• Example: Starknet's Volition.
• Mechanism: Users can opt for high-security, costly on-chain posting for valuable assets, or low-cost, committee-based posting for less critical transactions.
• Benefit: Provides granular control over the security-cost spectrum, optimizing for different use cases within the same rollup.

The core risk is that a sequencer could withhold the transaction data needed to reconstruct the rollup state. Without this data, users cannot:

• Prove ownership of their assets.
• Exit to the underlying L1 (Ethereum).
• Verify the correctness of state transitions independently. This creates a liveness failure, freezing funds, even if the ZK-proof is valid.

Validium and Volition models introduce distinct risk profiles:

• Validium: Data is kept off-chain by a Data Availability Committee (DAC). Users trust the committee's honesty and liveness. A malicious or offline DAC can freeze assets.
• Volition: Users choose per-transaction whether data is posted on-chain (ZK-Rollup mode) or off-chain (Validium mode), allowing them to self-select risk and cost.
• Standard ZK-Rollup: All data is posted to calldata or blobs on Ethereum, inheriting its high availability guarantees.

A DAC is a set of trusted entities that sign off on data availability for Validiums. Key security considerations:

• Trust Assumption: Requires a honest majority of members to not collude and withhold data.
• Liveness Requirement: Requires a available majority to be online and signing.
• Membership & Slashing: Security depends on member identity (permissioned vs. permissionless) and the existence of cryptoeconomic slashing for misbehavior.

Posting data to Ethereum's calldata or EIP-4844 blob transactions provides the strongest guarantee. Risks shift to:

• L1 Censorship: While extremely costly, a malicious L1 validator could theoretically censor rollup data blocks.
• Cost & Scalability: High data posting costs are a trade-off for security, potentially limiting throughput.
• Blob Pruning: EIP-4844 blobs are pruned after ~18 days, requiring rollups to implement long-term data storage solutions.

Data availability interacts differently with rollup security models:

• ZK-Rollups (Validity Proofs): A valid ZK-proof confirms state correctness even if data is unavailable. The risk is purely liveness (can't exit), not safety (invalid state).
• Optimistic Rollups (Fraud Proofs): Data availability is essential for safety. If data is unavailable, a fraudulent state root cannot be challenged, potentially allowing theft. This makes data availability critically safety-relevant for Optimistic Rollups and critically liveness-relevant for ZK-Rollups.