Data Availability Committee (DAC)

A DAC operates on a multi-signature (multisig) or threshold signature scheme where a predefined quorum (e.g., 5 of 8 members) must attest to data availability. This creates a trusted execution environment distinct from the decentralized security of the underlying Layer 1. Members are typically known, reputable entities like exchanges, foundations, or infrastructure providers, whose reputations act as collateral.

The core function is storing transaction data off-chain to save gas costs. The DAC provides a cryptographic commitment (like a Merkle root or a KZG polynomial commitment) to this data, which is posted on-chain. Users and validators can then request data attestations or fraud proofs from the committee members to verify availability without downloading the full dataset themselves.

DACs are the foundational data availability layer for Validium scaling solutions (e.g., StarkEx with DAC mode) and Volition architectures (like those from Polygon zkEVM). By moving data off-chain, they enable high transaction throughput and minimal gas fees for end-users, as only small commitments are settled on the base layer. This trade-off prioritizes scalability over pure decentralization.

Committee members continuously monitor and sign attestations confirming they hold the complete data for a specific batch or block. These signed attestations are the proof of custody. If a user cannot retrieve data, they can present the absence of a sufficient number of attestations as evidence of failure, potentially triggering a safety freeze or other protocol penalties.

Security relies on the honest majority assumption within the committee. The system is secure as long as the required quorum of members is honest and available. This is a weaker security guarantee compared to Ethereum's base layer or Ethereum Data Availability (EIP-4844 blobs) but is considered sufficient for many high-throughput applications. The risk is data withholding, not invalid state transitions.

DAC members are typically permissioned and vetted. Incentives can include:

• Service fees paid by the rollup sequencer.
• Reputational stakes where misconduct damages a public entity's credibility.
• Slashing mechanisms where a bond or stake can be forfeited for provable non-performance or malicious behavior. The exact model varies by implementation.

zkSync Era (formerly zkSync 2.0) initially launched using a Data Availability Committee before transitioning to full Ethereum calldata for data availability. This phased approach demonstrated:

• Bootstrapping Strategy: Using a DAC allowed the network to launch quickly and cost-effectively while building towards decentralization.
• Security Assumptions: Relied on a committee of trusted guardians to post and attest to data availability for the zkRollup's state transitions.
• Evolution to L1 DA: It highlights a common path where projects start with a DAC and later upgrade to more decentralized data availability solutions.

Protocols implement DACs with different architectural choices that define their security and trust model:

• Committee Size & Selection: Ranges from small, permissioned groups (e.g., 7-20 known entities) to larger, permissionless sets.
• Incentive Mechanism: Uses slashing, rewards, or reputation to ensure honest participation.
• Data Redundancy: How many committee members must store the data (e.g., 2-of-N, majority).
• Failure Mode: Defines the protocol's action if the DAC fails, such as halting or falling back to L1.

Choosing a DAC model involves balancing clear trade-offs compared to posting all data directly to a base layer like Ethereum:

• Cost: DACs dramatically reduce data posting fees, enabling ultra-low transaction costs.
• Trust Assumption: Introduces a trusted third-party assumption, moving away from pure cryptographic security.
• Decentralization: Often less decentralized than the underlying L1, creating a potential centralization vector.
• Time-to-Finality: Can enable faster finality than waiting for L1 block confirmations.

A DAC operates on a trusted or assumed honest majority model, in contrast to the cryptoeconomic security of on-chain data availability. Users must trust that a quorum of committee members will not collude to withhold data. This is a fundamental trade-off for scalability, as it reduces the security guarantees from the base layer to a smaller, permissioned set of actors.

Security depends heavily on the selection and incentives of members. Key considerations include:

• Reputation & Identity: Members are often known, reputable entities (e.g., foundations, exchanges, VCs).
• Bonding/Slashing: Some implementations use staked bonds that can be slashed for provable malfeasance.
• Collusion Risk: The economic or reputational cost of collusion must be prohibitively high. The model fails if a majority decides to act maliciously.

The primary threat is a data withholding attack, where the committee refuses to provide the data needed to reconstruct the rollup state. This can lead to:

• Invalid State Transitions: Without data, verifiers cannot check the correctness of state updates.
• Funds Locked: Users may be unable to withdraw assets if fraud proofs cannot be constructed. The security window is defined by the DAC's attestation period and any fallback mechanisms.

DACs provide cryptographic attestations (signatures) that data is available. These signatures are posted on-chain. However, these attestations are not fraud proofs; they are promises. If a signature is found to be fraudulent (e.g., data is unavailable), the system may have slashing conditions, but the damage from the unverifiable block may already be done during the challenge period.

The security model shifts the assumption:

• Liveness: Relies on the DAC being online and responsive to data requests.
• Safety: Relies on the DAC being honest. A malicious DAC can create an invalid but unprovable state, breaking safety. This differs from pure on-chain data, where liveness is guaranteed by the chain and safety is enforced by consensus and fraud proofs.

Contrasts with Data Availability Sampling (DAS) used by validiums and zk-rollups with blob storage:

• DAC: Trusted committee (N-of-M signatures). Lower cost, higher trust.
• DAS (e.g., Celestia, EigenDA): Trustless, probabilistic sampling by light nodes. Higher cost, base-layer security.
• Ethereum Blobs: Full data availability on Ethereum, maximally secure but higher cost. DACs are a scaling solution when full on-chain availability is too expensive.