Temporal Availability

The guarantee that a blockchain network will continue to produce new blocks at a predictable rate. This is a core liveness property, ensuring the system makes progress. Failures in block production lead to network downtime. Key mechanisms include:

• Proof-of-Work (PoW): Relies on miners solving cryptographic puzzles.
• Proof-of-Stake (PoS): Uses validators who stake capital to propose blocks.
• Leader Election: Protocols like Tendermint or HotStuff ensure a designated leader is always available to propose the next block.

A technique allowing light nodes to probabilistically verify that all data for a block is published and available, without downloading the entire dataset. This is foundational for scaling solutions like rollups. Key aspects:

• Nodes perform multiple random checks on small chunks of data.
• High confidence in availability is achieved with a logarithmic number of samples.
• Prevents data withholding attacks where a block producer publishes a block header but withholds the underlying transaction data.

A set of trusted entities that cryptographically attest to the availability of data for a specific period, often used in early validium or certain zk-rollup designs. They provide a temporal guarantee that data can be retrieved from them if the primary source fails.

• Members sign attestations for each batch of data.
• Offers a pragmatic security model between pure on-chain availability and full off-chain storage.
• Relies on the honesty of a known, permissioned set.

Specialized blockchain layers, like Celestia or EigenDA, whose primary purpose is to guarantee the temporal availability of data for other execution layers (rollups). They provide:

• High-throughput data publishing optimized for blob data.
• Built-in Data Availability Sampling (DAS) for light client verification.
• Economic security through their own consensus and crypto-economic penalties for data withholding.

A defined time window during which network participants can challenge invalid state transitions or prove data was withheld. This creates a temporal bound for enforcing correctness.

• In optimistic rollups, this is the fraud proof window (e.g., 7 days).
• Users must ensure data remains available for the entire duration to allow challenges.
• The system's safety depends on at least one honest actor being active during this period.

A cryptographic method to ensure data remains available even if some parts are lost. Data is expanded with redundant pieces using an erasure code (like Reed-Solomon).

• Allows reconstruction of the full data from any sufficient subset of pieces.
• Critical for Data Availability Sampling, as samples can be taken from any redundant piece.
• Increases storage overhead but provides robust temporal guarantees against node failures.

At the base layer, temporal availability is enforced by the consensus protocol. For example:

• Proof-of-Work (Bitcoin): Data is considered available once a block is mined and propagated. Finality is probabilistic, increasing with subsequent confirmations.
• Proof-of-Stake (Ethereum): Data availability is a prerequisite for block validity. Validators must attest to having received all block data before finalizing it through the Casper FFG mechanism.

Rollups depend on the underlying L1 for data availability, which is their primary security model.

• Optimistic Rollups (e.g., Arbitrum, Optimism): Post transaction data (calldata or blobs) to the L1. A challenge period (typically 7 days) allows anyone to dispute state transitions if data was unavailable.
• ZK-Rollups (e.g., zkSync, Starknet): Post state diffs and validity proofs to the L1. The proof confirms correct execution, but users still rely on L1 for the data needed to reconstruct state.

A technique used by modular blockchains and data availability layers to allow light clients to verify data is available without downloading the entire block.

• How it works: The block data is erasure-coded and distributed. Light clients randomly sample small pieces. If all samples are retrievable, they can statistically guarantee the entire data is available.
• Key Implementations: Celestia pioneered this, and Ethereum's Proto-Danksharding (EIP-4844) introduces blob data with a similar sampling goal for rollups.

A permissioned, trust-minimized alternative to posting all data on-chain.

• Function: A known set of entities (the committee) signs attestations that they hold the data off-chain and will make it available upon request.
• Use Case: Used by some Validiums (e.g., certain StarkEx deployments) to reduce costs while providing stronger availability guarantees than a single operator. Security depends on the honesty of a majority of committee members.

A core blockchain scaling trilemma: ensuring data is available for verification without requiring every node to store everything.

• The Issue: A malicious block producer can withhold transaction data, making it impossible for honest validators to verify the block's correctness, leading to potential double-spends or invalid state transitions.
• Solutions: The ecosystem addresses this with data availability layers (Celestia, Avail), sharding (Ethereum Danksharding), and hybrid models like DACs.

End-user applications rely on the temporal availability guarantees of the chains they interact with.

• Light Clients: Use techniques like DAS or fraud proofs to trustlessly verify data availability without running a full node.
• Wallet Security: If a wallet's RPC provider relies on a chain with weak availability, balance queries and transaction simulations can be incorrect. Strong DA ensures users see the true, canonical state.

A core tenet of temporal availability is ensuring transactions cannot be indefinitely delayed or excluded from the ledger. This is enforced by decentralized consensus mechanisms like Proof-of-Work or Proof-of-Stake, which prevent any single entity from controlling transaction ordering. Without this, a network is vulnerable to censorship attacks, undermining its utility as a neutral platform.

In distributed systems theory, temporal availability is closely tied to the liveness property, which guarantees that the system will eventually make progress. This is often in tension with safety (the guarantee that nothing bad happens, like a double-spend). Blockchain protocols must balance these to ensure both continuous operation and correctness. A network that halts completely has failed its liveness guarantee.

Blockchains must maintain availability under adversarial conditions, including spam attacks designed to flood the network with transactions. Key defenses include:

• Economic fees (gas) to price out spam.
• Rate-limiting mechanisms at the peer-to-peer layer.
• Node resource management to handle traffic spikes. Failure here can render the network unusable for legitimate users.

New nodes must be able to join the network and synchronize with the current state. Temporal availability requires that historical data is accessible and that the bootstrapping process is reliable. Dependence on a small set of centralized RPC providers or snapshot servers creates a single point of failure, threatening long-term network availability if those services go offline.

While related to persistence, this focuses on the ongoing ability to retrieve and verify historical data. Threats include:

• Pruning nodes reducing the number of full archival nodes.
• Dependency on external storage (like IPFS) that may not guarantee uptime.
• Protocol upgrades that could orphan old data formats. Solutions involve incentivizing archival nodes and using decentralized storage networks.

The process for implementing hard forks and protocol upgrades must itself be available and resistant to capture. If upgrade mechanisms are centralized or can be stalled by a minority, the network's ability to evolve and fix critical bugs is compromised, posing a long-term availability risk. On-chain governance models aim to address this but introduce their own liveness challenges.