Files
zeekayandHanzo Dev 178febad68 papers: reconcile T-Chain -> M-Chain / F-Chain / B-Chain per LP-134
Every rendered "T-Chain" / "ThresholdVM" / "teleportvm" reference across
the paper corpus is rewritten to the correct canonical chain by concern:
threshold signing / MPC / bridge custody / key recovery -> M-Chain (MVM);
FHE / encrypted compute / threshold decryption -> F-Chain (FVM); teleport
/ cross-chain messaging -> B-Chain (bridgevm); consensus Pulsar stays
Q-Chain. Section lux-trust-kernel/03-t-chain-threshold-governance.tex
renamed -> 03-f-chain-encrypted-policy.tex (with \input + xref fixes).
Braided "T-Chain" sections split by concern (M vs F). Only lp-020's
chain-separation rationale and the shared lux/chains/thresholdvm library
path retain the name, to record the removal. All changed papers rebuilt
(pdflatex, rc=0, no undefined refs).

ยง09 of lux-dao-governance-framework reframed: fabricated "production
deployment" metrics ($50M/$240k/$12M, survey %s, "as of Oct 2024")
relabeled as illustrative design configurations with no invented
replacements; reality noted (DAO treasury is a 1/1 Safe); conclusion
echo + one "first production" overclaim softened.

This commit also captures concurrent corpus workstreams on the same tree.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-02 00:57:09 -07:00

129 lines
4.4 KiB
TeX

\section{Evaluation}
\label{sec:evaluation}
%% ============================================================================
\subsection{Experimental Setup}
We deploy Lux-DAS on a 200-validator Lux 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}
%% ============================================================================