papers/lux-nist-mptc-submission/known-limitations.tex

% Lux NIST MPTC Submission — Known Limitations (honest assessment)
% Per repository policy: papers/, proofs/, audits/ are LaTeX-only.

\documentclass[11pt]{article}
\usepackage[margin=1in]{geometry}
\usepackage{amsmath}
\usepackage{hyperref}
\usepackage{enumitem}
\usepackage{longtable}
\usepackage{booktabs}

\title{Known Limitations\\\large Honest Assessment}
\author{Lux Network}
\date{}

\begin{document}
\maketitle

This document is a deliberate counter-balance to marketing material. It states
what the Lux MPTC stack does \emph{not} do, what is not yet production-ready,
what is research, and what is open work.

\section{Cryptographic limitations}

\subsection{The Z-Chain Groth16 wrapper is classical, not post-quantum}

The optional Groth16 wrapper around the ML-DSA cert set (LP-307) is a
pairing-based SNARK over BLS12-381. Pairing-based SNARKs break under Shor's
algorithm. The Groth16 wrapper compresses ML-DSA cert-set verification for
EVM verifier compatibility; it is \textbf{not} a PQ contribution. PQ finality
lives in ML-DSA + Pulsar.

This is acknowledged across the spec corpus
(\verb|proofs/quasar/horizon-soundness.tex| Remark \verb|rem:groth16-wrapper|;
\verb|proofs/definitions/finality-definitions.tex| Remark
\verb|rem:groth16-not-pq|; LP-105 \S\,Proof-lane classification). A future
PQ-friendly proof system (P3Q, \texttt{luxfi/p3q}, or lattice-based) replaces Groth16 in the
wrapper role; the production roadmap is clear, but the freeze tag ships
Groth16-classical and labels it accordingly.

\subsection{There is no production threshold ML-DSA}

ML-DSA's per-validator signatures are independent; we run one keypair per
validator. There is no FIPS standard for threshold ML-DSA. Research
constructions are tracked but not in production; the rejection-sampling
circular dependency (\verb|quasar-cert-soundness.tex| App.~A) blocks
straightforward composition.

If a production-ready threshold ML-DSA appears, it could replace the
per-validator ML-DSA cert set with a single threshold signature. Until then,
per-validator ML-DSA + optional Groth16 compression is the production path.

\subsection{Pulsar Bootstrap requires either a foundation MPC ceremony or DKG2}

The default Pulsar Bootstrap path is a one-time foundation MPC ceremony. A
toxic-waste assumption is confined to genesis of one key era; subsequent eras
run on Reanchor, which itself requires a fresh ceremony or a Pedersen DKG over
$R_q$ (\verb|pulsar/dkg2/|).

The DKG2 path eliminates the toxic-waste assumption but is not yet
production-default; it ships in parallel as a research production option
(LP-073 \S\,Pedersen DKG over $R_q$). For chains with hard ``no trusted dealer
ever'' requirements, DKG2 is the answer; for chains willing to accept a
one-time genesis ceremony per era, the foundation MPC path is the
lower-complexity production default.

\subsection{Group assignment for grouped Pulsar is open research}

Section 7 of the Quasar Horizon paper enumerates five open systems-research
questions for grouped Pulsar deployments. The most pressing: a closed-form
trade-off between $G$ (group count), $k$ (group size), $f$ (corruption
fraction), and per-group Pulse latency under WAN churn. The freeze tag ships
$G = 1$ for the production $n = 21$ Lux mainnet; multi-group code paths are
tested at $G \in \{2, 4, 8\}$ in
\verb|protocol/quasar/grouped_threshold_test.go| but not yet
production-deployed at $n > 100$.

\subsection{Pulsar upstream Feldman DKG is pseudoinverse-recoverable}

The upstream Pulsar academic reference uses a Feldman-style commit DKG that
has been shown pseudoinverse-recoverable in our internal red review
(\verb|luxcpp/crypto/corona/RED-DKG-REVIEW.tex|). Pulsar replaces this with
either a foundation MPC ceremony or a Pedersen-style DKG over $R_q$
(\verb|pulsar/dkg2/|); the upstream DKG is not used in the Lux production
stack.

This is documented; a chain operator who imports the upstream Pulsar
reference verbatim without the Lux DKG replacement would inherit the upstream
weakness.

\section{Implementation limitations}

\subsection{SDK status (honest assessment)}

\begin{longtable}{p{0.3\textwidth}p{0.6\textwidth}}
\toprule
\textbf{Language} & \textbf{Status} \\
\midrule
Go & Production-ready \\
Python (\verb|pkg/python/|) & Only complete non-Go SDK with real consensus logic \\
C (\verb|pkg/c/|) & Data structures only, not real consensus \\
Rust (\verb|pkg/rust/|) & FFI wrapper around C, not native \\
C++ (\verb|pkg/cpp/|) & Stub \\
\bottomrule
\end{longtable}

Production deployments must use the Go canonical. Other-language bindings
exist for tooling and read-only paths but should not be relied upon for
production consensus.

\subsection{GPU production path is not enabled}

The GPU code paths under \verb|corona/gpu/{metal,cuda,wgsl}/| (LP-137) are
research, not production. Reasons:

\begin{itemize}
\item Constant-time review of GPU code paths is not complete.
\item Cross-platform KAT byte-equality (Metal + CUDA + WGSL) is not yet
  validated.
\item The CPU path runs comfortably within the consensus block budget; GPU is
  a 2--6$\times$ improvement, useful but not blocking.
\end{itemize}

The freeze tag ships CPU-only for production. GPU is on the roadmap (LP-137)
and projected numbers are reported in the benchmark report.

\subsection{Fuzz harnesses run for 60\,s in CI}

The fuzz harnesses (\verb|warp/pulsar/fuzz_*.go|,
\verb|warp/fuzz_envelope_test.go|, \verb|pulsar/sign/fuzz_*.go|) run for 60\,s
per harness in CI. This is a production-grade fuzz cadence but does not
constitute a formal verification. A bug missed by the harness for 60\,s is
still possible; the production posture is to add new corpus entries on every
find and to keep the harness running indefinitely on dedicated infra (the
fuzz-discovered lattigo \verb|ReadUint64Slice| vulnerability of Mar-3 was
found within a 60-s fuzz run, which is encouraging but not exhaustive).

\subsection{Constant-time review is layer-specific}

The constant-time review (\verb|pulsar/CONSTANT-TIME-REVIEW.tex|,
\verb|lens/CONSTANT-TIME-REVIEW.tex|) covers the lattice math and the curve
math respectively. It does not cover:

\begin{itemize}
\item The Go runtime's garbage-collection-induced timing variance
  (fundamental to Go).
\item Cache-timing on heterogeneous hardware (varies across deployment targets).
\item Constant-time GPU code paths (GPU production not enabled).
\item The Lattigo deserializer (the lattigo \verb|ReadUint64Slice| finding of
  Mar-3 demonstrates that the deserializer is a separate hardening surface).
\end{itemize}

For deployments that need stricter constant-time guarantees, the
recommendation is to deploy on bare-metal x86 with \verb|GOGC=off| and custom
thread-pinning; the Lux production stack does not currently enforce this.

\subsection{Snapshot retention is finite}

LSS snapshot manager retains 8 generations by default
(\verb|threshold/protocols/lss/rollback.go|). Rollback to a snapshot older
than 8 generations requires a Reanchor (governance event). For chains that
need indefinite snapshot retention (audit / compliance), the snapshot
retention window is configurable via chain governance, but storage cost
scales linearly.

\section{Operational limitations}

\subsection{Cross-WAN p99 latency is sensitive to network conditions}

The cross-WAN $K = 21$ Pulse latency at p99 is $\sim 1.3$\,s on Lux mainnet's
current 5-region deployment (Section 8 of the benchmark report). Transient
WAN events (BGP routing changes, undersea cable issues, regional-DC outages)
can spike p99 above the 3-second bundle interval; in such cases the bundle
stays at Beam-final and the next bundle's transitive transcript inclusion
absorbs the lag. This is graceful degradation, not failure; downstream
consumers that depend on per-bundle Horizon-final must be prepared for
occasional lag.

\subsection{Validator-set rotation is a discrete event, not continuous}

LSS resharing is triggered by epoch transitions, not continuously. A
validator that joins or leaves at the start of an epoch is reflected in the
next reshare; intra-epoch joins and leaves are not reflected. For chains that
need finer-grained validator-set evolution, a custom epoch boundary policy
can be configured, but the resharing cost caps the epoch frequency in
practice.

\subsection{Reanchor requires governance}

A new $\eta$ (KeyEraID) is created via a Reanchor governance event. Reanchor
is intentionally heavy-weight to prevent accidental key-era resets. For
chains that need a faster Reanchor cadence (e.g., monthly key-era rotation
for security hygiene), the governance configuration can be adjusted, but
each Reanchor requires either a foundation MPC ceremony or a DKG2 run,
neither of which is sub-second.

\section{Security analysis limitations}

\subsection{UC treatment of the full composition is open work}

The current proof bucket carries SUF-CMA reductions and BFT-style safety /
liveness theorems. A universally composable (UC) treatment of the full
Quasar Horizon composition --- Beam + ML-DSA + Pulse + LSS lifecycle +
DAG-BFT engine + Lumen transport --- is open work. The Tamarin spec at
\verb|tamarin/QuasarConsensus.spthy| verifies the protocol-level handshake /
vote / bundle flow under standard symbolic abstractions; a UC treatment with
concrete security bounds remains future work.

\subsection{Adaptive corruption is bounded but not zero}

The proof bucket supports static-corruption reductions; adaptive-corruption
reductions appeal to Fischlin / erasure hybrids
(\verb|quasar-cert-soundness.tex| App.~C). The hybrid argument adds factors
that are absorbed in the concrete-security parameter; the production
parameters give classical $\geq 2^{142}$ and quantum $\geq 2^{130}$ even
after the hybrid loss. For deployments with long-term archival requirements
(decades), the parameter sets should be re-validated against future
cryptanalytic advances on Module-LWE / Module-SIS.

\section{In and out of scope}

\subsection*{In scope for this submission}

Pulsar (kernel + lifecycle), Lens (kernel + lifecycle), LSS (lifecycle
framework), Quasar Horizon (consensus composition), Warp 2.0 (cross-chain
envelope). All as documented in the spec/ directory.

\subsection*{Out of scope for this submission}

Lumen (PQ encrypted transport --- forthcoming Lumen LP), Warp Private
(FHE-encrypted payload --- production research), threshold ML-DSA (no FIPS
standard), grouped Pulsar at $G > 1$ at $n > 100$ (open research), GPU
production (research path under LP-137).

These items are tracked in the future-work sections of the companion papers
(\verb|luxquasarhorizon| \S10, \verb|luxwarpv2| \S Future). Each will be the
subject of a separate submission or revision to this submission as it
reaches production-readiness.

\end{document}