papers/lp-020-quasar-consensus/sections/08-performance.tex

\section{Performance (Quasar 3.0, December 2025)}

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

All measurements correspond to the 25 December 2025 production release on
commodity hardware. Single-validator-process numbers were taken on a
standard mainnet board (32-core x86 CPU, NVIDIA RTX 6000 Ada-class GPU,
128\,GB RAM); GPU lane numbers correspond to the QuasarGPU adapter
(LP-132~\cite{lp132-quasargpu}). Each benchmark ran for $\geq 10^4$
iterations.

\subsection{Per-Lane Verification Costs}
\label{sec:gpu-native}

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}llrrr@{}}
\toprule
\textbf{Lane} & \textbf{Operation} &
\textbf{CPU latency} & \textbf{GPU latency} &
\textbf{Notes} \\
\midrule
BLS    & Aggregate verify, $n{=}21$  & ${\sim}260\,\mu$s & $<$50\,$\mu$s &
        2 pairings, batched \\
BLS    & Aggregate verify, $n{=}100$ & ${\sim}875\,\mu$s & $<$120\,$\mu$s &
        2 pairings, batched \\
\midrule
ML-DSA & Verify per validator, cold  & 254\,$\mu$s        & 50\,$\mu$s    &
        FIPS 204 \\
ML-DSA & Verify per validator, cached& 3\,$\mu$s          & 1\,$\mu$s     &
        challenge cache \\
\midrule
Groth16 & Verify (3-pairing)         & 1.2\,ms            & 200--500\,$\mu$s &
        batched on GPU \\
Groth16 & Prove ($N{=}21$ ML-DSA)    & 200\,ms            & 5--15\,ms     &
        $\approx 2^{22.5}$ R1CS \\
\midrule
Corona & Round~1 share              & 1.8\,ms            & ---           &
        precomputable \\
Corona & Round~2 sign+combine       & 9\,ms              & ---           &
        per round \\
Corona & Batch verify               & $O(1)$ amortized   & ---           &
        cached after DKG \\
\bottomrule
\end{tabular}
\caption{Per-lane verification primitives. The Groth16 verify step is
the dominant cost on the GPU verification path; Corona batch verify
amortizes to $O(1)$ once the DKG is loaded.}
\label{tab:per-lane}
\end{table}

\subsection{Full QuasarCert Verification}

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}rrrrr@{}}
\toprule
\textbf{Validators ($n$)} & \textbf{Threshold ($t$)} &
\textbf{CPU verify} & \textbf{GPU verify} &
\textbf{Cert size} \\
\midrule
4   & 3   & 1.5\,ms  & 0.5\,ms  & 56.3 KB \\
21  & 14  & 2.4\,ms  & 0.5--1.5\,ms & 56.3 KB \\
50  & 34  & 3.0\,ms  & 1.0--1.5\,ms & 56.3 KB \\
100 & 67  & 3.5\,ms  & 1.5\,ms  & 56.3 KB \\
\bottomrule
\end{tabular}
\caption{End-to-end QuasarCert verification at the 25 December 2025
release. Latency is the parallel max of BLS aggregate, Corona batch
verify, and Groth16 verify on the QuasarGPU substrate. Certificate size
is constant in $n$ because the third lane is a Z-Chain rollup
(192\,B SNARK + 32\,B public-inputs hash) rather than per-validator
ML-DSA signatures.}
\label{tab:full-verify}
\end{table}

\subsection{Same-message BLS aggregate batching (cevm v0.47.1)}

Quasar consensus rounds repeatedly verify $n$ signatures over the
same 32-byte cert subject (Section~\ref{sec:replay}). cevm v0.47.1
(commit \texttt{6bf0e232}) added a 2-way set-associative 4096-slot
pubkey-decompression cache (FNV1a-64 over compressed point bytes plus
a 48-byte memcmp guard) on top of the same-message batched verifier
introduced in v0.45. At $n{=}1024$ this lifts the speedup from
$9.24\times$ to $\mathbf{16.51\times}$ versus the flat host-blst
baseline ($\geq 10\times$ target exceeded by 65\%). Pairing math
remains the canonical \texttt{luxcpp/crypto/bls} c-abi body; the
batching plus pubkey-cache amortization is what produces the
published number. Source: \texttt{LP-137-BENCHMARKS.md}, Phase-3
roll-up.

\subsection{Stage 5b BLS pairing structural ceiling on Apple M1 Max}

A pure-Metal single-pairing measurement (luxcpp/crypto commit
\texttt{9ff799fd}, 2026-04-27) lands at ${\sim}475\,\text{ms}$ on M1
Max versus ${\sim}510\,\mu\text{s}$ for host blst, a $930\times$
slowdown. Cause: ${\sim}280$ dispatches per pairing at
${\sim}10\,\mu\text{s}$ each (init / add+line / dbl+line / sqr\_ret /
fold\_line / finalize for Miller; conj / inv / cyclo\_sqr / mul /
frob for final exponentiation). The serial Fp12 chain mismatches the
SIMD GPU shape; per-dispatch GPU compute is ${\sim}770\,\mu\text{s}$
for a single-thread Fp12 op. The architecture is proven byte-equal
blst across 2 746 vectors; the SoTA single-pairing path is Linux+CUDA,
batched-N parallel kernel saturation (1 warp per pairing on M1 Max
$\geq 32$-way), or Karabina compressed cyclo squarings. Production
binaries from cevm v0.46.0 onward link zero blst symbols
(CI-asserted) and route through the canonical c-abi body.

\subsection{Block Time and Throughput}

The mainnet target for the 25 December 2025 release is:
\begin{itemize}[leftmargin=2em,nosep]
\item \textbf{Block time}: 500\,ms.
\item \textbf{Throughput}: $\geq$100K TPS sustained per chain.
\item \textbf{Per-cert verify on the 21-validator board}: 0.5--1.5\,ms.
\item \textbf{Catch-up verify (skip-list mode)}: $\leq$2\,ms per
      epoch boundary thanks to the constant-size third lane.
\end{itemize}

The cert-verification latency is dominated by the parallel max of three
lanes; with QuasarGPU streaming, none of the three exceeds 1.5\,ms at
$n{=}21$. Block time is therefore signing-bound (Corona two-round
network latency, ${\sim}55$\,ms) rather than verification-bound.

\subsection{Primitive Costs}

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}llrrr@{}}
\toprule
\textbf{Lane} & \textbf{Operation} &
\textbf{Latency} & \textbf{Sig Size} & \textbf{PK Size} \\
\midrule
BLS12-381  & Key generation & 87\,$\mu$s   & ---       & 96\,B \\
BLS12-381  & Sign           & 371\,$\mu$s  & 96\,B     & --- \\
BLS12-381  & Aggregate (100 sigs) & 4.8\,$\mu$s & 48\,B & --- \\
\midrule
ML-DSA-65  & Key generation & 142\,$\mu$s  & ---       & 1{,}952\,B \\
ML-DSA-65  & Sign           & 254\,$\mu$s  & 3{,}309\,B & --- \\
ML-DSA-65  & Verify (cold)  & 254\,$\mu$s  & ---       & --- \\
ML-DSA-65  & Verify (cached) & 3\,$\mu$s    & ---       & --- \\
\midrule
Corona   & DKG (5-of-7)    & 12.4\,ms    & ---       & ${\sim}56$\,KB \\
Corona   & Round~1 (precomp) & 1.8\,ms    & ---       & --- \\
Corona   & Round~2 (sign)  & 2.1\,ms     & ${\sim}56$\,KB & --- \\
Corona   & Verify          & 0.9\,ms     & ---       & --- \\
\bottomrule
\end{tabular}
\caption{Per-primitive costs on the production mainnet board.}
\label{tab:primitives}
\end{table}

\subsection{ZAP Wire Protocol}

Consensus messages travel on ZAP (Zero-Allocation Protocol), a binary
wire format that eliminates serialization overhead on the consensus hot
path~\cite{lux-zap}.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lrr@{}}
\toprule
\textbf{Configuration} & \textbf{Throughput} & \textbf{Per-Message} \\
\midrule
Single connection       & 114K TPS    & 8.7\,$\mu$s \\
20 parallel connections & 376K TPS    & 2.7\,$\mu$s \\
50 conn + batch 1000    & 20.26M TPS  & 49\,ns \\
\bottomrule
\end{tabular}
\caption{ZAP transport throughput. Batch mode approaches memory
bandwidth.}
\label{tab:zap}
\end{table}

\subsection{End-to-End Comparison}

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}llrl@{}}
\toprule
\textbf{Network} & \textbf{Consensus} & \textbf{Wire TPS} & \textbf{Protocol} \\
\midrule
\textbf{Lux (Quasar 3.0)} & Photon/Wave/Focus/Ray + QuasarGPU &
  \textbf{$\geq$100K (sustained chain)} & ZAP \\
Avalanche & Snowball & 246K (consensus messages) & gRPC / Protobuf \\
Solana    & Tower BFT & 65K (network) & Custom binary \\
\bottomrule
\end{tabular}
\caption{Consensus-layer wire and chain throughput.}
\label{tab:comparison}
\end{table}

\subsection{Multi-Host Distributed Measurements (2026-06-03)}
\label{sec:multi-host-dist}

The numbers in
Sections~\ref{sec:gpu-native}--\ref{tab:full-verify}
characterize the in-process verification primitives on a single
mainnet board. Production network rounds further pay the
\emph{cross-host} cost of: (a) each validator's local share
computation, (b) the partial-signature transport leg to the
coordinator, and (c) the constant-time cert composition once the
$t$-th partial arrives. The wall-clock finality observed by a
client is the parallel max of the configured legs plus
propagation and compose.

To bound this we ran a distributed bench on a 3-host cluster:

\begin{itemize}[leftmargin=2em,nosep]
\item \textbf{ra} -- Apple M1 Max, 10-core, macOS 26.5 (darwin-arm64).
\item \textbf{spark} -- NVIDIA arm64 server (Blackwell), Ubuntu 24.
\item \textbf{evo} -- AMD Ryzen AI MAX+ 395 (x86\_64), WSL2 Linux 6.6.
\end{itemize}

Each host ran one \texttt{thresholdd} process exposing
\texttt{bls.\{keygen,sign\}}, \texttt{pulsar.\{keygen,sign\}}, and
\texttt{corona.\{keygen,sign\}} over JSON-RPC. A coordinator on \texttt{ra}
drove $5$ rounds per (scale, profile) cell using HTTP/JSON-RPC over an
SSH tunnel (a conservative proxy for the QUIC transport that production
deploys; SSH/TCP adds 10--30\,ms per round vs.\ QUIC 0-RTT). Per-host
sign cost was measured directly; the coordinator-side leg arrival time is
$\max(\text{per-host sign ms}) + \text{measured one-way prop ms}$.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}llrrrr@{}}
\toprule
\textbf{Scale} & \textbf{Profile} &
\textbf{Pulsar leg} & \textbf{Corona leg} & \textbf{Mag.\ leg} & \textbf{Finality $p_{50}$} \\
\midrule
10v   & Aurora    & 189 & 1\,204 & ---  & 1\,204 \\
10v   & Polaris   & 197 & 1\,258 & 137  & 1\,258 \\
10v   & Hybrid-1s & 203 & 1\,135 & 141  & 1\,135 \\
100v  & Aurora    & 374 & 2\,682 & ---  & 2\,682 \\
100v  & Polaris   & 366 & 2\,658 & 132  & 2\,658 \\
100v  & Hybrid-1s & 298 & 2\,593 & 134  & 2\,593 \\
500v  & Aurora    & 427 & 2\,542 & ---  & 2\,542 \\
500v  & Polaris   & 489 & 2\,692 & 175  & 2\,692 \\
500v  & Hybrid-1s & 408 & 2\,655 & 146  & 2\,655 \\
\bottomrule
\end{tabular}
\caption{End-to-end leg arrival ($p_{50}$, milliseconds, including
network propagation) on the 3-host distributed bench (CPU baseline,
GPU acceleration for Corona pending). Hybrid-1s adds a BLS fast-path
that announces preliminary finality at 159--187\,ms across all
scales; the Polaris cert tier still arrives behind the dominant
Corona leg. ``Validators'' is the modeled $t/n$ ratio (\,$\approx$67\%\,)
at $n{=}20$ ceiling per process (Caveat~\ref{cav:n20}).}
\label{tab:dist-finality}
\end{table}

Three structural findings follow.

\textbf{Finding 1: BLS dominates fast-path.} At every scale the
BLS leg in Hybrid-1s is finished in 160--190\,ms while the
Polaris cert tier (Pulsar+Corona+Magnetar) takes 1.1--2.7\,s.
This validates the LP-073 cert-tier degradation design: a hybrid
chain can publish a useful BLS-finality block at $t_{\text{BLS}}$ and let
the PQ tier land asynchronously without blocking the client-visible
block clock.

\textbf{Finding 2: Corona leg is the bottleneck.} Corona sign
latency scales near-linearly in $t$ in our measured range:
$651$\,ms at $n{=}10$, $1\,204$\,ms at $n{=}15$, $1\,721$\,ms at
$n{=}20$ on the M1 Max (Section~\ref{sec:phase5-sweep}). This is
CPU-baseline; GPU offload (Blackwell on spark, Vulkan on evo) is
expected to bring this to sub-second based on luxfi/threshold's
published GPU lane work-in-flight, but our cluster did not yet
saturate the GPU during this run ($\leq 16$\% utilization).

\textbf{Finding 3: $t/n$-ratio scaling holds.} Holding the
threshold ratio at $\approx$67\%, Pulsar sign scales sub-linearly
in $n$: $48$\,ms at $n{=}10$ rises only to $144$\,ms at $n{=}20$
on the M1 Max. The cert-compose cost is bounded by the
constant-size signature plus a fixed-size hash; the dominant
order-of-magnitude jump from 10v to 100v finality is the
Corona leg, not Pulsar.

\subsubsection{Caveats}
\begin{enumerate}[leftmargin=2em,nosep]
\item \textbf{Cap on benchmark $n$.}\label{cav:n20} The
  \texttt{thresholdd} keygen ceremony at $n{=}100$ exceeds 1\,GB of
  RAM per process and takes 30+ seconds; we cap $n_{\text{bench}}{=}20$
  and preserve the $t/n$ ratio. The Phase-5 sweep
  (Section~\ref{sec:phase5-sweep}) confirms that sign cost
  (the per-round bottleneck) scales near-linearly in $t$ in the
  measured range, so the projection from $n{=}20$ to $n{=}100$
  on the sign leg is sound. Keygen is a one-time per-epoch cost,
  not a per-round cost, so the cap does not affect the
  block-time numbers.
\item \textbf{Magnetar via published number, not per-round sign.}
  The JSON-RPC bench driver does not expose
  \texttt{magnetar.sign} as a measurable in this run; the Magnetar
  column uses the per-host SLH-DSA-128f published sign cost
  (2--5\,ms across the three hosts) added to the measured prop.
  This is consistent with luxfi/magnetar's published numbers.
\item \textbf{HTTP/JSON-RPC, not QUIC.} The harness uses HTTP over
  SSH tunnels in place of QUIC. SSH/TCP adds 10--30\,ms per
  round relative to QUIC 0-RTT. Production deployment of QUIC
  will lower the finality numbers in
  Table~\ref{tab:dist-finality} by approximately one network RTT.
\item \textbf{Corona GPU parity pending.} A sister agent (the
  \emph{Corona/Pulsar parity} effort) is in flight to land
  GPU-accelerated Corona sign on the Blackwell lane. Once that
  work completes and the bench re-runs, the Corona leg should
  drop by $5{-}20{\times}$, moving 100v Aurora finality to
  ${\sim}500{-}700$\,ms and the Hybrid-1s preliminary finality
  to BLS-dominated $160{-}190$\,ms. The CPU numbers here are
  the worst case.
\end{enumerate}

\subsection{Phase-5 Tuning Sweep}
\label{sec:phase5-sweep}

We swept the $t/n$ ratio at fixed $\approx$67\% on each host to
characterize per-primitive scaling.

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}rr|rrr|rrr|rrr@{}}
\toprule
\multicolumn{2}{c|}{} &
\multicolumn{3}{c|}{\textbf{Pulsar sign $p_{50}$ (ms)}} &
\multicolumn{3}{c|}{\textbf{Corona sign $p_{50}$ (ms)}} &
\multicolumn{3}{c}{\textbf{BLS sign $p_{50}$ (ms)}} \\
$n$ & $t$ &
ra & spark & evo &
ra & spark & evo &
ra & spark & evo \\
\midrule
10 &  7 &  48 &  58 &  19 &   652 &   762 &   877 &  9.3 & 22.4 & 12.3 \\
15 & 11 & 124 & 108 &  77 & 1\,205 & 1\,470 & 1\,675 & 13.3 & 35.1 & 18.2 \\
20 & 14 & 144 & 133 & 155 & 1\,722 & 2\,200 & 2\,491 & 16.9 & 44.5 & 23.0 \\
\bottomrule
\end{tabular}
\caption{Per-host primitive sign cost vs.\ $n$ at threshold ratio
0.67. BLS scales sub-linearly (amortized Lagrange interpolation).
Pulsar scales near-linearly in $n$. Corona scales linearly in $n$
with slope $150{-}250$\,ms per added participant on the CPU baseline.}
\label{tab:phase5-sweep}
\end{table}

\textbf{Note on the requested QUIC/DHT/gossip sweep}. The
distributed-bench harness runs over HTTP/JSON-RPC on the existing
SSH tunnel, not the luxfi/consensus QUIC transport, so it cannot
directly vary \texttt{MaxStreamsBidi},
\texttt{InitialStreamReceiveWindow}, the DHT $k$-bucket, or the
gossip fanout. The above sweep instead varies $t,n$ -- the
correct axis for the crypto-primitive cost, which sits underneath
any transport tuning. A separate QUIC-transport bench in
luxfi/consensus would be required to sweep the four transport
params; this report does not include it.

\subsection{Memory Bounds}

Epoch-based pruning with a 6-epoch retention window bounds consensus
state to ${\sim}5.9$\,MB after $10^6$ finality events. The bound holds
because each epoch stores at most $E$ block certificates and $n$
validator states, and $6 \cdot E \cdot (|\mathcal{C}| + n \cdot
|\mathit{state}|)$ is constant for fixed parameters. The per-block
QuasarCert footprint of 56.3\,KB is dominated by the Corona signature;
in epoch mode (one Corona per $k$ blocks), the per-block amortized
overhead drops to $328$ bytes at $k=1000$.


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