mirror of
https://github.com/lux-apps/papers.git
synced 2026-11-03 05:07:46 +00:00
zooqueen
ac61e71667
Scrub residual Ring-LWE mislabels of the Corona/Pulsar threshold
signature family per canonical decision-b (source: ringtail/sign/config.go
M=8,N=7, q=0x1000000004A01).
- Corona = Module-LWE (Ringtail-derived parameter set, A in R_q^{8x7}),
not Ring-LWE / not "Module-LWE at rank 1".
- Pulsar = Module-LWE (ML-DSA-65, FIPS-204 byte-equal).
- Corona+Pulsar differ by parameter regime/codebase, NOT hardness family:
intra-lattice parameter/implementation diversity, NOT family-disjoint.
- True family-disjoint defense = Magnetar (hash, SLH-DSA) / HQC (codes).
Reframed the false Corona(R-LWE)-vs-Pulsar(M-LWE) family-independence
across lp-219/lp-220/lp-222/lp-223 (P3Q kinds), lux-quasar-composition
(profile hardness table + composition corollary/proof), lux-magnetar-pq,
and the superseded triple-proof/quasar drafts (anonymous lattice
threshold lane = Corona). Legitimate FHE/TFHE Ring-LWE, NTT citations,
and neutral "rank-1" lattice facts left intact. PDFs rebuilt.
92 lines
3.3 KiB
TeX
92 lines
3.3 KiB
TeX
\section{Core Innovation: Triple-Proof Quantum Finality}
|
|
|
|
|
|
\subsection{The Triple-Proof Mechanism}
|
|
|
|
Q-Chain requires three cryptographic proofs for quantum finality:
|
|
|
|
\textbf{1. BLS Aggregated Signature (Classical)}
|
|
\begin{itemize}
|
|
\item BLS12-381 curve with 128-bit classical security
|
|
\item Aggregatable signatures for efficiency
|
|
\item 48-byte public keys, 96-byte signatures
|
|
\item Compatible with existing infrastructure
|
|
\end{itemize}
|
|
|
|
\textbf{2. Corona Threshold Signature (Post-Quantum, Privacy)}
|
|
\begin{itemize}
|
|
\item Lattice-based (Module-LWE, Ringtail-derived) with 128-bit post-quantum security
|
|
\item Threshold scheme: no single validator holds full key
|
|
\item Two-round protocol for efficiency
|
|
\item Provides anonymous validator participation (ring signature anonymity set)
|
|
\item Embedded in the ZK proof---zero additional block header bytes
|
|
\end{itemize}
|
|
|
|
\textbf{3. ZK Proof of ML-DSA Identities (Post-Quantum, Identity)}
|
|
\begin{itemize}
|
|
\item STARK proof aggregating $N$ ML-DSA-65 (FIPS 204) signatures into $\sim$200 bytes
|
|
\item Each validator signs with ML-DSA (3,309 byte signature) per epoch
|
|
\item STARK compression: $N \times 3{,}309$ bytes $\to$ $\sim$200 bytes
|
|
\item Provides post-quantum identity binding---even if BLS is broken, validator identities remain provable
|
|
\item QuasarCert verification: ${\sim}2$--$5$\,ms CPU (dominated by Groth16's 3 pairings on BLS12-381)~\cite{lux-benchmarks}
|
|
\end{itemize}
|
|
|
|
\begin{algorithmic}[1]
|
|
\State \textbf{function} \textsc{IsBlockFinal}(block, cert)
|
|
\State $valid_{BLS} \gets \text{VerifyBLS}(cert.BLS, block)$
|
|
\State $valid_{ZK} \gets \text{VerifySTARK}(cert.ZKProof, block, cert.Validators)$
|
|
\State \Return $valid_{BLS} \land valid_{ZK}$
|
|
\State \textbf{end function}
|
|
\end{algorithmic}
|
|
|
|
\subsubsection{Storage Efficiency at 1ms Block Times}
|
|
|
|
\begin{center}
|
|
\begin{tabular}{lrrr}
|
|
\toprule
|
|
\textbf{Component} & \textbf{Size} & \textbf{Frequency} & \textbf{Annual} \\
|
|
\midrule
|
|
Per-block BLS hash & 32 B & 1,000/s & $\sim$1.0 TB \\
|
|
Per-epoch triple proof & 248 B & 1/s & $\sim$7.8 GB \\
|
|
\midrule
|
|
\textbf{Total (headers + proofs)} & & & $\sim$\textbf{1.0 TB} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
|
|
\subsection{Security Analysis}
|
|
|
|
The triple-proof design provides defense in depth:
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\small
|
|
\begin{tabular}{@{}llll@{}}
|
|
\toprule
|
|
\textbf{Attack Scenario} & \textbf{BLS Cert} & \textbf{Corona Cert} & \textbf{Result} \\
|
|
\midrule
|
|
Classical Attacker & Secure (128-bit) & Secure (harder) & \checkmark Block Safe \\
|
|
Quantum Attacker & Vulnerable & Secure (128-bit PQ) & \checkmark Block Safe \\
|
|
BLS Implementation Bug & Compromised & Secure & \checkmark Block Safe \\
|
|
Corona Bug & Secure & Compromised & \checkmark Block Safe \\
|
|
Both Compromised & Compromised & Compromised & $\times$ Block Unsafe \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
|
|
\label{tab:security}
|
|
\end{table}
|
|
|
|
\subsection{Quantum Attack Window}
|
|
|
|
Q-Chain's rapid finality creates an impossibly narrow attack window:
|
|
|
|
\begin{align}
|
|
\text{Attack Window} &< 10\text{ms (GPU BLS), } < 100\text{ms (CPU BLS fallback)} \\
|
|
\text{Quantum Operations Required} &> 10^{12} \text{ (for BLS12-381)} \\
|
|
\text{Available Time} &\ll \text{Required Time}
|
|
\end{align}
|
|
|
|
Even with a 10,000-qubit quantum computer running optimal Shor's algorithm, breaking BLS12-381 would require billions of sequential operations, far more than possible in 10\,ms.
|
|
|