Data Availability Service Level Agreement (SLA)

The SLA specifies the minimum acceptable availability percentage (e.g., 99.9%) for data to be retrievable. This is often measured over a monthly or quarterly period. Failure to meet this target typically triggers service credits or penalties.

• Example: A 99.9% uptime SLA allows for approximately 43.8 minutes of downtime per month.
• Importance: Ensures rollups can consistently reconstruct their state and validate transactions.

This defines the maximum acceptable delay between when data is published and when it becomes provably available for download. Low latency is crucial for fast block confirmation and sequencer operation.

• Measured in: Seconds or milliseconds.
• Key Mechanism: Often tied to the data availability sampling window, where light nodes must be able to successfully sample the data within this timeframe.

The SLA outlines the financial remedies for failing to meet its guarantees. Service credits are the primary mechanism, offering users a refund or discount on future service fees proportional to the severity of the failure.

• Example: A 1% service credit for missing the uptime SLA by 0.1%, increasing for more severe breaches.
• Purpose: Aligns the economic incentives of the provider with the security needs of the users.

These clauses define events that exempt the provider from SLA penalties. Typical exclusions include network-wide outages, acts of God, or malicious attacks beyond reasonable defense (e.g., a 51% attack on the underlying consensus layer).

• Critical Detail: A robust SLA clearly defines what constitutes an excusable event to prevent abuse.
• User Risk: Highlights that SLAs protect against operational failures, not systemic protocol risks.

Specifies the minimum duration for which published data is guaranteed to be stored and retrievable. This must exceed the fraud proof window or challenge period of any relying rollup.

• Typical Range: 30 days to several weeks, often aligned with Ethereum's 7-day challenge period for optimistic rollups.
• Security Implication: If data is deleted before the challenge window ends, rollup funds cannot be securely withdrawn.

The SLA mandates transparent, verifiable reporting on performance metrics. This often includes:

• Public Dashboards: Real-time display of uptime and latency.
• Audit Trails: Cryptographic proofs of data publication and availability.
• Regular Reports: Detailed summaries of SLA compliance and any breach incidents. This transparency allows users to independently verify the provider is meeting its commitments.

The percentage of time the DA layer is operational and able to accept and serve data. This is the most fundamental SLA metric.

• Measured as: (Total Time - Downtime) / Total Time * 100%.
• Industry Standard: High-performance DA layers target 99.9% (Three Nines) or higher availability, equating to less than ~8.76 hours of downtime per year.
• Impact: Downtime can halt block production in L2 rollups, causing transaction finality failures.

The time delay between a rollup sequencer publishing a batch of transactions and that data being fully available and verifiable on the DA layer.

• Critical for L2 Performance: Directly impacts the time to finality for user transactions.
• Typical Targets: Optimistic rollups may tolerate seconds, while ZK-rollups often require sub-second latency for optimal throughput.
• Measurement: Often expressed as a P99 latency (e.g., 99% of data is available within 2 seconds).

The time required for any network participant (e.g., a verifier or a new node) to successfully fetch and reconstruct the original data from the DA layer.

• Key for Censorship Resistance: Ensures anyone can act as a verifier without relying on the sequencer.
• Sampling-Based Systems: In networks using Data Availability Sampling (DAS), this is the time to sample enough erasure-coded chunks to reconstruct the data with high probability.
• SLA Guarantee: Often defined as a maximum retrieval time under normal network conditions.

The rate at which the DA layer can accept and make data available, measured in bytes per second (B/s) or megabytes per block.

• Bottleneck for Rollups: A DA layer's throughput cap directly limits the transactions per second (TPS) of the rollups built on it.
• Two Components:
  • Acceptance Rate: Speed of ingesting new data.
  • Propagation Rate: Speed of distributing data across the network.
• Example: A DA layer guaranteeing 1 MB/s sustained throughput can support rollups publishing data at that rate.

The cryptographic assurance that published data is available for retrieval. This is the security foundation of the SLA.

• Mechanisms:
  • Data Availability Proofs (DAPs): Cryptographic commitments (like KZG polynomial commitments) that allow light clients to verify availability without downloading all data.
  • Erasure Coding: Data is expanded with redundancy; availability is guaranteed if any 50%+ of the chunks are retrievable.
• SLA Enforcement: The protocol's consensus rules automatically slash or penalize nodes that sign for unavailable data.

A non-technical but critical operational metric defining the stability and transparency of data publishing fees.

• Importance for Rollups: Unpredictable, volatile DA costs make it impossible to reliably calculate L2 transaction fees for users.
• SLA Components:
  • Fee Model Transparency: Clear, published formula (e.g., cost per byte).
  • Fee Stability: Bounded volatility over defined time periods, or a credible fee market design.
• Economic SLA: This guarantees the operational feasibility of running a rollup on the DA layer.

The primary promise of a DA SLA is that transaction data for a block will be publicly available for a defined period, allowing anyone to reconstruct the chain state and verify validity proofs. This prevents data withholding attacks, where a sequencer could publish only block headers, making fraud proofs impossible.

• Key Metric: Uptime percentage (e.g., 99.9%).
• Enforcement: Typically enforced through cryptoeconomic slashing or financial penalties.

SLAs specify measurable targets for latency and throughput to ensure the layer meets rollup needs.

• Data Publishing Latency: The time between a rollup sequencing a block and the data being confirmed as available on the DA layer.
• Data Retrieval Speed: How quickly any user or node can download the data for a given block height.
• Throughput Capacity: Measured in bytes per second or MB per block, defining the network's data bandwidth.

To credibly enforce guarantees, DA SLAs define faults that trigger slashing of staked collateral from node operators.

• Unavailability Fault: Failing to make data available within the SLA window.
• Censorship Fault: Selectively withholding specific transactions.
• Penalty Structure: Slashing may be a fixed amount, a percentage of stake, or escalate with fault severity. This creates a strong cryptoeconomic security model aligned with network health.

SLAs require a transparent mechanism for users to challenge perceived SLA violations. This often involves:

• Fraud Proofs for Data: Light clients can issue a challenge if they cannot retrieve data, triggering a verification game.
• Attestation Committees: Committees of randomly selected stakers attest to data availability, with their signatures serving as proof.
• Escalation Paths: Clear processes for arbitrating unresolved disputes, potentially involving a governance layer or external adjudication.

Specialized DA layers offer explicit SLAs with distinct models.

• EigenDA: Operates on Ethereum using restaking via EigenLayer. Its SLA is backed by the cryptoeconomic security of restaked ETH. Operators are slashed for faults.
• Celestia: A standalone DA blockchain. Its SLA is enforced by its own Proof-of-Stake consensus. Data availability sampling (DAS) allows light nodes to probabilistically verify the SLA is being met.

These provide sovereign DA guarantees separate from execution layer consensus.

A lightweight verification technique where nodes download small, random chunks of block data to probabilistically confirm its availability. This enables resource-efficient scaling without requiring nodes to download entire blocks.

• Key Benefit: Allows light clients and validators to verify data availability with high confidence.
• Implementation: Used by networks like Celestia and Ethereum's danksharding roadmap.

A data redundancy method that expands the original data with parity chunks, allowing the full dataset to be reconstructed even if a significant portion of chunks are missing. This is the cryptographic backbone of most DA guarantees.

• Purpose: Increases resilience against data withholding attacks.
• Process: A block's data is encoded so that only 50% (or less) of the chunks are needed for recovery.

A permissioned set of trusted entities that cryptographically attest (via signatures) to the availability of transaction data. This provides a weaker, trust-based form of DA guarantee compared to cryptographic proofs.

• Use Case: Common in early optimistic rollup implementations (e.g., early Arbitrum Nova).
• Trade-off: Offers lower cost and complexity but introduces a trust assumption in the committee members.

A cryptographic proof, such as a KZG polynomial commitment or a Merkle root, that allows any verifier to check that a specific piece of data is part of a committed dataset and is available. This is the core technical mechanism enforcing an SLA.

• Function: Binds the published data to the block header, enabling fraud proofs or validity proofs.

A transaction format introduced by Ethereum's EIP-4844 (Proto-Danksharding) that carries large data 'blobs' separate from execution. Blobs are cheap to post but are automatically deleted after a short period (1-2 weeks).

• Purpose: Provides a dedicated, low-cost data channel for Layer 2 rollups.
• DA Guarantee: Relies on Ethereum's consensus for short-term availability, with long-term persistence delegated to rollups.

A malicious scenario where a block producer publishes a block header but withholds the corresponding transaction data. This prevents other validators from verifying state transitions, potentially enabling fraud.

• Threat Model: The primary security risk that Data Availability solutions are designed to mitigate.
• Defense: Mechanisms like erasure coding and data availability sampling make this attack economically infeasible or easily detectable.