mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
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.
184 lines
9.0 KiB
TeX
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.
|