papers/lux-quasar-horizon/sections/10-future-work.tex

%% ====================================================================
\section{Future Work}
\label{sec:future-work}
%% ====================================================================

The Mar-3 freeze ships Quasar Horizon as the consensus composition over Pulsar / ML-DSA / BLS lanes, with LSS-managed dynamic lifecycle and asynchronous PQ finality discipline. This section names the open work that follows.

\subsection{Lumen stream layer}

Lumen is the post-quantum encrypted stream layer that carries Photons between validators (LP-105 \cite{lp105}). The forthcoming Lumen LP specifies three modes:
\begin{itemize}[leftmargin=2em,nosep]
  \item \textbf{Lumen Fast.} AEAD ratchet, no per-frame OTS. For high-throughput gossip / mempool / bundle data.
  \item \textbf{Lumen Audit.} OTS or publicly verifiable per-frame auth (LMS / XMSS / SLH-DSA). For votes, resharing messages, activation certs.
  \item \textbf{Lumen Bulk.} Bundle / state / chunk transport with optional erasure coding.
\end{itemize}

The Lumen handshake is hybrid (X-Wing combiner \cite{lp105}; ML-KEM-768 + X25519 + SHA3, per the IETF specification under that name). The composition with Quasar Horizon is straightforward: Lumen carries Photons; Photons cohere into Beams; Beams compose with ML-DSA cert sets and Pulses via Prism into Horizon. Lumen is orthogonal to the Horizon composition; the open work is the LP, the wire format, and the production deployment.

\subsection{FHE result roots}

Z-Chain produces FHE-encrypted state transitions (\cite{luxwarpv2} \S``Warp Private''). The composition with Horizon: a Z-Chain result root commits to the FHE ciphertext digest; the Pulse signs that root via the standard Horizon transcript. The destination chain (or downstream consumer) verifies under the unchanged GroupKey without seeing plaintext. This is Warp Private as a finality lane.

\paragraph{Open work.} The FHE result root is currently a research target. The Lux FHE benchmark report \cite{luxbenchmarks} cites measured numbers; the open work is the production circuit and the Pulse-over-FHE-result-root composition theorem.

\subsection{P3Q proof lane}

The Z-Chain Groth16 wrapper around the ML-DSA cert set is a classical compression artifact (Remark~\ref{rem:groth16-wrapper-horizon}). A future PQ-friendly wrapper replaces Groth16 with P3Q~\cite{luxp3q} or a lattice-based transparent SNARK. The wrapper continues to compress the ML-DSA cert-set verification, but now without a pairing-based assumption.

\paragraph{Open work.} (1) Confirm the P3Q parameter set for the ML-DSA-65 verification circuit ($\sim 2^{22.5}$ R1CS gates, App.~B of \cite{quasarcertsoundness}). (2) Benchmark it against Groth16 on the same circuit. (3) Provide a $\mathsf{Warp\,Private\,PQ}$ envelope variant in Warp 2.0 (\cite{luxwarpv2} \S``Future PQ-friendly proof system''). (4) Update LP-307 with the PQ wrapper as the default for new deployments. The state-machine for the wrapper choice is governance-gated; chains can switch wrappers without disturbing the Horizon PQ reduction.

\subsection{Lattice-based universally composable security}

The current proof bucket carries SUF-CMA reductions and BFT-style safety / liveness theorems. A universally composable (UC, Canetti \cite{canetti2001uc}) treatment of the full Quasar Horizon composition --- Beam + ML-DSA + Pulse + LSS lifecycle + DAG-BFT engine + Lumen transport --- is open work. The current Tamarin spec at \texttt{tamarin/QuasarConsensus.spthy} verifies the protocol-level handshake / vote / bundle flow under standard symbolic abstractions; a UC treatment would carry concrete security under the ideal-functionality framework.

\subsection{Grouped Pulsar at $n \geq 1000$}

Section~\ref{sec:grouped-pulsar} stated five open systems-research questions. The most pressing is the closed-form trade-off between $G$ (number of groups), $k$ (group size), $f$ (corruption fraction), and the per-group Pulse latency under WAN churn. Production deployments at $n \sim 100$ are tractable today; production deployments at $n \sim 1000$ are gated on this trade-off being formally characterized.

\paragraph{Empirical handle.} The benchmark report \cite{luxbenchmarks} cites measured Pulse latency at $K = 21$ and projects $K = 64$, $K = 128$ from the per-party Round 1 / Round 2 cost curve. The closed-form analysis remains open.

\subsection{Cross-chain Horizon propagation}

Warp 2.0 \cite{luxwarpv2,lp021v2} carries source-chain Horizon finality across chain boundaries via Pulsar Pulses. The composition with Quasar Horizon is direct: a Warp 2.0 envelope carries the source chain's HorizonCertificate (Beam + ML-DSA + Pulse); the destination chain's verifier (Warp 2.0 receiver) re-runs Prism over the source's transcript using the source-chain key registry.

\paragraph{Open work.} (1) Cross-chain validator-set registry: how does a destination chain learn the source chain's $(V_t, \mathsf{BLSRegistry}, \mathsf{MLDSARegistry}, \mathsf{PulsarGroupKey})$ as it evolves? Currently via the destination's source-chain key-registry contract; this contract's update path is itself a Horizon-final on the destination, leading to a recursive trust structure. (2) Quantitative analysis of cross-chain latency: with 5 source chains and 5 destination chains, what is the worst-case cross-chain Horizon-final delay? (3) Cross-chain Horizon batching: can a Warp 2.0 envelope carry multiple source NebulaRoots in one Pulse? Yes in principle; details in \cite{luxwarpv2}.

\subsection{Reanchor via DKG2 vs Foundation MPC}

Pulsar's Bootstrap path is a foundation MPC ceremony. The Pedersen DKG over $R_q$ (\texttt{pulsar/dkg2/}; LP-073 \cite{luxpulsar} \S\ref{sec:lifecycle:dkg}) is the trusted-dealer-free alternative. Both ship in parallel.

\paragraph{Open work.} The forthcoming DKG2 LP specifies the Pedersen DKG production path: KAT vectors, constant-time verifier, and the Reanchor governance flow that wires it into chain-level operation. Until DKG2 is production-ready, foundation MPC ceremonies remain the default for new key-eras.

\subsection{Threshold ML-DSA}

ML-DSA's per-validator signatures are independent (one keypair per validator); there is no threshold ML-DSA in production. \cite{tmldsa2025} (Celi et al., USENIX Security 2025) is a research construction; \cite{quasarcertsoundness} App.~A discusses the rejection-sampling circular dependency that prevents straightforward composition.

\paragraph{Open work.} If a production-ready threshold ML-DSA appears, it could replace the per-validator ML-DSA cert set with a single threshold signature. The composition with Horizon is direct (replace step 3 of the Prism predicate with a threshold-ML-DSA verify). Until then, per-validator ML-DSA + Z-Chain Groth16 compression is the production path.

\subsection{Scope of these futures}

None of these open items affect the core Horizon composition theorem (Theorem~\ref{thm:horizon-soundness}). They extend the surface (transport, FHE, cross-chain), tighten the analysis (UC, grouped trade-off), and replace classical-only wrappers with PQ-friendly ones. The Mar-3 freeze ships the production composition; the futures listed here are the natural extensions.