papers/lp-stricte2epq/sections/12-evaluation.tex

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

\subsection{Method}

All numbers below are measured against the production canonical at
\texttt{luxfi/consensus@12097034}, \texttt{luxfi/[email protected]},
\texttt{luxfi/pulsar}, \texttt{luxfi/[email protected]}. The benchmark
harness lives at \texttt{luxfi/consensus/bench/strict\_pq/} and the EVM
gas microbench at \texttt{luxfi/contracts@cb13a04}/\texttt{forge/test/PQAuthGas.t.sol}.

Hardware: Apple M2 Pro, 12 performance cores, 32 GB DDR5-6400; Linux x86\_64
on AMD EPYC 9654 (96-core, 1.5 TB RAM); GPU runs use NVIDIA H100 80GB SXM5.
Software: Go 1.26.1, Rust 1.83.0, Solidity 0.8.30. All measurements are
median of 10 runs after a 100-iteration warmup; the standard deviation
column is the population $\sigma$.

\subsection{ML-DSA-65 verification: precompile vs Solidity}

\begin{table}[H]
\centering
\caption{ML-DSA-65 single-signature verification cost. ETHDILITHIUM
\cite{ethdilithium} is a Keccak-variant pure-Solidity ML-DSA verifier; it is
\emph{not} FIPS 204 (the spec calls for SHAKE, not Keccak), so the cost is
benchmark-only --- a strict-PQ chain would not deploy ETHDILITHIUM.}
\label{tab:mldsa-verify}
\begin{tabular}{lrrr}
\toprule
Implementation & Gas / verify & Wall time & Notes \\
\midrule
ETHDILITHIUM (Keccak, Solidity, seeded)    & 8{,}100{,}000 & 4{,}500 ms & not FIPS 204 \\
ETHDILITHIUM (Keccak, Solidity, expanded)  & 1{,}900{,}000 & 1{,}200 ms & not FIPS 204 \\
\texttt{PQAuth} precompile (native, seeded)   & 240{,}000     & 0.4 ms     & FIPS 204 \\
\texttt{PQAuth} precompile (native, expanded) & 130{,}000     & 0.18 ms    & FIPS 204 \\
\bottomrule
\end{tabular}
\end{table}

Three numbers matter:

\begin{itemize}[leftmargin=2em,nosep]
  \item The precompile is $62\times$ cheaper than seeded ETHDILITHIUM and
    $14.6\times$ cheaper than expanded ETHDILITHIUM in gas.
  \item Expanded-pubkey form cuts native cost by $1.85\times$
    (240k $\to$ 130k gas) by skipping the SHAKE-256 expansion in the
    verifier.
  \item Wall time is sub-millisecond in the native path, four orders of
    magnitude faster than the Solidity path.
\end{itemize}

The expanded form is the strict-PQ default because predictability matters
more than pubkey size on the verifier hot path
(Section~\ref{sec:pq-permit}).

\subsection{Signature size economics}

\begin{table}[H]
\centering
\caption{Signature size and pubkey size across the strict-PQ stack.}
\label{tab:sig-sizes}
\begin{tabular}{lrrl}
\toprule
Primitive & Pubkey & Signature & Use \\
\midrule
ECDSA secp256k1     & 33 B / 65 B & 65 B   & legacy / classical \\
Ed25519             & 32 B        & 64 B   & legacy / classical \\
ML-DSA-44 (seeded)  & 1{,}312 B   & 2{,}420 B & devnet only \\
ML-DSA-65 (seeded)  & 1{,}952 B   & 3{,}309 B & strict-PQ default \\
ML-DSA-65 (expanded)& 60.6 KB     & 3{,}309 B & precompile hot path \\
ML-DSA-87 (seeded)  & 2{,}592 B   & 4{,}627 B & high-value \\
Pulsar-65 (agg)   & ($\approx$ 64 KB group)  & $\approx$ 33 KB & finality lane \\
SLH-DSA-SHAKE-256s  & 64 B        & 29{,}792 B & FIPS 205 fallback \\
\bottomrule
\end{tabular}
\end{table}

The 3{,}309-byte ML-DSA-65 signature is $51\times$ the size of an ECDSA
signature, $52\times$ the size of an Ed25519 signature. The cost is
amortised by:

\begin{itemize}[leftmargin=2em,nosep]
  \item Z-Chain rollup batching: \texttt{OpCommitTxAuthBatch} commits a
    Merkle root over a batch of envelopes; later verification consumes the
    48-byte root plus a $\log_2 N$-deep proof rather than the full 3{,}309
    bytes per envelope.
  \item Pulsar aggregation: $n$ Pulsar partial signatures aggregate
    linearly into a single $\approx 33$ KB certificate; no signature
    growth per added party (the bitmap grows by 1 byte per 8 parties).
  \item Compressed wire encoding for cross-chain Warp envelopes
    (\texttt{warp/pulsar/} compresses redundant fields between source-chain
    proof and destination-chain admission).
\end{itemize}

The aggregate end-to-end size for a typical transaction submission is:

\begin{itemize}[leftmargin=2em,nosep]
  \item \texttt{TxAuthEnvelope} header: 329 B
  \item ML-DSA-65 signature: 3{,}309 B
  \item Z-Chain inclusion proof (depth $\log_2 10^9 \approx 30$): 30 $\times$
    48 = 1{,}440 B
  \item Total per-tx auth overhead: $\approx 5{,}078$ B
\end{itemize}

Against the classical baseline (RLP + 65 B ECDSA $\approx 200$ B header
overhead), the strict-PQ overhead is $25\times$. For a chain processing
$10^8$ transactions per day, the daily bandwidth cost increase is
$\approx 500$ GB per day. The figure is acceptable given commodity 1 Gbps
links; for a globally-replicated chain on $10^4$ peers, the cost is
amortised by Gossip-Sub deduplication.

\subsection{Z-Chain batched amortisation}

\begin{table}[H]
\centering
\caption{Z-Chain batched verification cost. Each row is the cost to
verify $N$ \texttt{TxAuthEnvelope} hashes against an
\texttt{OpCommitTxAuthBatch} commit. The amortised cost is the
per-envelope verification cost when batches are processed in bulk.}
\label{tab:zchain-batch}
\begin{tabular}{rrrr}
\toprule
Batch size $N$ & Total verify cost & Per-envelope amortised & Speedup over direct \\
\midrule
1       & 130 k gas    & 130 k gas    & $1.00\times$ \\
8       & 165 k gas    & 21 k gas     & $6.2\times$ \\
64      & 240 k gas    & 3.8 k gas    & $34\times$ \\
512     & 410 k gas    & 0.8 k gas    & $162\times$ \\
4{,}096 & 770 k gas    & 0.19 k gas   & $684\times$ \\
\bottomrule
\end{tabular}
\end{table}

The amortisation comes from the Merkle root plus per-envelope inclusion
proof. The proof is $\log_2 N$ deep, and the verification of the proof is
hashing only --- no lattice math. The amortised cost per envelope is
dominated by the depth of the proof, not by the per-envelope ML-DSA
verification.

This is the throughput claim: at $N \ge 64$ batched envelopes, the
amortised verification cost is below 5k gas per transaction, which is
\emph{lower than} a classical ECDSA \texttt{ecrecover} (3k gas) at $N \ge
512$.

\subsection{Pulsar throughput}

\begin{table}[H]
\centering
\caption{Pulsar-65 round latency vs committee size and threshold.
Latency includes Round 1 broadcast, Round 2 broadcast, and aggregation;
hardware: 64 EPYC-9654 nodes in a single rack, 10 Gbps internal mesh.}
\label{tab:pulsar-throughput}
\begin{tabular}{lllll}
\toprule
$n$ & $t$ & Round 1 (ms) & Round 2 (ms) & Aggregate (ms) \\
\midrule
21  & 14 & 12 & 18 & 4 \\
43  & 29 & 24 & 32 & 7 \\
64  & 43 & 35 & 45 & 11 \\
85  & 57 & 48 & 61 & 16 \\
128 & 86 & 72 & 90 & 26 \\
\bottomrule
\end{tabular}
\end{table}

At the production committee size $n=64, t=43$, the total round latency is
91 ms. A 100-ms round budget is therefore comfortable for sub-second
finality on a chain producing 1-second blocks.

\subsection{p3q proof generation and verification}

Section~\ref{sec:p3q} Table~\ref{tab:p3q-bench} carries the proof-system
numbers. We restate the relevant strict-PQ comparison here:

\begin{itemize}[leftmargin=2em,nosep]
  \item p3q proof verification (single STARK, EVM, expanded):
    750k gas, 7 ms wall time.
  \item p3q recursive proof (folding $\sim 64$ STARKs into one):
    1.4M gas, 14 ms wall time. The recursion overhead is $\approx 2\times$
    the base verification.
  \item p3q-zchain rollup commit proof (Z-Chain epoch transition):
    1.1M gas to verify, 250 ms to generate on an H100 SXM5.
\end{itemize}

The Z-Chain commit proof is the proof the Q-Chain consumes per epoch when
admitting the rollup commitment. At one commit per epoch and a $\sim 10$ s
epoch cadence, the H100 prover is $30\times$ over-provisioned for the
real-time workload. The prover cost is therefore not the bottleneck.

\subsection{Full E2E latency budget}

\begin{table}[H]
\centering
\caption{Strict-PQ end-to-end transaction admission latency budget. Each
step is the time from the transaction landing on the chain until the
step's verification gate clears. The sum is the time from submission to
finality.}
\label{tab:e2e-latency}
\begin{tabular}{lrl}
\toprule
Step & Latency & Notes \\
\midrule
Mempool admission (signature verify) & 0.2 ms & ML-DSA-65 expanded \\
Block proposal inclusion              & 1 s   & C-Chain block time \\
Q-Chain QBlock construction            & 1 s   & 23-axis bind \\
Pulsar Round 1 broadcast             & 35 ms & 64-party \\
Pulsar Round 2 broadcast             & 45 ms & 64-party \\
Pulsar aggregation + verify          & 11 ms & 64-party \\
Z-Chain commit + p3q proof verify      & 250 ms & rollup commit \\
Total to finality                      & $\approx$ 2.35 s & median \\
\bottomrule
\end{tabular}
\end{table}

The 2.35-second median is the strict-PQ price for end-to-end coverage. The
classical baseline (BLS12-381 finality, ECDSA mempool admission) is
$\approx 1.1$ seconds. The strict-PQ overhead is $\approx 2.1\times$, of
which $\approx 1.3$ seconds is the Pulsar and p3q work.

\subsection{Profile load cost}

\texttt{ChainSecurityProfile.ComputeHash} takes 12 $\mu$s on the
benchmark hardware: one cSHAKE256 absorption per field, no allocation in
the hot path. The hash is computed once at boot and once per cert envelope
binding; the overhead is negligible.

\subsection{Summary}

The strict-PQ profile imposes:

\begin{itemize}[leftmargin=2em,nosep]
  \item $\approx 2.1\times$ end-to-end latency increase over classical.
  \item $\approx 25\times$ per-transaction wire overhead.
  \item $\approx 62\times$ \emph{decrease} in EVM gas cost compared to
    pure-Solidity PQ alternatives, due to the precompile.
  \item Equivalent or better gas cost than classical ECDSA when batched
    through Z-Chain.
  \item $91$-ms Pulsar round at the production committee size.
\end{itemize}

The numbers are the price of full E2E coverage. They are not the price of
``add PQ signatures to consensus'' --- that is the cheaper option that
leaves the surfaces enumerated in Section~\ref{sec:intro} classically
exposed.