Data Availability Committee (DAC)

A DAC operates as a multi-signature committee where a predefined threshold of members (e.g., 4 out of 7) must cryptographically sign attestations that data for a new block is available. This creates a collective guarantee, reducing reliance on any single entity. The attestations are posted on-chain, allowing the rollup or Layer 2 to proceed with state transitions.

• Key Mechanism: Uses threshold signature schemes (TSS) or multi-sig wallets.
• Trust Assumption: Users trust that the committee majority is honest.

The primary function is to store and serve the full transaction data (the "data blob") off-chain, typically on high-availability cloud storage or a peer-to-peer network. Only a small data commitment (like a Merkle root) and the attestation are posted on the base layer (e.g., Ethereum). This drastically reduces on-chain gas costs while ensuring data can be retrieved for fraud proofs or validity proofs.

• Example: A rollup batch's data is stored on DAC member servers and IPFS, with its hash posted to Ethereum.

To allow light clients to verify data availability without downloading everything, a DAC often implements a Data Availability Sampling interface. Clients request random small chunks of the data from committee members. If the DAC is withholding data, random sampling will detect this with high probability. This is a bridge towards peer-to-peer DAC designs.

• Key Benefit: Enables trust-minimized verification for users not running full nodes.
• Evolution: P2P networks like Celestia automate this without a committee.

DAC members are typically bonded with staked assets (slashing conditions) or have their reputation at stake. If they sign an attestation for unavailable data or fail to serve data upon request, their stake can be slashed. This economic security aligns committee incentives with honest behavior.

• Enforcement: Slashing is enforced by a smart contract on the base chain.
• Example: In early Validium implementations (e.g., StarkEx), the DAC stake is slashed if fraud is proven and data is missing.

Contrasts with pure on-chain data availability (e.g., Ethereum calldata). A DAC offers lower cost and higher throughput but introduces a trust assumption in the committee's honesty and liveness. It is a security-scalability tradeoff.

• On-Chain DA: Fully secure, cryptographically guaranteed, but expensive.
• DAC/Off-Chain DA: More scalable, cheaper, but introduces committee trust.
• Use Case: Ideal for applications where absolute decentralization is secondary to cost and speed.

The concept is evolving from permissioned enterprise committees to decentralized networks. Projects are building peer-to-peer DAC networks where any node can join by staking, and data availability is guaranteed by cryptoeconomic incentives and proof-of-stake mechanisms, not a fixed committee list. This moves the model closer to a data availability layer.

• Example: EigenDA and Avail represent this evolution, using large, permissionless sets of staked nodes.

Using a DAC involves a clear security-efficiency trade-off compared to standard rollups (which post all data to Ethereum).

• Advantages (DAC):

  • Lower Fees: Drastically reduces L1 calldata costs.
  • Higher Throughput: Less data per transaction enables more TPS.

• Disadvantages (DAC):

  • Trust Assumption: Users must trust the committee to publish data upon request.
  • Censorship Risk: A malicious committee could withhold data, freezing assets.

• Key Distinction: Rollups inherit Ethereum's data availability security; DAC-based systems do not.

A DAC introduces an explicit trusted third-party assumption. Users must trust that a supermajority of committee members (e.g., 7 of 10) are honest and will not collude to withhold data. This is a departure from the cryptoeconomic security of pure Layer 1s, where data availability is enforced by the entire validator set. The security guarantee is social or legal, not cryptographic.

The primary risk is a data withholding attack, where a malicious majority of the DAC refuses to provide the data needed to reconstruct the chain's state. This can lead to:

• Invalid state transitions going unchallenged.
• Funds becoming frozen as users cannot generate fraud proofs.
• A complete liveness failure of the rollup or chain. Mitigations include using cryptographic data availability sampling (DAS) or fallback to posting data on a base layer like Ethereum.

Security depends heavily on the membership and incentive structure of the committee. Key considerations include:

• Reputation: Members are often well-known entities (exchanges, foundations, VCs) staking their reputation.
• Legal Agreements: Binding service-level agreements (SLAs) and legal liability can be enforced.
• Economic Bonding: Members may post stake (slashing bonds) that can be forfeited for malfeasance, aligning economic incentives with honest behavior.

DACs represent a specific point on the security-decentralization-cost spectrum for data availability.

• vs. On-Chain DA (Ethereum): Higher cost, maximal cryptographic security, no trusted committee.
• vs. Data Availability Sampling (Celestia): Uses cryptoeconomics and random sampling by light nodes; trust is minimized but not zero.
• vs. Validium: A specific architecture where a DAC secures data availability off-chain, while proofs are posted on-chain.

A DAC prioritizes liveness (consistent operation) but trades off some safety guarantees. The system remains live as long as the committee functions, but safety can be compromised if the committee acts maliciously. This is an explicit design choice for applications where high throughput and low cost are critical and where the selected committee's trustworthiness is deemed acceptable.

The role of DACs is evolving within modular stacks. Modern implementations often use them as a high-performance layer with a fallback to a more secure layer. Examples include:

• EigenDA: Uses a cryptoeconomically secured set of operators with restaking from Ethereum.
• Hybrid DACs: A small committee handles daily traffic, with data periodically committed to a base layer, reducing the window of risk for data withholding.

A scaling solution where transaction execution is performed off-chain (like a rollup), but data availability is handled by a separate committee or system, not the base layer (e.g., Ethereum). A DAC is a common choice for this role.

• Trade-off: Higher throughput and lower fees than a rollup, but introduces a trust assumption for data availability.
• Contrast with ZK-Rollup: A ZK-Rollup posts data to Ethereum L1; a Validium does not.

An error-correcting code used in data availability schemes to redundantly encode block data. Even if a significant portion of the data is withheld, the original data can be reconstructed from the remaining pieces.

• Role in DAS: Makes data availability sampling feasible and secure.
• Process: Data is expanded into a larger set of encoded chunks; only a subset is needed for recovery.

The cryptographic mechanism by which a DAC attests to data availability. Members sign a message confirming they have received and stored the data, often aggregated into a single multi-signature.

• Function: Provides a compact, verifiable proof of the committee's attestation.
• Security Model: Relies on the assumption that a threshold of honest members will not collude to sign for unavailable data.

A hybrid scaling architecture that gives users a choice per transaction between ZK-Rollup mode (data on-chain for maximum security) and Validium mode (data off-chain via a DAC for lower cost).

• User Sovereignty: Allows flexibility based on the asset's value and required security.
• Implementation: Pioneered by StarkWare, combining the security of Ethereum with the scalability of off-chain data availability.