Data Availability Attack Vector

A data withholding attack occurs when a block producer (e.g., a validator or sequencer) creates a valid block but intentionally withholds a portion of the transaction data. This prevents other network participants from verifying the block's contents, creating a scenario where invalid transactions (like double-spends) could be hidden.

• Core Mechanism: The attacker publishes only the block header, making the block appear valid at the consensus layer while the data layer is incomplete.
• Impact: Honest validators cannot perform full execution, forcing them to choose between accepting an unverifiable block (risking fraud) or forking the chain (causing liveness failure).

DAS griefing is an attack targeting networks that use Data Availability Sampling for scalability. Here, a malicious block producer correctly publishes all data but structures it to maximize the sampling workload for light clients or validators, potentially causing timeouts and leading them to incorrectly reject an available block.

• How it Works: The attacker arranges data erasure codes so that a disproportionate number of samples are required to reach statistical certainty of availability.
• Consequence: This can degrade network performance, increase latency, and undermine the efficiency guarantees of the sampling protocol.

This attack involves a block producer publishing an incorrectly constructed erasure-coded block. In systems like Celestia or Ethereum DankSharding, data is expanded with redundancy using erasure coding (e.g., Reed-Solomon).

• The Fraud: The attacker creates a block where the coded data does not correspond to the original data, breaking the mathematical relationship.
• Detection: It relies on honest nodes performing fraud proofs to demonstrate the coding is invalid. If the network lacks sufficient nodes to detect and propagate the proof, the faulty block may be accepted.

A strategic liveness attack exploits the data availability problem to halt the chain. By consistently producing blocks but withholding their data, a malicious cartel of validators can force the network into a state where no new blocks can be safely finalized.

• Strategic Goal: Unlike fraud, the goal is denial-of-service, not financial theft.
• Requirement: This typically requires control of a significant portion (e.g., >1/3) of the block production rights to be sustained.
• Result: The chain stops progressing as honest participants cannot verify blocks, illustrating the tight coupling between liveness and data availability.

This is an application-layer attack where a cross-chain bridge or oracle relay assumes data availability on a source chain that has been compromised. An attacker submits a fraudulent state root or transaction proof to the destination chain, backed by data that was never made available on the source chain.

• Vulnerability: Bridges often assume light client verification is sufficient, but this fails if the source chain's data availability layer is under attack.
• Real-World Risk: This was a considered threat vector in the design of optimistic rollups, where the challenge period exists to allow fraud proofs if data is available.

A trusted, permissioned set of entities that cryptographically attest (via signatures) that transaction data for a block is available. This provides a faster, simpler guarantee than cryptographic proofs but introduces a trust assumption.

• Use Case: Common in optimistic rollups (e.g., early Arbitrum Nova) as an interim scaling solution.
• Operation: Committee members must store data and provide it upon request.
• Trust Model: Security depends on the honesty of a majority of committee members.

ZK-Rollups inherently mitigate data availability risks by publishing validity proofs (ZK-SNARKs/STARKs) on-chain. The proof verifies state correctness independently of full data publication.

• Security Model: Users only need the state root and proof; full data is needed only for censorship resistance and rebuilding state.
• Hybrid Approach: Most ZK-rollups (e.g., zkSync, StarkNet) still post calldata or blobs for full security and decentralization.
• Future Vision: Volitions let users choose between on-chain data (high security) and off-chain data availability (lower cost).

The foundational layer for data propagation, where full nodes and block builders broadcast transaction data across a robust, incentivized network. A resilient gossip layer is the first line of defense.

• Purpose: Ensures data is widely replicated before a block is finalized.
• Incentives: Protocols like Ethereum's proposer-builder separation (PBS) may include penalties for builders who withhold data.
• Attacks: Targeted eclipse attacks or network partitioning can weaken gossip, making other DA proofs critical.

Used primarily in optimistic rollups, this mechanism allows any honest node to challenge a sequencer suspected of withholding data by requesting a specific data chunk. Failure to provide it results in a slashing penalty.

• Challenge Period: A window (e.g., 7 days) where data withholding can be challenged.
• Requirement: Requires at least one honest, fully-synced node to monitor the chain.
• Limitation: Security depends on the liveness of at least one honest participant.

A cryptographic technique that allows light clients or nodes to probabilistically verify data availability by downloading small, random chunks of a block. This makes it computationally infeasible for a malicious block producer to hide a significant portion of data without being detected. DAS is a core primitive for scaling solutions like Ethereum's danksharding and Celestia, enabling secure block verification without downloading the entire dataset.

A trusted, permissioned set of entities that cryptographically attest (via signatures) that transaction data for a rollup or layer-2 block is available. This provides a weaker security assumption than cryptoeconomic guarantees or DAS, but offers a practical scaling solution. The security model depends on the honesty of a majority of committee members. Examples include early iterations of Validium and some zk-rollup designs.

A cryptographic proof that demonstrates a state transition (e.g., in an Optimistic Rollup) was invalid. Its execution depends on data availability because verifiers must have access to the disputed transaction data to reconstruct and challenge the faulty state transition. If the data is withheld in a data availability attack, fraud proofs cannot be constructed, allowing the invalid state to become finalized.

A data redundancy method that expands the original block data with parity chunks, allowing the full data to be reconstructed even if a significant percentage (e.g., 50%) of the chunks are missing. This is a prerequisite for effective Data Availability Sampling (DAS), as it ensures that sampling a small fraction of the total data provides high confidence that the entire dataset is available. It transforms the problem from 'is all data present?' to 'is enough data present to reconstruct the whole?'.

The core challenge in blockchain scalability: how can nodes verify that all data for a new block is published without downloading the entire block themselves? This is distinct from data validity. The problem is central to the security of light clients, rollups, and sharded systems. Solutions like DAS and DACs are direct responses to this fundamental problem, which a Data Availability Attack Vector seeks to exploit.

An Ethereum upgrade that introduces a new transaction format carrying large 'blobs' of data that are not accessible to the EVM and are automatically deleted after ~18 days. Blobs provide a dedicated, low-cost data channel for layer-2 rollups, significantly improving their scalability. The design separates data availability (ensured by consensus layer nodes) from data storage, directly mitigating data availability risks for rollups by guaranteeing the data is published on-chain.