papers/lux-quasar-composition/sections/08-evaluation.tex

\section{Evaluation}
\label{sec:eval}

\subsection{Cert sizes}

Table~\ref{tab:cert-sizes} gives the measured cert sizes per
profile at the production parameter set ($n = 21$ validators,
Corona M=$8$ N=$7$ ring degree $256$ q=$2^{48}+0x4A01$ (Module-LWE, Ringtail params), Pulsar M-LWE
$N = 256$ q=$2^{48}+2561$, Magnetar SLH-DSA-SHAKE-192f).

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lrrrrrr@{}}
\toprule
\textbf{Profile} & \textbf{BLS} & \textbf{Pulsar} & \textbf{Corona} & \textbf{Magnetar} & \textbf{Groth16} & \textbf{Total} \\
\midrule
\texttt{Pulsar}  & 48 B  & 3{,}309 B & --- & --- & 192 B & ${\sim}3{,}549$ B \\
\texttt{Aurora}  & 48 B  & 3{,}309 B & 33{,}052 B & --- & 192 B & ${\sim}36{,}601$ B \\
\texttt{Polaris} & 48 B  & 3{,}309 B & 33{,}052 B & 16{,}224 B & 192 B & ${\sim}52{,}825$ B \\
\bottomrule
\end{tabular}
\caption{Cert size per profile at $n = 21$. Sizes are dominated by
the threshold-signature wire format on each leg. Native binary
encoding (\texttt{corona\_gob.go}) is $1.01\times$ gob; numbers
above are the native binary form (the canonical wire bytes).}
\label{tab:cert-sizes}
\end{table}

The Pulsar profile is bandwidth-efficient: $\sim 3.5$ KB per cert
is dominated by the Pulsar ML-DSA-65 signature ($\sim 93$ \% of
the cert). The Aurora profile is $\sim 10\times$ larger due to the
Corona threshold-signature wire format ($\sim 33$ KB). The
Polaris profile adds the Magnetar leg ($\sim 16$ KB).

\paragraph{Comparison with naive per-validator ML-DSA.}
A naive cert that includes per-validator ML-DSA-65 signatures (no
threshold combination, no Groth16 rollup) would carry $n \cdot
3{,}309 = 69{,}489$ bytes at $n = 21$, or $330{,}900$ bytes at
$n = 100$. The QuasarCert Pulsar profile is $19\times$ smaller at
$n = 21$ and $93\times$ smaller at $n = 100$, with no degradation
in PQ-security.

\subsection{Storage projections}

For a chain producing one block per 500 ms (the Lux Q-Chain target
block time), $86{,}400$ blocks/day. Table~\ref{tab:storage} gives
the storage growth per profile.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lrrr@{}}
\toprule
\textbf{Profile} & \textbf{Per 10K blocks} & \textbf{Per day} & \textbf{Per year} \\
\midrule
\texttt{Pulsar}  & 33.8 MB  & 292 MB  & 107 GB  \\
\texttt{Aurora}  & 349 MB   & 3.0 GB  & 1.1 TB  \\
\texttt{Polaris} & 503 MB   & 4.3 GB  & 1.6 TB  \\
\bottomrule
\end{tabular}
\caption{Storage projection per cert profile at one block per 500 ms.
The Pulsar profile sustains $\sim 100$ GB of cert storage per year;
the Aurora and Polaris profiles require $\sim 1$ TB/year. Archival
nodes hold these in full; light clients sync via Z-Chain epoch
proofs and store $\sim 10$ KB/year.}
\label{tab:storage}
\end{table}

For the Aurora / Polaris profiles, the cert storage cost is
non-trivial. Two amortizations apply.

\paragraph{Epoch-mode amortization.} In ``epoch mode'' the Corona
and Magnetar legs are signed once per epoch (over a Merkle root of
that epoch's block hashes), not per block. With epoch size $k =
1000$ blocks, the amortized Corona / Magnetar cost is $\sim 33$
B/block and $\sim 16$ B/block respectively, reducing the Aurora
profile to $\sim 3.6$ KB/block and Polaris to $\sim 3.6$ KB/block
plus a one-time epoch-end overhead.

\paragraph{Z-Chain Groth16 amortization.} The Z-Chain leg is
already amortized: one $192$-byte proof per window of $\sim 1024$
blocks. The per-block Z-Chain cost is therefore $\sim 0.2$ B/block,
negligible compared to the other legs.

\subsection{Verify times}

Table~\ref{tab:verify-times} gives measured CPU verify times on
Apple M1 Max (10 cores, darwin/arm64) from the
\texttt{luxfi/consensus} bench harness
\cite{consensusrepo}.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lrl@{}}
\toprule
\textbf{Operation} & \textbf{Time} & \textbf{Source} \\
\midrule
BLS single verify & 820 \textmu s & \texttt{crypto/bls BenchmarkVerify} \\
BLS aggregate verify (100 signers) & 875 \textmu s & \texttt{quasar BenchmarkBLSAggregatedVerification/100} \\
ML-DSA-65 verify (cold) & 254 \textmu s & \texttt{utxo/mldsafx BenchmarkMLDSA65Verify} \\
ML-DSA-65 verify (cached) & 3 \textmu s & \texttt{utxo/mldsafx BenchmarkMLDSA65VerifyCached} \\
SLH-DSA-192f verify & 1{,}920 \textmu s & \texttt{utxo/slhdsafx BenchmarkSLH192fVerify} \\
Groth16 verify (CPU) & 1--3 ms & not yet in bench harness \\
Pulsar threshold verify & $O(1)$ after DKG & amortized \\
Full QuasarCert verify (Pulsar profile) & 1.85 ms & \texttt{quasar BenchmarkQuasarBlockProcessing} \\
Full QuasarCert verify (Aurora profile, est.) & ${\sim}4$--$5$ ms & projection \\
Full QuasarCert verify (Polaris profile, est.) & ${\sim}6$--$8$ ms & projection \\
\bottomrule
\end{tabular}
\caption{Measured and projected QuasarCert verify times. The Pulsar
profile clears in 1.85 ms; Aurora and Polaris are correspondingly
larger due to the additional lattice and hash-based leg verifies.
GPU batch verification amortizes 10--100$\times$ across multiple
certs at $\geq 64$ signers.}
\label{tab:verify-times}
\end{table}

\paragraph{The 357 \textmu s legend.} Earlier Lux drafts
(\texttt{lux-triple-proof-consensus}, \texttt{lux-master-security-model})
quoted ``$357$ \textmu s epoch finality''. This number does not match any
measured operation in the current code. The closest real candidates
are BLS single keygen ($350$ \textmu s) and ML-DSA-65 sign ($495$
\textmu s); the actual QuasarCert verify on Pulsar profile is $1.85$ ms
CPU. Papers should quote the measured $2$--$5$ ms CPU QuasarCert
verify (or $\sim 0.5$--$1.5$ ms GPU batched), not the $357$ \textmu s
legend.

\subsection{Cert assembly latency}

The cert assembly latency is dominated by the slowest leg's signing
operation, because legs are signed in parallel. Table~\ref{tab:sign-times}
gives the measured per-leg signing times.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lr@{}}
\toprule
\textbf{Leg signing operation} & \textbf{Time (M1 Max)} \\
\midrule
BLS single sign & 350 \textmu s \\
BLS aggregate (100 sigs) & 5.3 ms \\
ML-DSA-65 sign & 495 \textmu s \\
Pulsar Round 1 (precomputation) & ${\sim}50$ ms per validator \\
Pulsar Round 2 (response) & ${\sim}30$ ms per validator \\
Pulsar combine ($n = 21$) & ${\sim}40$ ms \\
Corona Round 1 + Round 2 + combine & ${\sim}50$--$100$ ms \\
Magnetar reveal + sign + zeroize & ${\sim}5$--$10$ ms (SLH-DSA-192f sign $1.92$ ms verify) \\
Groth16 prove (CPU) & ${\sim}400$ ms per ML-DSA verification \\
Groth16 prove (GPU batched) & ${\sim}5$--$15$ ms amortized \\
\bottomrule
\end{tabular}
\caption{Per-leg signing times. The cert assembly latency is
dominated by the Pulsar / Corona threshold-combine step
($\sim 40$--$100$ ms), not the BLS aggregate or the FIPS 204
single-party sign.}
\label{tab:sign-times}
\end{table}

The Lux Q-Chain target block time is $500$ ms. The Pulsar-profile
cert assembly fits well within this budget ($\sim 90$ ms wall-clock
across signing and verify). The Aurora-profile cert assembly is
$\sim 200$ ms; Polaris is $\sim 250$ ms. All profiles fit within
the $500$ ms block-time budget with significant headroom.

\subsection{Throughput at scale}

The ZAP wire protocol \cite{lp020} sustains $\geq 100$K TPS per
chain on Lux production hardware (\texttt{luxfi/consensus/bench}
measurements; $11.5$M TPS in optimal end-to-end conditions on
$50$-connection batching). The cert assembly cost is amortized
across the block payload, not per-transaction; a $500$ ms block
with $50{,}000$ transactions has a per-tx overhead of
$\sim 90$ \textmu s for the Pulsar profile.

\subsection{GPU dispatch impact}

GPU batch verification ($\geq 64$ signers / signatures) provides:

\begin{itemize}[leftmargin=2em,nosep]
\item BLS aggregate verify: $\sim 875$ \textmu s CPU
      $\rightarrow$ $\sim 40$ \textmu s GPU (M2 Pro), $20\times$ speedup.
\item ML-DSA-65 verify: $\sim 254$ \textmu s CPU
      $\rightarrow$ $\sim 20$ \textmu s GPU, $10\times$ speedup.
\item Groth16 verify: $\sim 1$--$3$ ms CPU
      $\rightarrow$ $\sim 200$--$500$ \textmu s GPU, $5$--$10\times$ speedup.
\end{itemize}

For a validator catching up after downtime, GPU batch verify
amortizes the entire cert-history replay cost. At $20\times$
speedup over CPU, a year of Pulsar-profile certs ($\sim 63$M
certs) verifies in $\sim 30$ minutes GPU vs.~$\sim 10$ hours CPU.

The break-even for GPU dispatch is $\sim 64$ signers / signatures,
because of the $\sim 100$ \textmu s Metal/CUDA dispatch overhead.
Below this threshold, the CPU path is faster.

\subsection{Comparison with naive PQ designs}

Table~\ref{tab:comparison} compares QuasarCert with two naive
alternatives.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lrrr@{}}
\toprule
\textbf{Design} & \textbf{Cert size} & \textbf{Verify time} & \textbf{PQ security} \\
\midrule
BLS-only (legacy) & 48 B & 875 \textmu s & none \\
Per-validator ML-DSA & 69 KB & 5.3 ms & yes \\
QuasarCert Pulsar profile & 3.5 KB & 1.85 ms & yes \\
QuasarCert Aurora profile & 37 KB & ${\sim}4$--$5$ ms & yes (intra-lattice) \\
QuasarCert Polaris profile & 53 KB & ${\sim}6$--$8$ ms & yes (cross-family) \\
\bottomrule
\end{tabular}
\caption{QuasarCert vs. naive PQ designs at $n = 21$. The Pulsar
profile is $20\times$ smaller and $3\times$ faster to verify than
per-validator ML-DSA, with the same EUF-CMA bound. The
intra-lattice and cross-family profiles trade size for additional
hardness diversification.}
\label{tab:comparison}
\end{table}