mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
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.
298 lines
14 KiB
TeX
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}
|