papers/lp-137-gpu-crypto-stack/sections/01-introduction.tex

\section{Introduction}
\label{sec:introduction}

A modern blockchain crypto substrate is a fragmented surface. The same elliptic curve appears under three different vendor prefixes, the same hash gets implemented twice in the same binary, and the test oracle is a fork of the production library. When the production library has a bug, the test passes anyway---both sides share the same root.

LP-137 is the Lux network's response. It defines, for every cryptographic primitive in the 9-chain topology, exactly one Go canonical, exactly one C++23 CPU body, and one kernel each in Metal, CUDA, and WGSL. All four are required to be byte-equal on randomized inputs at $N{=}1000$. The test oracle is a vendored, audited upstream (e.g.\ \texttt{gnark-crypto}, \texttt{blst}, \texttt{PQClean}) that is \emph{never linked into shipped libraries}---it appears only at the test-time boundary in \texttt{<alg>/test/cmake/}, preserving its adversarial-distance against the first-party body.

\subsection{Three failure modes LP-137 closes}

\paragraph{Oracle bypass.} When the CPU canonical and the test oracle come from the same upstream family (e.g.\ both forked from \texttt{blst}, or both from \texttt{gnark-crypto}), the byte-equality contract loses its adversarial property: an upstream bug propagates through both sides of the check and the test passes silently. First-party CPU plus audited test oracle is the correct adversarial structure---a bug on either side fails the test. LP-137 therefore mandates that the CPU canonical be Lux first-party for every algorithm in the corpus.

\paragraph{Vendor symbol leak.} Production binaries that link \texttt{blst}, \texttt{mcl}, or \texttt{BoringSSL} into the production graph re-expose vendor symbols and tie the security boundary to upstream release cycles. LP-137 pins those libraries to \texttt{<alg>/test/cmake/} oracles, never to \texttt{lib<alg>.a}, eliminating both surfaces.

\paragraph{Brand fragmentation.} Per-organization symbol prefixes (\texttt{LUX\_*}, \texttt{LUXFI\_*}, \texttt{HANZO\_*}) make the same algorithm look like five different libraries to the linker, the C-ABI consumer, and the auditor. LP-137 enforces brand-neutral naming: the algorithm name \emph{is} the namespace.

\subsection{The GPU-residency invariant}

The 9-chain Lux topology (P, C, X, Q, Z, A, B, M, F) routes hot-path bytes through attested GPU memory. The GPU-residency invariant is operational: no plaintext key, no signing nonce, and no hot-path scalar leaves an attested GPU device during a chain-local round. CPU touches reality only at four boundary events:

\begin{itemize}
\item Packet ingress (network NIC $\rightarrow$ pinned host buffer $\rightarrow$ GPU DMA).
\item Cold-state page service (state Merkle tree leaves loaded for a transaction touch).
\item Attestation handshake (TEE / NV-NRAS / SEV-SNP / TDX evidence verification).
\item Watchdog (slow-path liveness probe, mTLS heartbeat, cert rotation).
\end{itemize}

Every other byte is GPU-resident. This is not an aspirational property---it is checked by the determinism harness on every commit (\S\ref{sec:determinism-harness}).

\subsection{Per-algorithm LPs}

LP-137 is the umbrella spec. The detailed formal specification of each algorithm lives in its own LP, organized so that exactly one LP corresponds to exactly one algorithm. The 29-algo corpus maps to 35 LPs (some algorithms appear in two LPs---e.g.\ a low-level curve LP plus a higher-level signing-scheme LP that consumes it). The per-algorithm LP carries:

\begin{enumerate}
\item Mathematical specification (parameters, algorithm, KAT vectors).
\item Implementation links: Go canonical path, C++ CPU body, Metal/CUDA/WGSL kernel paths.
\item Test oracle: vendored upstream commit + role boundary.
\item Security analysis: side-channel posture, attacker model, deprecation status.
\item Cross-references to consumer LPs and to LP-137 (this paper).
\end{enumerate}

The complete index is in LP-137 \texttt{\#per-algorithm-lps}, reproduced and expanded in \S\ref{sec:per-algorithm-spec} of this paper.

\subsection{Contributions}

\begin{enumerate}
\item A byte-equality methodology that produces deterministic CPU$\leftrightarrow$GPU parity across three GPU backends (Metal, CUDA, WGSL) for every algorithm in a 29-primitive corpus, enforced on $N{=}1000$ randomized inputs on every release.
\item A crossover-threshold sweep that empirically determines, per algorithm, the batch size $N^{*}$ at which the GPU pulls ahead of a single-thread CPU baseline. The dispatcher uses these thresholds to choose backend automatically.
\item A safety analysis that combines test-oracle isolation, GPU-memory hygiene, and brand-neutral C-ABI symbol layout into one operational checklist that fires on every PR.
\item A reproducible bench-ladder methodology with explicit calibration rules (single-thread CPU baseline, end-to-end GPU timing including upload/download, deterministic PRNG seed for input sampling).
\item A clean separation between substrate (this paper, LP-137) and per-algorithm spec (LP-026, LP-029, LP-066, LP-069, LP-070--077, LP-110--126, LP-131, LP-146--159), so that substrate evolution and algorithm evolution can proceed independently.
\item Acceleration-kernel specs decoupled from per-algorithm specs: LP-160 batched Montgomery inversion \cite{lp160}, LP-161 multi-curve Pippenger MSM \cite{lp161}, LP-162 combined-pair Miller loop \cite{lp162}, LP-163 Karatsuba modexp \cite{lp163}, LP-164 six-step NTT \cite{lp164}, LP-165 Pedersen tree-reduce \cite{lp165}, LP-166 threshold pre-sign batch kernel \cite{lp166}. Each is a kernel that consumes one or more per-algorithm canonicals and ships under the same byte-equality contract.
\end{enumerate}