papers/lux-adoption-roadmap.tex

%% ===================================================================
%% LP-134 canonical naming (2025-12-15):
%% Per LP-134 (Lux Chain Topology), the former T-Chain has been split into:
%%   M-Chain — MPC ceremonies for bridge custody of EXTERNAL wallets
%%             (CGGMP21, FROST, Pulsar-general)
%%   F-Chain — FHE compute + TFHE bootstrap-key generation (encrypted EVM)
%% T-Chain is REMOVED entirely; teleport is B-Chain (bridgevm, LP-6000). No teleportvm.
%% Where this paper says "T-Chain MPC" / "T-Chain threshold governance" /
%% "T-Chain TFHE" / "T-Chain custody", read as M-Chain (MPC) or F-Chain (FHE).
%% ===================================================================

\documentclass[11pt]{article}
\usepackage{shared/luxcover}
\usepackage{amsmath, amssymb, algpseudocode, graphicx, hyperref, booktabs}

\title{Adoption Roadmap: From Research Stack to Deployable Infrastructure}
\author{
Lux Research\thanks{Corresponding author: [email protected]}\\
\textit{Lux Industries, Inc.}\\
\texttt{[email protected]}
}
\date{2025}

\usepackage{amsthm}
\newtheorem{definition}{Definition}
\begin{document}
\luxcoverpage

\begin{abstract}
Research papers describe what is possible; adoption roadmaps describe what happens next. This paper specifies the phased deployment plan for Lux Network's post-quantum and FHE infrastructure, from the current production state (classical BLS consensus with PQ-ready architecture) to full Quasar triple-proof finality with confidential computing. We define four deployment phases with explicit dependencies, migration checkpoints, compatibility layers for each transition, audit milestones, and operator education requirements. Each phase has measurable entry and exit criteria---not aspirational dates, but concrete technical preconditions. The roadmap covers consensus migration (Nova to Quasar), cryptographic primitive rotation (ECDSA to hybrid BLS+ML-DSA), FHE integration (EVM precompiles + F-Chain), and bridge protocol upgrades (Teleport with PQ attestation).
\end{abstract}

\section{Introduction}

Lux Network's research program has produced specifications for quantum-secure consensus (Quasar \cite{quasar}), post-quantum signatures (Corona \cite{corona}, ML-DSA \cite{pq-suite}), fully homomorphic encryption (FHE \cite{fhe-api, fhe-benchmarks}), and supporting infrastructure (cryptographic agility \cite{crypto-agility}, hybrid certificates \cite{hybrid-certs}, zero-trust operations \cite{zero-trust}). Deploying these to a live network with real stake requires a plan that does not break what already works.

This roadmap is organized as four phases. Each phase has:
\begin{itemize}
\item \textbf{Entry criteria}: Technical preconditions that must be met before the phase begins.
\item \textbf{Deliverables}: Specific deployable artifacts.
\item \textbf{Exit criteria}: Measurable conditions that confirm the phase is complete.
\item \textbf{Rollback plan}: How to revert if the phase fails.
\end{itemize}

\section{Current State (Phase 0)}

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}ll@{}}
\toprule
\textbf{Component} & \textbf{Status} \\
\midrule
Consensus & Lux consensus family (BLS12-381 signing) \\
Node binary & \texttt{luxd} v1.23.x (Go, single binary) \\
EVM & C-Chain with chain-VM EVM (Zoo, Hanzo, SPC, Pars) \\
Signatures & ECDSA (legacy), BLS12-381 (active) \\
Bridge & Teleport with MPC attestation (classical) \\
FHE & Library implemented, demos passing, not in consensus \\
PQ & ML-DSA/Corona implemented, not in production signing \\
Formal verification & Lean4 proofs for consensus safety/liveness \\
\bottomrule
\end{tabular}
\caption{Phase 0: Current production state (as of v1.23.23).}
\label{tab:phase0}
\end{table}

\section{Phase 1: Hybrid Signatures and Certificate Infrastructure}

\subsection{Entry Criteria}

\begin{enumerate}
\item ML-DSA-65 implementation passes NIST KAT (Known Answer Tests).
\item Hybrid certificate enrollment tested on devnet with $\geq 5$ validators for $\geq 30$ days.
\item Cryptographic agility layer deployed on testnet with algorithm negotiation in ZAP handshake.
\item External audit of ML-DSA and hybrid certificate code completed.
\end{enumerate}

\subsection{Deliverables}

\begin{enumerate}
\item \textbf{Hybrid certificates}: Every mainnet validator holds a BLS+ML-DSA certificate \cite{hybrid-certs}.
\item \textbf{Algorithm negotiation}: ZAP handshake supports hybrid algorithm sets \cite{crypto-agility}.
\item \textbf{Hybrid key schedule}: Q-Chain stores both classical and PQ public keys per validator.
\item \textbf{Dual-signed blocks}: Blocks carry BLS signature (required) and ML-DSA signature (optional, for monitoring).
\end{enumerate}

\subsection{Exit Criteria}

\begin{enumerate}
\item 100\% of mainnet validators hold hybrid certificates.
\item ML-DSA signatures appear on $\geq 95\%$ of blocks for $\geq 7$ days.
\item No consensus disruption during the transition.
\end{enumerate}

\subsection{Rollback}

Drop ML-DSA extension from certificates. Revert ZAP handshake to classical-only. No state migration required.

\section{Phase 2: Quasar Consensus and Triple-Proof Finality}

\subsection{Entry Criteria}

\begin{enumerate}
\item Phase 1 exit criteria met.
\item Quasar consensus passes Lean4 safety and liveness proofs \cite{proof-methodology}.
\item Pulsar threshold DKG tested on testnet with $\geq 21$ validators for $\geq 60$ days.
\item Tamarin model for FROST-BLS and Pulsar verified.
\item Two independent audits of Quasar consensus code completed.
\end{enumerate}

\subsection{Deliverables}

\begin{enumerate}
\item \textbf{Q-Chain}: Platform management chain with Quasar consensus, replacing P-Chain.
\item \textbf{Triple-proof finality}: Blocks require BLS aggregate + Pulsar threshold + ZK identity proof.
\item \textbf{Validator migration}: Existing P-Chain validators re-register on Q-Chain with new key material.
\item \textbf{Slashing}: Post-quantum slashing conditions (double-sign, missing PQ cert).
\end{enumerate}

\subsection{Exit Criteria}

\begin{enumerate}
\item Q-Chain producing blocks with triple-proof certificates for $\geq 30$ days.
\item Finality latency $\leq 100$\,ms (CPU BLS) or $\leq 10$\,ms (GPU BLS) sustained.
\item No safety violations (conflicting finalized blocks).
\item P-Chain deprecated (read-only mode for historical queries).
\end{enumerate}

\subsection{Rollback}

Revert to P-Chain consensus. Q-Chain state is discarded. Validators re-register on P-Chain with existing keys. Requires coordinated restart.

\section{Phase 3: FHE Integration and Confidential Computing}

\subsection{Entry Criteria}

\begin{enumerate}
\item Phase 2 exit criteria met.
\item FHE library benchmarks meet SLOs \cite{fhe-benchmarks} on validator hardware.
\item EVM precompile gas metering verified by Halmos symbolic execution.
\item F-Chain (FVM) tested on testnet with threshold decryption for $\geq 30$ days.
\item One external audit of FHE EVM precompiles completed.
\end{enumerate}

\subsection{Deliverables}

\begin{enumerate}
\item \textbf{FHE EVM precompiles}: Encrypted arithmetic, comparison, and bitwise operations available to Solidity contracts on C-Chain and chain-VM EVMs.
\item \textbf{F-Chain}: FVM providing public parameter distribution, ciphertext registration, and threshold decryption.
\item \textbf{fhed integration}: FHE daemon deployable alongside validator nodes with mDNS discovery.
\item \textbf{Confidential token standard}: Encrypted ERC-20 using \texttt{@luxfi/contracts/FHE.sol}.
\end{enumerate}

\subsection{Exit Criteria}

\begin{enumerate}
\item FHE precompiles available on mainnet C-Chain.
\item At least one confidential token deployed and operational.
\item F-Chain threshold decryption operational with $\geq 15$-of-21 threshold.
\item No gas metering exploits (underpriced FHE operations).
\end{enumerate}

\subsection{Rollback}

Disable FHE precompiles via network upgrade (set activation timestamp to far-future). F-Chain stops processing new requests; existing ciphertexts remain encrypted. No fund loss---encrypted balances are unspendable until FHE is re-enabled.

\section{Phase 4: Full Stack and Ecosystem}

\subsection{Entry Criteria}

\begin{enumerate}
\item Phase 3 exit criteria met.
\item Bridge protocol upgraded with PQ attestation (Teleport).
\item HSM integration tested with $\geq 3$ HSM vendors \cite{hsm-boundary}.
\item Operator education program completed for $\geq 80\%$ of validator operators.
\end{enumerate}

\subsection{Deliverables}

\begin{enumerate}
\item \textbf{Teleport}: Cross-chain messaging with PQ-attested MPC signatures.
\item \textbf{HSM support}: Production HSM integration for BLS and ML-DSA signing.
\item \textbf{FHE applications}: Dark pool, compliance, blind auction demos running on mainnet.
\item \textbf{SDK updates}: \texttt{@luxfhe/sdk} with F-Chain integration.
\end{enumerate}

\subsection{Exit Criteria}

\begin{enumerate}
\item End-to-end PQ security from source code (signed releases \cite{reproducible-builds}) to consensus (Quasar) to confidential computing (FHE) to cross-chain (Teleport).
\item Zero critical findings in red-team exercise \cite{proof-methodology}.
\end{enumerate}

\section{Dependency Graph}

\begin{verbatim}
Phase 0 (Current)
  |
  v
Phase 1 (Hybrid Signatures)
  |  Depends on: crypto-agility, hybrid-certs, ML-DSA audit
  v
Phase 2 (Quasar Consensus)
  |  Depends on: Phase 1, Lean4 proofs, Pulsar DKG, 2 audits
  v
Phase 3 (FHE Integration)
  |  Depends on: Phase 2, FHE benchmarks, Halmos verification
  v
Phase 4 (Full Stack)
     Depends on: Phase 3, Teleport, HSM integration
\end{verbatim}

Each phase depends on the prior phase's exit criteria, not on a calendar date.

\section{Operator Education}

Each phase includes documentation and training for validator operators:

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}ll@{}}
\toprule
\textbf{Phase} & \textbf{Operator Action Required} \\
\midrule
Phase 1 & Generate ML-DSA keys, update staking registration \\
Phase 2 & Participate in Pulsar DKG, verify Q-Chain migration \\
Phase 3 & Deploy fhed sidecar, configure FHE parameters \\
Phase 4 & Integrate HSM, verify PQ attestation \\
\bottomrule
\end{tabular}
\caption{Operator actions per phase.}
\label{tab:operator}
\end{table}

\section{Conclusion}

A roadmap is a sequence of verifiable transitions, not a wish list. Each phase in Lux's adoption plan has concrete entry criteria (technical preconditions), measurable exit criteria (production validation), and a rollback plan (if the phase fails). The dependencies are explicit: Phase 2 cannot begin until Phase 1's exit criteria are met, regardless of calendar pressure. This structure ensures that the research stack described in Lux's 55+ papers becomes deployable infrastructure without compromising the security guarantees that the research established.

\begin{thebibliography}{99}

\bibitem{quasar}
Kelling, Z. (2025).
\textit{Quasar: Quantum-Secure Multi-Engine Consensus with Triple-Proof Quantum Finality}.
Lux Industries Research.

\bibitem{corona}
{Lux Industries}.
\textit{Corona: Two-Round Module-LWE Threshold Signatures}.
Lux Industries, 2026. \texttt{github.com/luxfi/corona}.
Module-LWE (Ringtail-derived), two-round.

\bibitem{pq-suite}
Kelling, Z. (2024).
\textit{Post-Quantum Cryptographic Suite for Blockchain Infrastructure}.
Lux Industries Research.

\bibitem{fhe-api}
Kelling, Z. (2025).
\textit{FHE API and Developer Model for Practical Private Applications}.
Lux Industries Research.

\bibitem{fhe-benchmarks}
Kelling, Z. (2025).
\textit{FHE Benchmarking, Cost Models, and Operational SLOs}.
Lux Industries Research.

\bibitem{crypto-agility}
Kelling, Z. (2024).
\textit{Cryptographic Agility Architecture for Long-Lived Blockchain Systems}.
Lux Industries Research.

\bibitem{hybrid-certs}
Kelling, Z. (2024).
\textit{Hybrid Certificate Chains and Post-Quantum Trust Anchors}.
Lux Industries Research.

\bibitem{zero-trust}
Kelling, Z. (2025).
\textit{Zero-Trust Validator Operations and Service Identity}.
Lux Industries Research.

\bibitem{hsm-boundary}
Kelling, Z. (2025).
\textit{Secure Enclave, HSM, and Threshold Boundary Design}.
Lux Industries Research.

\bibitem{reproducible-builds}
Kelling, Z. (2025).
\textit{Signed Software, Reproducible Builds, and Quantum-Resilient Release Pipelines}.
Lux Industries Research.

\bibitem{proof-methodology}
Kelling, Z. (2025).
\textit{Security Proof Obligations, Red-Team Methodology, and Verification Strategy}.
Lux Industries Research.

\end{thebibliography}

\end{document}