papers/lp-219-p3q-framework/sections/01-introduction.tex

\section{Introduction}

P3Q is a standalone on-chain post-quantum verifier framework: one
EVM precompile at slot \texttt{0x012205}, one ABI, and a leading
\texttt{kind} byte that dispatches into per-family
threshold-signature verifier cores via the \texttt{P3QVerifier}
interface. Any contract that needs to check a post-quantum
threshold signature on-chain calls
\texttt{P3Q.verify(kind, sig, messageHash, groupPubKey)} at a
single address; the kind byte selects which cryptographic family
answers. P3Q is not a rollup primitive --- it is the general
PQ-verify dispatch surface --- but its driving consumer is the
PQ-secured rollup, and this paper specifies the framework
independently of any one caller or any one cryptographic family.

\subsection{P3Q and its consumers}

Post-quantum rollups separate cleanly into two layers, and P3Q is
the lower one:

\begin{itemize}[leftmargin=2em,nosep]
\item \textbf{The rollup-batch envelope pattern} (LP-218, the
  primary consumer) --- a sequencer composes transactions,
  threshold-signs a state-root tuple, and posts a single
  \texttt{RollupBatchTx}; the parent L1 verifies that signature by
  \emph{calling} P3Q inside normal block validation. The rollup
  pattern owns the wire format, the parent-L1-verifies-the-sig
  pattern, and the inherited cert mode --- it does not own the
  verifier.
\item \textbf{The P3Q verifier framework} (this paper, LP-219) ---
  the slot, the kind-byte dispatch ABI, the \texttt{P3QVerifier}
  registration interface, and the cross-family composition
  semantics. The per-kind verifiers are specified in the companion
  LPs LP-223 (Pulsar), LP-220 (Corona), and LP-222 (Magnetar).
\end{itemize}

LP-218 consumes P3Q; LP-219 specifies it. The dependency runs one
direction only: a contract that is not a rollup at all --- a
bridge light-client, a cross-chain message verifier, an
on-chain custody policy --- can still call \texttt{P3Q.verify} for
any post-quantum threshold-signature check.

\subsection{Why a single slot}

A naive design would allocate one EVM precompile slot per PQ
family: \texttt{0x012205} for Pulsar, \texttt{0x012206} for
Corona, \texttt{0x012207} for Magnetar. The earlier draft of this
work did exactly that, treating the rollup-batch wrappers as
sibling primitives. Three slots, three ABIs, three audit
surfaces, three call-paths in EVM.

The 2026-06-03 decomplection collapses this into one slot with
kind-byte dispatch. The motivations are not aesthetic:

\begin{itemize}[leftmargin=2em,nosep]
\item \textbf{Solidity callability is a UX surface.} A rollup
  contract that wants cross-family-maximum verify writes three
  \texttt{P3Q.verify(kind, ...)} calls at a single address. Three
  slots would mean three address constants, three ABI imports,
  three precompile registrations to track in the operator's head.
  One slot keeps the developer surface coherent.
\item \textbf{Audit surface compounds.} Three slots with three
  wrappers means three independent code paths around the
  threshold-signature verifier core -- the wrappers carry their
  own structural parsing, length checks, gas billing, and
  domain-separation contexts. Each is an audit boundary. One
  slot dispatches into per-kind verifier cores via the
  \texttt{P3QVerifier} interface and leaves only the dispatch
  table to audit.
\item \textbf{Future kinds add a byte, not a slot.} If a fourth
  PQ family enters the Lux stack (a hypothetical code-based
  signature with HQC-style structure, say), it lands as one new
  \texttt{kind} byte in the dispatch table and one new
  \texttt{P3QVerifier} implementation. No new precompile slot
  allocation, no new Solidity function shape, no new audit
  boundary at the EVM-side.
\item \textbf{One and only one way per LP-200.} The ZAP Stack
  umbrella codifies the principle: every distinct concern has
  exactly one canonical entry point. ``Verify a rollup-batch
  threshold signature on-chain'' is one concern; the kind byte
  selects which primitive answers the question.
\end{itemize}

\subsection{The kind set at a glance}

\begin{table}[h]
\centering
\small
\begin{tabular}{@{}lllll@{}}
\toprule
\textbf{kind} & \textbf{Name} & \textbf{PQ family} & \textbf{Underlying scheme} & \textbf{Spec} \\
\midrule
$0x01$ & Pulsar   & Module-LWE   & FIPS-204 ML-DSA-65 threshold & LP-223 \\
$0x02$ & Corona   & Module-LWE     & Corona two-round threshold & LP-220 \\
$0x03$ & Magnetar & Hash-based   & FIPS-205 SLH-DSA threshold   & LP-222 \\
\bottomrule
\end{tabular}
\caption{The three production kinds at slot \texttt{0x012205},
each specified in its own companion LP.}
\label{tab:kinds-overview}
\end{table}

A simultaneous structural break across both families would
require independent advances in (i)~Module-LWE cryptanalysis ---
which both the Pulsar and Corona kinds rest on, at distinct
parameter sets and codebases --- and (ii)~collision resistance
of the SHA-2 / SHA-3 family (the Magnetar kind). These two
families are widely understood to be mutually independent;
Pulsar and Corona add parameter- and implementation-level
diversity within the lattice family, not a second family. The
cross-family-maximum posture LP-217 PQ-heavy codifies relies on
the lattice/hash independence; this framework supplies the
on-chain machinery to actually compose all three kinds inside a
single rollup contract.

\subsection{Honest measurement state}

Throughout the P3Q LP family, performance numbers are tagged
\textbf{measured} or \textbf{projected}. The architectural
decisions of this framework paper (slot, ABI, dispatch table,
registration interface) are not contingent on any GPU dispatch
closing; they are contingent only on the per-kind CPU verifier
correctness, specified and benchmarked in the companion kind LPs.
GPU dispatch is projected, not measured, in every P3Q paper:
\texttt{nvidia-smi dmon} mean \texttt{SM\%} during the 2-hour
2026-06-04 Spark run was \SI{11.9}{\percent} (idle/background
only), and two boundary gaps (\texttt{lux-lattice.pc} not
installed on Spark; \texttt{lux\_slhdsa\_*} entry points not yet
exposed in \texttt{lux/accel/c\_api.h}) prevent dispatch until
closed.

\subsection{Roadmap}

Section~\ref{sec:architectural-decision} documents the 2026-06-03
decomplection in detail: the prior sibling-slots model, the
unification onto \texttt{0x012205}, and the relationship to
LP-0120's separate raw-primitive verifier slots.
Section~\ref{sec:verifier-interface} defines the
\texttt{P3QVerifier} Go interface that registers each kind into
the dispatch table. Section~\ref{sec:composition} ties the kind
set back into LP-217 cert profile modes and shows the
rollup-contract composition pattern for the PQ-heavy posture. The
per-kind verifier specifications live in LP-223 (Pulsar), LP-220
(Corona), and LP-222 (Magnetar).