Files
papers/lp-200-lux-vs-avalanche-diff/bench-table.tex
zeekay d43bd27971 docs(papers): ZAP stack + cert profile modes + pitch decks (LP-186..300)
Companion LaTeX papers to luxfi/LPs:
- lp-200-zap-stack: full ZAP-as-substrate paper (10-layer model, deco-
  mplected concerns, performance).
- lp-200-lux-vs-avalanche-diff: code-translation appendix.
- lp-203-gpu-native-verify, lp-205-pipelined-quasar, lp-208-dag-mempool,
  lp-209-mysticeti-ordering, lp-210-block-stm, lp-211-cross-shard-atomic,
  lp-217-cert-profile-modes, lp-218-zap-p3q-pq-rollup,
  lp-220-p3q-corona-magnetar, lp-221-stark-fri-verifier,
  lp-300-schema-registry.

Pitch / outreach decks (luxcover.sty templated):
- blackrock-nahmii-pitch, corporate-dao-stack-analysis,
  nahmii-patent-acquisition, pq-patent-family-future-infringers,
  lux-substrate-platform-pitch, w3a-foundation-membership,
  multi-validator-scale, vfs-archive-cost-study.

Edits aligning to LP-217 / LP-200:
- lp-020-quasar-consensus 02-system-model + 08-performance.
- lp-073-pulsar 11-quasar.
- lp-103-omnichain-explorer 03-chain-support.
- lp-104-graph-engine.
- lp-201-zap-universal-wire/wire-inventory.csv.
- lp-306-lx-social-dex sections/02.
- lux-adoption-roadmap, lux-chain-architecture,
  lux-consensus-engines/08-composition, lux-crypto-agility,
  lux-evm-precompile-engineering/02, lux-fhe-smart-contracts/05,
  lux-quasar-composition/04+06+10, lux-reproducible-builds.
- INDEX.md cross-links the new papers.
2026-06-10 22:35:37 -07:00

298 lines
14 KiB
TeX

% bench-table.tex — Measured performance numbers and competitor comparison
% All numbers sourced from existing Lux benchmarks. Sources cited in-line.
\section{Benchmarks: Measured and Derived}
\label{sec:benchmarks}
This section aggregates measured performance numbers from the Lux substrate.
All numbers below were collected on Apple M1 Max (10 cores, 64 GiB, macOS
Darwin 25.4, Go 1.26.x) unless otherwise noted. Sources are git-pinned
benchmark files in the Lux tree (e.g. \texttt{consensus/BENCHMARKS.md},
\texttt{pulsar/bench/results/REPORT.md},
\texttt{papers/lux-zap-benchmarks/}). Numbers reported as
``TBM'' (to be measured) indicate a Phase~2 deliverable not yet collected
on dedicated WAN hardware.
\subsection{Wire protocol: ZAP vs linearcodec, protobuf, FlatBuffers}
\begin{table}[h]
\centering
\small
\caption{ZAP-native P-chain transaction Parse speedup vs upstream
linearcodec, batch~5 v3.7 (refreshed 2026-06-02). Source:
\texttt{node/vms/platformvm/txs/bench\_results/RESULTS.md}.
Reproduction: \texttt{GOWORK=off go test -bench=BenchmarkParse\_
-benchmem -benchtime=2s -count=1 ./vms/platformvm/txs/zap\_native/}.
Lower ns/op is better. \textbf{Geometric mean across nine measurable tx
types: $7.50\times$ Parse, $3.57\times$ allocation reduction
(3--7 allocs/120--536\,B $\to$ 1 alloc/24\,B uniformly).} Build geomean
$1.03\times$, within v3.6 noise; $0.77$--$0.90\times$ dips on
\texttt{BaseTx} and \texttt{SetL1ValidatorWeightTx} are tracked as a
luxfi/zap v0.7.x follow-up (\texttt{Builder.SetU64} per-call dispatch
overhead, not a wire-layer regression).}
\label{tab:zap-pchain}
\begin{tabular}{lrrrrr}
\toprule
\textbf{Tx Type} & \textbf{Legacy ns/op} & \textbf{ZAP ns/op}
& \textbf{Speedup} & \textbf{Legacy allocs/B} & \textbf{ZAP allocs/B} \\
\midrule
RewardValidatorTx & 213.6 & 36.91 & 5.79$\times$ & 3/120 & 1/24 \\
SetL1ValidatorWeightTx & 423.4 & 52.30 & 8.10$\times$ & 3/136 & 1/24 \\
IncreaseL1ValidatorBalanceTx & 167.3 & 33.45 & 5.00$\times$ & 3/136 & 1/24 \\
DisableL1ValidatorTx & 177.9 & 27.09 & 6.57$\times$ & 3/120 & 1/24 \\
BaseTx & 334.3 & 49.67 & 6.73$\times$ & 3/152 & 1/24 \\
RegisterL1ValidatorTx & 765.1 & 50.98 & 15.01$\times$ & 6/384 & 1/24 \\
SlashValidatorTx & 356.8 & 45.35 & 7.87$\times$ & 4/176 & 1/24 \\
TransferChainOwnershipTx & 418.0 & 53.13 & 7.87$\times$ & 4/192 & 1/24 \\
RemoveChainValidatorTx & 343.3 & 44.01 & 7.80$\times$ & 4/176 & 1/24 \\
\midrule
\textbf{Geomean (n=9)} & & & \textbf{7.50$\times$} & & \\
\bottomrule
\end{tabular}
\end{table}
\noindent\textbf{Note on v3.6 vs v3.7.} The LP-023 Appendix~A table
reported a $8.5\times$ geomean on a slightly different harness (Go
$1.24$, prior schema). The v3.7 result above ($7.50\times$,
\texttt{luxfi/node} post-batch-5-v3.7,
\texttt{luxfi/zap} v0.7.2, Go $1.26.1$) is within $4\%$ of the v3.6
baseline ($7.74\times$) and is the canonical reference for citations
post-2026-06-02. The allocation profile is the more durable headline:
ZAP holds $1$~alloc/$24$~B \emph{uniformly} across every tx type
regardless of payload size, while linearcodec scales linearly with
field count ($3$--$7$ allocs / $120$--$384$~B). This is structurally
load-bearing: at $4\cdot 10^4$ Parse ops/s per validator on the Lux
1\,B-gas block, the GC pressure differential ($24$~B vs $384$~B
amortised per tx) is the single largest contributor to validator CPU
budget.
\begin{table}[h]
\centering
\small
\caption{Decode throughput of ZAP wire vs industry wire protocols on a
145-byte consensus vote payload. Source:
\texttt{papers/lux-zap-benchmarks/sections/03-serialization-throughput.tex}.}
\label{tab:zap-decode}
\begin{tabular}{lrrrr}
\toprule
\textbf{Protocol} & \textbf{ops/sec} & \textbf{ns/op}
& \textbf{allocs/op} & \textbf{B/op} \\
\midrule
\textbf{ZAP} & 156{,}000{,}000 & 6.4 & 0 & 0 \\
FlatBuffers & 142{,}000{,}000 & 7.0 & 0 & 0 \\
Cap'n Proto & 89{,}000{,}000 & 11.2 & 0 & 0 \\
gRPC (protobuf) & 14{,}200{,}000 & 70.4 & 3 & 192 \\
QUIC (raw) & 11{,}800{,}000 & 84.7 & 2 & 160 \\
Protobuf-mux & 10{,}100{,}000 & 99.0 & 5 & 320 \\
JSON-RPC & 1{,}180{,}000 & 847.5 & 28 & 2{,}048 \\
\bottomrule
\end{tabular}
\end{table}
\noindent\textbf{Headline:} ZAP decode is $11\times$ faster than protobuf
and $132\times$ faster than JSON-RPC with zero allocations on the
$145$-byte consensus-vote payload. The upstream Avalanche
\texttt{linearcodec} is closer to the protobuf row in shape
(reflection-based, $3+$ allocations); the per-tx batch-5-v3.7 geomean
$7.50\times$ Parse speedup vs upstream (Table~\ref{tab:zap-pchain}) is
consistent with this --- linearcodec spends most of its budget on
reflection dispatch and intermediate struct allocation, not on byte
movement.
\subsection{Consensus signing primitives (CPU baseline)}
\begin{table}[h]
\centering
\small
\caption{Cryptographic signing primitives, Apple M1 Max CPU path. Source:
\texttt{consensus/BENCHMARKS.md}.}
\label{tab:crypto-prims}
\begin{tabular}{lrrr}
\toprule
\textbf{Operation} & \textbf{KeyGen} & \textbf{Sign} & \textbf{Verify} \\
\midrule
BLS12-381 & 1.06 \textmu s & 350 \textmu s & 820 \textmu s \\
ML-DSA-44 (FIPS 204 Cat~2) & 175 \textmu s & 1.36 ms & 245 \textmu s \\
ML-DSA-65 (FIPS 204 Cat~3) & 343 \textmu s & 2.63 ms & 398 \textmu s \\
ML-DSA-87 (FIPS 204 Cat~5) & 461 \textmu s & 3.29 ms & 517 \textmu s \\
SLH-192f (FIPS 205 fast) & --- & 63 ms (THBS) & --- \\
SLH-192s (FIPS 205 small) & --- & 1.43 s (THBS) & --- \\
SLH-256s (FIPS 205 small) & --- & 2.04 s (THBS) & --- \\
secp256k1 & --- & --- & 658 ns \\
\bottomrule
\end{tabular}
\end{table}
\begin{table}[h]
\centering
\small
\caption{Magnetar v1.1 strict-atom THBS-SE vs v1.0-equivalent baseline
(circl-dispatched SignDeterministic). Source:
\texttt{magnetar/CHANGELOG.md \S 1.1.0}.}
\label{tab:magnetar-speedup}
\begin{tabular}{lrrr}
\toprule
\textbf{Mode} & \textbf{v1.0-equivalent} & \textbf{v1.1 strict-atom}
& \textbf{Delta} \\
\midrule
Magnetar-SHAKE-192s & 2.93 s/op & 1.43 s/op & $-51\%$ \\
Magnetar-SHAKE-192f & 113 ms/op & 63 ms/op & $-44\%$ \\
Magnetar-SHAKE-256s & 2.22 s/op & 2.04 s/op & $-8\%$ \\
\bottomrule
\end{tabular}
\end{table}
The strict-atom path is FASTER than dispatch-to-circl because the
Magnetar-internal SHAKE walk avoids circl's per-call \texttt{PrivateKey}
unmarshal + state struct initialisation overhead, while preserving
byte-identity to FIPS 205 verifiers.
\subsection{Quasar consensus protocol microbenchmarks}
\begin{table}[h]
\centering
\small
\caption{Quasar protocol benchmarks (Apple M1 Max, single-goroutine).
Source: \texttt{consensus/BENCHMARKS.md \S 5}.}
\label{tab:quasar}
\begin{tabular}{lr}
\toprule
\textbf{Operation} & \textbf{ns/op (ops/sec)} \\
\midrule
QuasarSig verify (msg = 512 B) & 1{,}017{,}823 (982) \\
QuasarSig sign (msg = 1024 B) & 808{,}500 (1{,}237) \\
QuasarSig verify (msg = 1024 B) & 1{,}089{,}206 (918) \\
BLS aggregation of 4 sigs & 209{,}808 (4{,}766) \\
BLS aggregation of 100 sigs & 5{,}297{,}844 (189) \\
BLS aggregated verify, 100 signers & 875{,}227 (1{,}142) --- \emph{constant} \\
QuasarBlockProcessing & 1{,}849{,}772 (540) \\
QuasarQuantumHash & 434.7 (2{,}300{,}000) \\
QuasarValidatorAddition & 327{,}629 (3{,}052) \\
\bottomrule
\end{tabular}
\end{table}
\noindent\textbf{Headline:} Aggregated BLS verification of 100 signers
completes in 875 \textmu s --- constant in committee size by aggregation.
A QuasarCert (21-validator BLS aggregate + ML-DSA + Pulsar) is producible
in $\sim$400--500 ms CPU (Groth16 dominates) and verifiable in 2--5 ms.
\subsection{PQ-mode wire and storage trade-offs}
\begin{table}[h]
\centering
\small
\caption{Storage and certificate-size cost of each consensus signing mode
(100~validators, 21~committee, 5\,k cert horizon). Source:
\texttt{consensus/README.md}.}
\label{tab:pqmodes}
\begin{tabular}{lrrrrr}
\toprule
\textbf{Mode} & \textbf{Sign} & \textbf{Aggregate} & \textbf{Verify}
& \textbf{Cert} & \textbf{Storage 10K} \\
\midrule
\texttt{bls} & 312 \textmu s & 8.6 ms & 714 \textmu s & 123 B & 1.17 MB \\
\texttt{bls-mldsa} & 369 \textmu s & 8.5 ms & 3.4 ms & 69 KB & 665 MB \\
\texttt{bls-rt} & 39 ms & 3.3 s & 1.6 ms & 33 KB & 318 MB \\
\texttt{triple} & 40 ms & 3.3 s & 4.3 ms & 102 KB & 981 MB \\
\bottomrule
\end{tabular}
\end{table}
\subsection{EVM execution: Lux C++ EVM vs go-ethereum vs reth}
\begin{table}[h]
\centering
\small
\caption{EVM execution throughput. Lux C++ EVM data from
\texttt{papers/evmgpu-benchmark}; competitor data from cited references
(Paradigm/reth April 2024 post, geth live-sync averages).}
\label{tab:evm-comparison}
\begin{tabular}{lllr}
\toprule
\textbf{Engine} & \textbf{Path} & \textbf{Workload} & \textbf{Throughput} \\
\midrule
\textbf{Lux C++ evmone+state} & CPU & full block & \textbf{20.9 Ggas/s} \\
\textbf{Lux Go EVM (baseline)}& CPU & full block & 4.2--5.4 Ggas/s \\
Lux $+$ parallel ecrecover (10c)& CPU & block w/ sigs & 7.1$\times$ over 1-core \\
go-ethereum (latest) & CPU & live mainnet sync & $\sim$25--50 Mgas/s \\
reth (Paradigm) & CPU & live mainnet sync & 100--200 Mgas/s \\
reth (Paradigm) & CPU & historical opBNB sync & 690 Mgas/s \\
\textbf{Lux C++ evmone interp.\ only}
& CPU & interp.\ only & $\sim$416 Ggas/s \\
Block-STM (Aptos) & 32-thread CPU & Aptos workload & up to 170k TPS \\
\bottomrule
\end{tabular}
\end{table}
\noindent\textbf{Headline:} Lux's native C++ EVM (evmone+state) sustains
$20.9$~Ggas/s in measured benchmarks --- roughly $400$--$800\times$ a
mainstream geth installation, $100\times$ reth live-sync, and within
$30\times$ of reth's best opBNB historical-sync number. The 87\% of block
time spent in secp256k1 ecrecover (measured at $334$\,ms of $384$\,ms
total) is the bottleneck targeted by the parallel-ecrecover and GPU
ecrecover paths.
\subsection{Quasar finality vs published consensus protocols}
\begin{table}[h]
\centering
\small
\caption{Published consensus latency / throughput points. The Quasar
single-DC 10\,ms / 4.76M TPS claim assumes the Lux 1\,B gas block limit
(47{,}619 txs/block at 21\,k gas per transfer). Source:
\texttt{papers/lux-quasar-benchmarks/sections/15-literature-backed-comparison.tex}.}
\label{tab:consensus-comparison}
\begin{tabular}{lrrrl}
\toprule
\textbf{Protocol} & \textbf{Validators} & \textbf{Finality (ms)}
& \textbf{TPS} & \textbf{Msg / commit} \\
\midrule
\textbf{Quasar (single-DC, BLS)} & 21 & 10 & 4{,}761{,}904 & $O(n)$ \\
\textbf{Quasar (CPU-BLS, WAN)} & 21 & 200 & TBM & $O(n)$ \\
Mysticeti-C & 10 & 500 & $>$200{,}000 & $O(n)$ \\
Mysticeti-C & 50 & $<$1{,}000 & $\sim$400{,}000 & $O(n)$ \\
Mysticeti-C & 106 & 390 (p50) & --- & $O(n)$ \\
HotStuff (orig.) & 128 & $\sim$700 & $\sim$50{,}000 & $O(n)$ \\
HotStuff-2 & 100 & $\sim$400 & --- & $O(n)$ \\
Tendermint / CometBFT & 100 & 1{,}000--3{,}000 & $\sim$10{,}000 & $O(n^2)$ \\
Avalanche Snowman & 2{,}000 & 1{,}350 & 3{,}400 & $O(k)$ sampling \\
Solana TowerBFT & 1{,}500 & 12{,}800 (econ.) & 65{,}000 claimed & $O(n)$ \\
\bottomrule
\end{tabular}
\end{table}
\noindent\textbf{Headline:} Quasar's classical (BLS-only) path provides
the only sub-second, post-quantum-equipped finality in the published
consensus literature. The PQ-finality column (Pulsar + ML-DSA-65) is a
strict superset of any non-PQ protocol on this list.
\subsection{Phase-2 (TBM): production WAN benchmarks}
The following benchmarks are designed but \emph{not yet measured} on
dedicated WAN-distributed hardware. They are listed here as a Phase-2
deliverable. Reproduction harness lives at the cited paths.
\begin{itemize}[leftmargin=1.4em,topsep=0.2em,itemsep=0.1em]
\item \textbf{WAN finality at 21 / 100 validators} ---
\texttt{papers/lux-quasar-benchmarks/sections/15-*.tex}
rows currently marked \texttt{[TBD]}. Repro via Lux netrunner
(\texttt{luxfi/netrunner}) on 4-region GCP/AWS topology.
\item \textbf{GPU EVM ecrecover at scale} ---
\texttt{papers/evmgpu-benchmark} reports the 20.9 Ggas/s C++
path and parallel ecrecover. GPU ecrecover (Metal/CUDA) is
target $20$--$24\times$ vs CPU per Lux memory; no public
baseline.
\item \textbf{ZAP wire over QUIC at p99} ---
\texttt{papers/lux-zap-benchmarks/sections/04-latency.tex}
reports 19.8 \textmu s p99 single-host; cross-DC numbers
pending.
\item \textbf{Magnetar threshold orchestration overhead} ---
single-party numbers are in Table~\ref{tab:crypto-prims};
network round-trip costs for THBS-SE Combine deferred to
\texttt{luxfi/consensus} layer.
\item \textbf{FHE precompile gas calibration at 12M block limit} ---
\texttt{papers/lux-fhe-benchmarks}; gas tables published per
precompile, full-block calibration pending.
\end{itemize}