Files
papers/lux-data-availability/sections/06-evaluation.tex
zeekay 4a753bb639 papers: reorganize into per-paper dirs, add Antje Worring as co-author
Restructured from flat .tex/.pdf files into per-paper subdirectories.
Added Antje Worring as co-author on all papers.
Synced PDFs to pdfs/ for download site.
2026-04-18 21:50:07 -07:00

129 lines
4.4 KiB
TeX

\section{Evaluation}
\label{sec:evaluation}
%% ============================================================================
\subsection{Experimental Setup}
We deploy Lux-DAS on a 200-validator Fuji testnet with 16 appchains. Each appchain produces
blobs at a configurable rate. Validators run on AWS \texttt{c6g.xlarge} instances (4 vCPU
ARM Graviton2, 8 GiB RAM, 10 Gbps network). Light clients run on \texttt{t4g.micro} instances
(2 vCPU, 1 GiB RAM) to simulate resource-constrained devices.
\subsection{Throughput}
\begin{table}[H]
\centering
\caption{Blob throughput across configurations}
\label{tab:throughput}
\begin{tabular}{lrrr}
\toprule
\textbf{Configuration} & \textbf{Blobs/slot} & \textbf{Data/slot (MiB)} & \textbf{DA Overhead (\%)} \\
\midrule
$k=32$, 1 appchain & 64 & 1.9 & 4.2 \\
$k=64$, 1 appchain & 128 & 15.5 & 3.1 \\
$k=64$, 16 appchains & 128 $\times$ 16 & 248 & 2.8 \\
$k=128$, 1 appchain & 64 & 31.0 & 2.5 \\
\bottomrule
\end{tabular}
\end{table}
The DA overhead measures the ratio of commitment and proof data to raw blob data. As $k$
increases, the overhead decreases because commitment size grows as $O(k)$ while blob size
grows as $O(k^2)$.
\subsection{Light Client Verification Latency}
\begin{table}[H]
\centering
\caption{Light client DAS latency (ms) by sample count $s$}
\label{tab:light-client-latency}
\begin{tabular}{lrrrr}
\toprule
\textbf{$s$} & \textbf{p50 (ms)} & \textbf{p95 (ms)} & \textbf{p99 (ms)} & \textbf{Security bits} \\
\midrule
16 & 11 & 28 & 45 & 6.6 \\
32 & 21 & 48 & 72 & 13.2 \\
75 & 42 & 89 & 131 & 30.9 \\
150 & 78 & 165 & 240 & 61.8 \\
\bottomrule
\end{tabular}
\end{table}
Latency scales linearly with $s$ because samples are issued in parallel and latency is
dominated by the slowest responding full node.
\subsection{Comparison with EIP-4844 and Celestia}
\begin{table}[H]
\centering
\caption{Comparison of DAS systems}
\label{tab:comparison}
\begin{tabular}{lrrr}
\toprule
\textbf{Metric} & \textbf{Lux-DAS} & \textbf{EIP-4844} & \textbf{Celestia} \\
\midrule
Commitment type & KZG & KZG & NMT (Merkle) \\
Proof size per cell (bytes) & 96 & 48\footnotemark & 512--1{,}024 \\
Trusted setup & Yes (shared) & Yes & No \\
Multi-chain DA & Native & No & Namespace-based \\
Amortized verify cost ($m$ blobs) & $O(m)$ scalars + 2 pairings & $2m$ pairings & $O(m \log n)$ hashes \\
Blob throughput (MiB/slot) & 248 (16 appchains) & 0.75 & 8.0 \\
Light client latency (ms, $s=75$) & 42 & N/A\footnotemark & 180 \\
\bottomrule
\end{tabular}
\end{table}
\addtocounter{footnote}{-1}
\footnotetext{EIP-4844 uses single-dimensional KZG, so proofs are one group element.}
\stepcounter{footnote}
\footnotetext{EIP-4844 does not implement DAS; light clients must trust full nodes or use
the beacon chain attestation for DA.}
Lux-DAS achieves higher throughput than Celestia primarily because KZG proofs are constant-size
(two group elements per cell), whereas NMT Merkle proofs grow logarithmically. The amortized
verification advantage from \Cref{prop:batched-verification} further improves the gap when
verifying cells across multiple appchains in the same slot.
\subsection{Bandwidth Analysis}
\begin{table}[H]
\centering
\caption{Per-validator bandwidth (Mbps) by number of appchains validated}
\label{tab:bandwidth}
\begin{tabular}{lrrrr}
\toprule
\textbf{Appchains validated} & 1 & 4 & 8 & 16 \\
\midrule
Without aggregation & 2.1 & 8.4 & 16.8 & 33.6 \\
With aggregation & 2.1 & 3.2 & 4.1 & 5.3 \\
Reduction factor & 1.0$\times$ & 2.6$\times$ & 4.1$\times$ & 6.3$\times$ \\
\bottomrule
\end{tabular}
\end{table}
Appchain-scoped aggregation provides near-logarithmic bandwidth scaling with the number of
appchains, because validators only download full data for their assigned appchains and compact
Merkle proofs for cross-appchain DA verification.
\subsection{Fault Injection Experiments}
To validate the security analysis, we inject faults by having a fraction $\alpha$ of
validators withhold cells selectively.
\begin{table}[H]
\centering
\caption{Detection rate vs.\ withholding fraction ($s = 75$, $L = 50$ light clients)}
\label{tab:fault-injection}
\begin{tabular}{lrrrr}
\toprule
\textbf{Withholding $\alpha$} & 0.10 & 0.25 & 0.50 & 0.75 \\
\midrule
Detection rate (1 client) & 0.54 & 0.89 & 0.999 & $>0.9999$ \\
Detection rate ($L=50$) & $>0.9999$ & $>0.9999$ & $>0.9999$ & $>0.9999$ \\
\bottomrule
\end{tabular}
\end{table}
%% ============================================================================