mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
98343d238e
Quasar Horizon (consensus composition over Pulsar / ML-DSA / BLS lanes
under Prism + LSS lifecycle), Warp 2.0 (Pulse-backed cross-chain envelope
with forward-only v1->v2 migration and lattigo ReadUint64Slice DoS fix),
benchmark report (microbench, reshare, activation, Warp 2.0 verify, Prism
composition, GPU headroom, cross-WAN latency), and NIST IR 8214C-style
submission package (spec, parameter sets, domain separation, serialization,
reference-impl pointers, evaluation report, security analysis, side-channel
considerations).
All four deliverables compile cleanly via pdflatex+bibtex and reference
the canonical proof bucket files at proofs/{definitions,pulsar,lss,quasar}.
No duplication of proof bodies; cite by file path.
42 lines
3.5 KiB
TeX
42 lines
3.5 KiB
TeX
\section{Related Work}
|
|
\label{sec:related-work}
|
|
|
|
\subsection{Vendor-as-canonical alternative}
|
|
|
|
The most common alternative to LP-137's first-party-CPU-canonical structure is to vendor an audited upstream (e.g.\ \texttt{blst} for BLS12-381, \texttt{mcl} for BN254) and use it as the production library. This was specifically considered and rejected on 2026-04-27 (LP-137 \texttt{Rejected proposals}). The reasoning:
|
|
|
|
\begin{itemize}
|
|
\item \textbf{Adversarial-distance loss.} If the production CPU body is the same upstream as the test oracle, the byte-equality check loses its bug-detection power.
|
|
\item \textbf{Vendor symbol leak.} Linking \texttt{libblst} into production re-exposes its symbol table and ties the security boundary to upstream's release schedule.
|
|
\item \textbf{Brand fragmentation.} Each vendor uses a different naming convention; merging multiple vendors into a single substrate creates an N-way symbol-prefix conflict.
|
|
\item \textbf{Build fragility.} \texttt{aarch64} Apple Silicon is a known weak spot for several upstream BLS libraries; a first-party body removes this dependency.
|
|
\end{itemize}
|
|
|
|
The verified-perf claim that vendor implementations are ``5-10$\times$ faster'' did not hold up on the cold path (the CPU canonical is not the hot path; the GPU kernel is). On the hot path, the comparison is GPU vs vendor-CPU, not Lux-CPU vs vendor-CPU, so the vendor-CPU faster baseline is irrelevant.
|
|
|
|
\subsection{Comparison with other substrates}
|
|
|
|
\paragraph{\texttt{gnark-crypto} (Consensys).} Excellent Go reference for pairing-friendly curves and ZK tooling \cite{gnarkcrypto}. Lux uses it as a test oracle (\S\ref{sec:determinism-harness}). It is not a GPU library and does not address the GPU-residency invariant.
|
|
|
|
\paragraph{\texttt{blst} (Supranational).} The reference BLS12-381 implementation \cite{blst}. CPU-only (with hand-tuned assembly per platform), no GPU kernel. We use it as a test oracle.
|
|
|
|
\paragraph{\texttt{arkworks-rs}.} Modular Rust crypto with strong type safety \cite{arkworks}. We import it as a second oracle for BN254 and Banderwagon KAT cross-verification.
|
|
|
|
\paragraph{\texttt{PQClean}.} The canonical post-quantum reference repository \cite{pqclean}. ML-KEM \cite{fips203}, ML-DSA \cite{fips204}, SLH-DSA \cite{fips205} reference implementations are imported via FetchContent; the LP-137 substrate provides the GPU kernel and the C-ABI shim.
|
|
|
|
\paragraph{\texttt{lattigo}.} Go reference for FHE primitives (BFV, BGV, CKKS, TFHE) \cite{lattigo}. Lux's TFHE substrate started from this lineage and ships first-party Metal/CUDA NTT kernels for the lattice arithmetic, lifted past the radix-2 ceiling by the LP-164 six-step transform \cite{lp164,longa2016}.
|
|
|
|
\paragraph{Rust BLS GPU prototypes (\texttt{gnark/golang.org/x/crypto/bls12381\_gpu}).} Several research-grade GPU BLS prototypes exist. None ship a unified byte-equality contract across CPU + Metal + CUDA + WGSL; LP-137 is, to our knowledge, the first production-grade substrate with that property.
|
|
|
|
\subsection{Why not Conan?}
|
|
|
|
\texttt{Conan} was rejected as the C++ dependency manager. Reasons:
|
|
|
|
\begin{itemize}
|
|
\item Adds a Python prerequisite to the build pipeline.
|
|
\item Pulls dependencies from a third-party repo by default; we want every dep to be a Lux fork pinned to a tag.
|
|
\item Doesn't compose well with CMake's \texttt{FetchContent}, which is the standard Lux build idiom.
|
|
\end{itemize}
|
|
|
|
\texttt{FetchContent} is the canonical mechanism. Each forked dep is at \texttt{luxcpp/<dep>@<tag>}; the \texttt{<alg>/test/cmake/<oracle>.cmake} pulls the test-oracle commit into the test binary only.
|