Data availability

Who this is for: developers and issuers who want to understand where the transaction data behind Lumia's state actually lives, and why that's a separate question from correctness. You should already know: Architecture.

Why data availability is its own question

A validity proof (see Architecture) tells you a state transition was computed correctly. It does not, by itself, tell you that the underlying transaction data is anywhere you can get at it. Those are two separate guarantees: correctness (proven cryptographically) and availability (whether the raw data needed to reconstruct or challenge state actually exists somewhere accessible). A chain can have a perfectly valid proof and still leave users unable to independently verify or reconstruct their own balances if the data behind that proof isn't published anywhere retrievable.

Where that data lives is a real architectural trade-off between cost and trust assumptions, not an implementation detail: fully on the base chain (a rollup), off-chain with a separate availability guarantee (a validium), or a choice between the two (volition). The validium and volition models are covered below, along with Avail, the data-availability network named for this role.

The two data-availability models covered here differ in where a batch's transaction data ends up:

Validium

What a validium is, and how it differs from a rollup in where transaction data lives.

Volition (Enhanced Validium)

The per-transaction choice model between rollup-style and validium-style data availability.

Where Lumia's transaction data lives

What holds the transaction data behind Lumia's validity proofs.

Why Lumia's data-availability choice matters

Why a dedicated DA network is a different cost and security trade than the alternatives.

How data-availability sampling scales

The data-availability sampling mechanism that lets a DA layer scale independently of a chain's execution throughput.