Files
zooqueen a1f77cacc9 papers: retire boschini2024corona key -> ringtail (third-party prior art); fix Pulsar/Corona/Ringtail provenance + lattice labels
Ringtail (Boschini et al., ePrint 2024/1113) is third-party prior art; Lux's
Corona (Ring-LWE = Module-LWE rank-1) builds on it; Pulsar is Module-LWE rank-k.
Retired the conflated boschini2024corona/corona2024/coronago/... bib keys to the
single canonical ringtail/corona/pulsar/magnetar keys, rewrote \cite + \bibitem
by context, and fixed 'Pulsar (Ring-LWE)' mislabels (Corona where corona.metal/
single-ring/Ringtail-derived; Pulsar where Module-LWE rank-k/ML-DSA). Cryptographer-led.
2026-06-19 22:33:10 -07:00

184 lines
9.0 KiB
TeX

\section{Related work}
\label{sec:related-work}
\subsection{NIST MPTC and FIPS}
The cryptographic backbone is FIPS 203 (ML-KEM) \cite{fips203}, FIPS 204
(ML-DSA) \cite{fips204}, and FIPS 205 (SLH-DSA) \cite{fips205}, with SP
800-185 (cSHAKE / TupleHash / KMAC) \cite{sp800185} for transcript binding
and SP 800-90A (DRBG) \cite{sp80090a} for chain-level randomness. The
NIST Multi-Party Threshold Cryptography (MPTC) report
\cite{nistir8214c} is the authoritative inventory of threshold schemes
under consideration; Pulsar-65 fits the M-LWE family in that inventory,
alongside Threshold ML-DSA \cite{tmldsa2025}, Threshold Raccoon
\cite{thresholdraccoon}, and Hermine \cite{hermine}. The Pulsar family
\cite{lp073} predates and informs the strict-PQ FinalitySchemeID
selection.
The FIPS family is consumed verbatim. The strict-PQ profile does not
introduce a new primitive; it consumes the standardised primitives and
wraps them in a TupleHash256-bound transcript discipline.
\subsection{Post-quantum blockchain efforts}
\textbf{Avalanche.} The classical Avalanche stack uses BLS12-381 for the
validator-set Snowman+ finality lane and ECDSA secp256k1 for the C-Chain
transaction lane. PQ posture is an active topic in the Avalanche research
roadmap as of 2026 but is not shipping on mainnet at this writing. The
strict-PQ profile in this paper is structurally similar to what an
Avalanche PQ retrofit would look like, with the Lux distinction being that
the Z-Chain identity rollup is a co-validated sibling chain rather than a
retrofit onto the P-Chain.
\textbf{Cosmos.} The Cosmos SDK has a number of PQ-experiment forks; the
official PQ posture is the Tendermint replacement proposal, which moves
Tendermint's Ed25519 validator-set signatures to ML-DSA-65. The Cosmos
proposal is consensus-only --- it does not touch the IBC bridge, the
account-side signing, or the contract-side authorisation. Strict-PQ
covers the surfaces Cosmos defers.
\textbf{Ethereum.} The Ethereum PQ posture is currently a multi-EIP
proposal track: EIP-2537 (BLS precompiles) is unrelated; EIP-7212
(secp256r1 precompile) is unrelated; EIP-7932 (signature registry, see
Section~\ref{sec:tx-auth-envelope}) is the closest analogue to
\texttt{TxAuthEnvelope}; EIP-8051 (expanded-pubkey form, see
Section~\ref{sec:pq-permit}) is consumed verbatim. The Ethereum proof-system
PQ posture is the FRI-based stwo \cite{stwo} and Plonky3 \cite{plonky3}
work; the strict-PQ profile admits the Plonky3-SHA3 variant alongside p3q.
The Ethereum community's PQ migration plan does not specify a single locked
profile equivalent to LUX\_STRICT\_E2E\_PQ. The community plan is a phased
adoption of individual EIPs, leaving the per-chain posture to each
deployment. Lux's contribution to that landscape is the locked-profile
design: a single 48-byte digest that names the entire posture.
\subsection{Z-Chain and identity rollups}
The Z-Chain identity rollup pattern (Section~\ref{sec:zchain-rollup})
borrows from the eIDAS-related identity-rollup designs (e.g., the
EU-funded EBSI \cite{ebsi}). Z-Chain's distinguishing characteristics are
(1) co-validation with the execution chains under the same committee;
(2) the seven-root aggregator structure that supports cheap
inclusion-proof verification by the EVM and other VMs; and (3) the
session-key sub-tree for ephemeral capabilities.
The Z-Chain identity scheme is not an SSI / DID framework
\cite{w3cdid}; it is a PQ key-registration rollup that integrates with
the Lux finality lane. SSI / DID integration is downstream and is
specified by HIP-0098 (out of scope for this paper).
\subsection{Threshold lattice signatures}
The Pulsar scheme (Section~\ref{sec:pulsar}) inherits from the
two-round lattice threshold signature literature:
\begin{itemize}[leftmargin=2em,nosep]
\item The Ringtail line \cite{ringtail} provides the MAC-authenticated
Round 1 commitment broadcast.
\item The Damgård / Orlandi / Takahashi / Tibouchi line
\cite{damgard2021} provides the two-round-from-lattice trapdoor
commitment construction.
\item The Threshold Raccoon line \cite{thresholdraccoon} provides the
practical-threshold-signatures-from-standard-lattice-assumptions
construction; Hermine \cite{hermine} extends this with DKG and
proactive refresh.
\item The Threshold ML-DSA family \cite{tmldsa2025} provides the
FIPS 204 compatibility path.
\item The lattice-based DKG line \cite{krt24,gks24} provides the
Pedersen-style DKG over $R_q$.
\end{itemize}
Pulsar is the Lux composition of these primitives plus the LSS lifecycle
framework \cite{luxlssmpc} for dynamic validator sets. The reference impl
ships in \texttt{luxfi/pulsar}.
\subsection{Post-quantum SNARKs}
The p3q stack (Section~\ref{sec:p3q}) is the Lux STARK / FRI canonical
\cite{lp137}. It sits within the broader hash-based SNARK landscape
alongside Plonky3 (with SHA3 vs. Poseidon variants) \cite{plonky3}, stwo
\cite{stwo}, RISC Zero zkVM \cite{riscZero}, and Mira-style sumcheck IOPs
\cite{mira}. The strict-PQ profile admits only the SHA3-Merkle variants
because Poseidon \cite{poseidon} is not part of FIPS 202 and would not pass
the \texttt{HashSuiteID} gate.
The trade-off versus Groth16 \cite{groth2016} is discussed in
Section~\ref{sec:p3q}: Groth16 is cheaper but requires a trusted setup and
a pairing-friendly curve, both of which the strict-PQ profile forbids
through the \texttt{ForbidTrustedSetup} and \texttt{ForbidPairings} bits.
\subsection{ETHDILITHIUM and EVM-side PQ}
ETHDILITHIUM \cite{ethdilithium} is the canonical pure-Solidity Dilithium
verifier; it uses Keccak in place of the FIPS 204 SHAKE, which makes it
non-conformant to FIPS 204 \cite{fips204}. The strict-PQ profile does not
deploy ETHDILITHIUM (it is not FIPS 204), but the contract serves as the
benchmark baseline for ``what if we did this in pure Solidity'' against
which the \texttt{PQAuth} precompile is measured (8.1M $\to$ 130k gas, a
$62\times$ improvement in the expanded-pubkey path, see
Section~\ref{sec:evaluation}).
The \texttt{ZKNoxHQ/ETHDILITHIUM} repository \cite{ethdilithium-repo} is
the open-source reference of the Keccak-variant verifier. Reading the
source confirms that the only difference from FIPS 204 Dilithium is the
hash family substitution; the rest of the verifier (lattice arithmetic,
sample-and-reject, hint reconstruction) is byte-faithful to FIPS 204. A
strict-PQ-compatible Solidity verifier could be derived by substituting
SHAKE back in --- the cost would be a $\sim 4\times$ slowdown over the
Keccak variant, putting pure-Solidity verification at $\sim 32$M gas, still
$\sim 245\times$ more expensive than the precompile path.
\subsection{Bridges and cross-chain PQ}
The strict-PQ bridge (Section~\ref{sec:bridge-pq}) follows the design
pattern of Cosmos IBC \cite{ibc} and Polkadot XCMP \cite{xcmp} but
substitutes ML-DSA-65 for the classical admission key and binds a Z-Chain
inclusion proof. The cross-chain Warp envelope (HIP-0080,
\texttt{luxfi/warp}) carries the Pulsar finality cert from the source
chain to the destination chain, where a recursive p3q proof verifies the
cert inside a destination-chain proof.
The closest analogue is the post-Berachain proof-aggregation bridge
\cite{berachain-bridge}, which uses BLS aggregates over the source-chain
finality artifact. The Lux strict-PQ replacement is the same structure
with Pulsar-65 in place of BLS, with the additional Z-Chain identity
binding.
\subsection{Other companion artefacts}
\textbf{HIPs.} HIP-0077 (Parent identity / TypedNodeID), HIP-0078 (Z-Chain
registry), HIP-0079 (Q-Chain finality), HIP-0080 (cross-chain Warp),
HIP-0081 (Pulsar DKG), HIP-0082 (Wallet PQ Account), HIP-0083
(Contract PQ Permit), HIP-0084 (PQAuth precompile block), HIP-0085
(TxAuthEnvelope), HIP-0086 (Session KEM), HIP-0087 (DRBG governance),
HIP-0088 (Bridge profile), HIP-0089 (mldsafx C-Chain fork), HIP-0090 to
HIP-0104 (proofs, sub-protocols, edge cases). The complete HIP set is the
specification surface this paper compresses.
\textbf{LPs.} LP-168..179 are the Lux mirrors of the corresponding HIPs in
the LP series \cite{lps}. LP-105 (Lux Stack Lexicon) is the canonical
vocabulary and claims-evidence table.
\textbf{ZIPs.} ZIP-0809..0820 are the Zoo mirrors, applied to the Zoo
deployment of the Lux stack. The Zoo deployment inherits LUX\_STRICT\_E2E\_PQ
verbatim; the ZIP series carries the Zoo-specific governance binding.
\textbf{Companion proofs.} The strict-e2e-pq Lean 4 / TLA+ / Go property
tree (\texttt{luxfi/proofs/strict-e2e-pq/} \cite{luxstricte2epqproofs}) carries
the machine-checked counterparts to the propositions in this paper.
\subsection{What this paper does not specify}
\begin{itemize}[leftmargin=2em,nosep]
\item The Lux SSI / DID integration (HIP-0098).
\item The exact EVM tx-type \texttt{0x05} format
(HIP-0089-future).
\item The bridge-specific Pulsar-87 transition (HIP-0099).
\item The Quantum-Random-Beacon (QRB) primitive HIP-0100 proposes.
\item The Multi-Party DRBG that HIP-0100 follow-on proposes for chain-level
randomness beyond the SP 800-90A baseline.
\end{itemize}
Each of these is the subject of its own HIP and its own paper; the
strict-PQ profile is the foundation they build on.