papers/lux-data-availability/sections/01-introduction.tex

\section{Introduction}

\label{sec:introduction}
%% ============================================================================

Data availability is the foundational liveness requirement of any blockchain that separates
execution from consensus. A block is \emph{data-available} if every honest participant can
reconstruct the full block data from the information published at consensus time. Without
this guarantee, an adversary can propose a block header that commits to invalid state
transitions while withholding the data needed for anyone to prove fraud~\cite{albassam2018fraud}.

Traditional monolithic blockchains ensure data availability trivially: every full node
downloads every block. This approach does not scale. As throughput targets increase from
tens to thousands of transactions per second, the bandwidth required of every full node
grows proportionally, centralizing the network among well-provisioned operators. The
\emph{data availability problem} asks whether there exists a mechanism allowing nodes with
limited bandwidth---\emph{light nodes}---to gain high confidence in data availability without
downloading the full data.

The insight behind \emph{data availability sampling} (DAS) is that erasure coding inflates
block data with redundancy, so that the entire block can be reconstructed from any sufficiently
large fraction of the coded data. Light nodes sample a small number of random chunks and
verify them against a succinct commitment embedded in the block header. If the block producer
has withheld too many chunks, with high probability at least one of the sampled positions
will be missing, and the light node will reject the block.

\subsection{Motivation within the Lux Ecosystem}

The Lux Network is a multi-chain platform in which application-specific blockchains---called
\emph{appchains}---share a common validator infrastructure via the Primary Network. Each appchain
may define its own virtual machine, state format, and transaction semantics, but all appchains
rely on the Primary Network for validator management and cross-chain messaging.

In this architecture, data availability acquires a multi-dimensional character. A appchain block
is relevant only to the subset of validators running that appchain's VM, yet cross-appchain
messages (via Lux Teleport, LP-6332, riding on Lux Warp 2.0) require that the \emph{source} data is available to the
\emph{destination} validators for fraud proofs or ZK verification. A naive solution---requiring
all validators to download all appchain data---collapses the scalability benefit of appchains.

Lux-DAS resolves this tension by providing a \emph{shared DA layer} that offers global
verifiability with local storage. Each appchain's data is erasure-coded and committed
independently; the commitments are aggregated into the Primary Network block header. Any
light client on any appchain can verify that any other appchain's data is available by sampling
from the shared commitment structure, without downloading the foreign appchain's data in full.

\subsection{Contributions}

\begin{enumerate}[leftmargin=*]
    \item We formalize the Lux-DAS protocol, specifying erasure coding parameters, commitment
          structure, sampling procedures, and reconstruction guarantees (\Cref{sec:protocol}).
    \item We prove that Lux-DAS achieves $(1 - 2^{-\lambda})$-confidence data availability for
          light clients sampling $s = \lambda / 2$ cells, and that an adversarial block producer
          cannot equivocate without detection by $O(k^2 / s)$ sampling nodes (\Cref{sec:security}).
    \item We introduce appchain-scoped commitment aggregation, reducing per-validator bandwidth
          proportional to the number of appchains (\Cref{sec:protocol:aggregation}).
    \item We present benchmark results from a Fuji testnet deployment, comparing against
          EIP-4844 and Celestia on throughput, latency, and proof size (\Cref{sec:evaluation}).
\end{enumerate}

\subsection{Paper Organization}

\Cref{sec:background} reviews erasure coding, polynomial commitments, and prior DAS
constructions. \Cref{sec:protocol} describes the Lux-DAS protocol in full detail.
\Cref{sec:security} provides formal security analysis. \Cref{sec:implementation} discusses
system architecture and engineering decisions. \Cref{sec:evaluation} presents empirical
results. \Cref{sec:related} compares Lux-DAS to related work. \Cref{sec:conclusion} concludes.


%% ============================================================================