papers/lux-quasar-composition/sections/07-implementation.tex

\section{Implementation}
\label{sec:impl}

\subsection{Repository topology}

The Quasar suite is implemented across the following Lux
repositories, each of which is independently versioned and tagged:

\begin{table}[ht]
\centering
\small
\begin{tabular}{@{}lll@{}}
\toprule
\textbf{Repo} & \textbf{Role} & \textbf{Pinned Tag} \\
\midrule
\texttt{luxfi/quasar} & Umbrella spec / profile registry / composition proofs & v0.1.0 \\
\texttt{luxfi/consensus} & Quasar consensus engine, cert wire impl & v1.22.85 \\
\texttt{luxfi/pulsar} & Threshold ML-DSA-65 primitive (Tier A) & v1.0.9 \\
\texttt{luxfi/corona} & Threshold Module-LWE primitive (Tier A docs) & v0.6.0 \\
\texttt{luxfi/magnetar} & Threshold SLH-DSA primitive (Tier B) & v0.2.0 \\
\texttt{luxfi/crypto} & BLS / ML-DSA / SLH-DSA / ML-KEM primitives & v1.19.x \\
\texttt{luxfi/threshold} & Threshold MPC protocol library & v1.7.0+ \\
\texttt{luxfi/chains/quantumvm} & Z-Chain Groth16 rollup VM & v1.2.3+ \\
\texttt{luxfi/lens} & Curve-side threshold sister kernel & pinned \\
\bottomrule
\end{tabular}
\caption{Quasar suite repository layout. Each repository is an
independent unit of release; cross-repo coordination happens at
profile-rotation events (see Section~\ref{sec:profile-rotation}).}
\label{tab:repos}
\end{table}

The umbrella repository \texttt{luxfi/quasar} \cite{quasarrepo} owns
only the wire-format contract (\texttt{SPEC.md}), the profile registry
(\texttt{PROFILES.md}), the primitive version pins
(\texttt{PRIMITIVES.md}), and the cross-primitive composition proofs
(\texttt{proofs/}). It contains no Go code; it is documentation +
proofs + reference vectors.

The consensus engine \texttt{luxfi/consensus} \cite{consensusrepo}
contains the Go canonical implementation of the QuasarCert wire
format, the signing and verification entry points, and the
integration with the linear-chain (Nova) and DAG (Nebula) drivers.
The cert struct lives at
\texttt{protocol/quasar/types.go} (line 40), and the native binary
encoder lives at \texttt{protocol/quasar/corona\_gob.go}.

Each primitive lives in its own repo with its own documentation
package and its own NIST MPTC \cite{nistir8214c} submission
trajectory. The umbrella does not re-implement primitives, and the
primitives do not depend on the umbrella; they are connected only
via the wire-format contract.

\subsection{Pulsar: threshold ML-DSA-65 (Tier A)}

The Pulsar primitive \cite{pulsar} is the threshold ML-DSA-65
construction at \texttt{luxfi/pulsar}, pinned at \texttt{v1.0.9}
(\texttt{5d00be9}). It is Tier A on the NIST MPTC submission readiness
ladder: 14 documentation artifacts complete, EasyCrypt theory shells
$13/13$, Lean mechanization $5/5$, Jasmin verified-implementation
shells $3/3$, KAT determinism asserted, $19/19$ NIST N1 interop tests
passing, cryptographer sign-off APPROVED WITH GATES, cut-submission
dry-run validated for submission to NIST MPTC v0.1 on $2026$-$11$-$16$.

Pulsar provides:
\begin{itemize}[leftmargin=2em,nosep]
\item Joint Pedersen-style DKG over $R_q$ with explicit
      hiding / binding proofs and a complaint workflow
      \cite{pulsar,gennaro1999,pedersen91}.
\item Two-round threshold signing with rejection sampling, producing
      byte-equal FIPS 204 ML-DSA-65 signatures.
\item Verifiable secret resharing across validator-set rotations
      via LSS \cite{luxlssmpc}.
\item Activation certificates that bind a generation's public key
      into the next.
\item Identifiable abort on Round-1 / Round-2 message inconsistency.
\end{itemize}

The Pulsar primitive sits in the QuasarCert as the $\sigma^{\mathrm{Puls}}$
leg. It is the PQ-floor primitive --- present on every profile,
NIST-standardized via FIPS 204, single-party-compatible via Class N1.

\subsection{Corona: threshold M-LWE (Tier A documentation)}

Corona \cite{corona,ringtail} is the Lux production
fork at \texttt{luxfi/corona}, pinned at \texttt{v0.6.0}. The
documentation shape is Tier A complete (full Pulsar-template package
landed: SUBMISSION + NIST-SUBMISSION + SPEC + PROOF-CLAIMS +
AXIOM-INVENTORY + FIPS-TRACEABILITY + TRUSTED-COMPUTING-BASE + PATENTS
+ CRYPTOGRAPHER-SIGN-OFF + DEPLOYMENT-RUNBOOK); the cryptographer
verdict is APPROVED WITH GATES. Open Tier A gates: EasyCrypt theory
shells (GATE-1, v0.7.0), Lean-EasyCrypt bridge (GATE-2, v0.7.0),
dudect $10^9$ on threshold layer (GATE-3, v0.8.0), external audit
(GATE-4, v0.8.0). Construction soundness is inherited from Boschini
et al.~ePrint 2024/1113 / IEEE S\&P 2025.

The upstream academic name was ``Corona''; this has been retired
in the Lux ecosystem, and both the production fork and the
protocol family are now ``Corona''.

Corona provides the $\sigma^{\mathrm{Cor}}$ leg of the QuasarCert
on the Aurora and Polaris profiles. The Corona group key is derived
from a parallel DKG run alongside the Pulsar DKG at epoch boundaries.

\subsection{Magnetar: threshold SLH-DSA (Tier B, v0.1)}

Magnetar \cite{magnetar} is the v0.1 reveal-and-aggregate
threshold SLH-DSA construction at \texttt{luxfi/magnetar}, pinned
at \texttt{v0.2.0}. The construction is byte-wise Shamir VSS over
$\mathrm{GF}(257)$ on the SLH-DSA scheme seed; Combine reconstructs
the seed in aggregator memory, calls single-party
\texttt{slhdsa.SignDeterministic}, and zeroizes. This mirrors
Pulsar's v0.1 trust model: a brief aggregator-as-TCB window during
which the seed must be erased.

Tier B reflects that the construction has been implemented and
internally reviewed, but has not yet been externally audited and
does not have the full Tier A artifact bundle (EasyCrypt theory,
Lean mechanization, Jasmin verified implementation). The Polaris
profile depends on Magnetar reaching Tier A; the production
deployment plan reserves Polaris for after Magnetar's Tier A
audit completes (target $2027$ Q3 per \texttt{luxfi/magnetar}'s
\texttt{SUBMISSION-STATUS.md}).

Magnetar's signature is byte-identical to FIPS 205 SLH-DSA on the
reconstructed seed: \texttt{TestN1\_ByteEquality} across $(3,2)$,
$(5,3)$, $(7,4)$ committees verifies this property in CI. The
threshold output passes the unmodified NIST SLH-DSA verifier.

\subsection{BLS: BLS12-381 aggregate}

The BLS primitive \cite{cryptorepo} lives at
\texttt{luxfi/crypto/bls} and tracks the IETF BLS draft
\cite{ietfbls}. The aggregate signature is produced via point
addition; the threshold variant (for chains that desire threshold-BLS
custody) lives at \texttt{luxfi/threshold/protocols/bls}
\cite{thresholdrepo}.

The QuasarCert BLS leg uses the aggregate variant, not threshold:
each validator signs individually with its BLS-PoP key, and the
aggregate is computed by the proposer. The proof-of-possession
defeats the rogue-key attack \cite{boldyreva2003,bonehshorth}: each
public key is published with a BLS signature on the key under
itself, in a domain-separated context.

\subsection{Z-Chain Groth16 rollup}

The Z-Chain Groth16 VM lives at \texttt{luxfi/chains/quantumvm}
\cite{chainsrepo}. The circuit verifies ML-DSA-65 verification at
$\sim 2^{22.5}$ R1CS constraints per signature, amortized to
$\sim 2^{20}$ constraints per cert at $n = 21$ via the shared-matrix
optimization (Appendix B of \cite{quasarcertsoundness}).

The trusted setup is the powers-of-tau ceremony plus a
circuit-specific phase 2 with $\geq 1024$ contributors
\cite{bowegabizonmiers}. The verifying-key hash is rooted on
Z-Chain as $\mathsf{zchain\_vk\_root}$ and committed into the
validator-set Merkle root.

The Z-Chain leg is asynchronous: it produces one Groth16 proof per
window of $\sim 1024$ blocks (amortizing prover cost). Within an
epoch, blocks reuse the most recent valid proof.

The PLONK upgrade path is documented in Appendix D of
\cite{quasarcertsoundness}; the proof system is swappable
without changing the wire format because the Z-Chain leg is
$\pi^{\mathrm{ZK}}$, a 192-byte opaque proof byte string.

\subsection{Build and test reproducibility}

The full Quasar suite is reproducibly buildable from source.
Reproducibility is anchored on:

\begin{itemize}[leftmargin=2em,nosep]
\item Pinned Go versions: 1.26.1 in \texttt{luxfi/consensus} and the
      primitive repos.
\item Pinned module versions: \texttt{go.mod} files in each repo
      pin all dependencies at exact tags.
\item KAT vectors: each primitive ships golden test vectors that
      assert byte-equality with the NIST reference implementation
      (for FIPS 203/204/205) or with the academic reference
      implementation (for Corona; see \texttt{luxfi/corona/vectors/}).
\item Constant-time review: each primitive ships a
      \texttt{CONSTANT-TIME-REVIEW.md} (Pulsar) /
      \texttt{ct/} (Corona, Magnetar) documenting which functions
      have been audited to be constant-time, and which use the
      dudect statistical test (currently 10$^7$ samples; target
      10$^9$ for Tier A).
\end{itemize}

Build commands:
\begin{verbatim}
# Consensus engine
cd ~/work/lux/consensus && GOWORK=off go build ./... && GOWORK=off go test ./...

# Pulsar primitive
cd ~/work/lux/pulsar && go test ./... -tags=production_kat
cd ~/work/lux/pulsar && ./scripts/cut-submission.sh --dry-run

# Corona primitive
cd ~/work/lux/corona && go test ./...

# Magnetar primitive
cd ~/work/lux/magnetar && go test ./...

# Umbrella spec proofs (LaTeX)
cd ~/work/lux/quasar && latexmk -pdf proofs/composition.tex
\end{verbatim}

\subsection{GPU dispatch}

The GPU-native crypto stack \cite{lp137} provides Metal (Apple),
CUDA (NVIDIA), and WGSL (cross-vendor) dispatchers for the
verify-heavy operations:

\begin{itemize}[leftmargin=2em,nosep]
\item BLS aggregate verify: GPU dispatch at $\geq 64$ signers
      gives $\sim 20$--$24\times$ speedup over CPU (Metal M2 Pro
      measurement; \texttt{lux-pq-consensus-benchmarks/}).
\item ML-DSA-65 verify: GPU dispatch at $\geq 64$ signatures
      gives $\sim 8$--$12\times$ speedup.
\item Groth16 verify: GPU dispatch reduces the three-pairing check
      from 1--3 ms CPU to 200--500 \textmu s GPU.
\end{itemize}

The break-even point is $\sim 64$ signatures because of the
$\sim 100$ \textmu s Metal/CUDA dispatch overhead. Below that
threshold, the CPU single-verify path is faster.

For the QuasarCert specifically, GPU dispatch is most useful at
the aggregate-verify boundary: when a validator receives a batch
of certs (during catch-up sync) it can dispatch the BLS legs and
the Groth16 legs as GPU batches, amortizing the dispatch overhead.