zeekay
78efc403f2
Add corona/gpu package — the single, decomplecting point where corona opts into the lattice library's per-SubRing GPU NTT dispatcher. Architecture (decomplected). The lattice library already owns ALL build-tag plumbing for GPU NTT: ring.SetGPUDispatchers (subring_ops.go) is the canonical hook; the lattice/gpu package installs it under `cgo && gpu` build tags and provides a real CPU fallback under !cgo or !gpu. Output is byte-equal to ring.SubRing.NTT by lattice's own contract. corona/gpu adds the corona-side bridge: UseAccelerator() flips a global flag, NewParams() across corona consults the flag via MaybeRegister and binds each created Ring's SubRings into the lattice GPU registry. Single source of truth for the opt-in; no build tags inside corona. Threshold gating (honest). Single-poly Metal NTT at corona's production N=256 is roughly 4-6x SLOWER than pure-Go ring.SubRing.NTT (measured: BenchmarkPulsarSign_ 5of7 force-GPU 7.1s vs CPU 1.1s; 14of21 force-GPU 23.5s vs CPU 5.9s). The GPU win exists only in BATCHED dispatch (many polynomials per kernel launch), which requires future engine-layer plumbing of lattice/gpu.MontgomeryNTTContext.Forward(data, batch>=4) bypassing the per-poly r.NTT() pinch point. Therefore UseAccelerator() picks defaultThreshold=1024 — above corona's N=256 — so the SubRing dispatch is armed but does not fire on single-poly NTT. The registry remains primed for any future batch caller (e.g. FHE bootstraps in thresholdvm sharing this library). UseAcceleratorForce() (threshold=1) is provided strictly for the correctness gate: every NTT call routes through the GPU so the byte-equality test in threshold/threshold_gpu_test.go exercises the GPU path end-to-end. Production callers use UseAccelerator() instead. Byte-equality. TestThresholdSign_CPU_vs_GPU_ByteIdentical runs the full 2-round Pulsar signing protocol with GPU dispatch off and forced-on (same deterministic dealer randomness, same message) and asserts byte-equal sig.C / sig.Z / sig.Delta. Passes under CGO_ENABLED=0, CGO_ENABLED=1, and CGO_ENABLED=1 -tags gpu. Existing TestDKG2_GPU_ByteEqual coverage extends across n=3,5,7,11,21 (production shape). Wiring. NewParams() in sign-bound packages — threshold, dkg2, dkg, reshare — calls corona/gpu.MaybeRegister(r) for the main Q ring. RXi and RNu are power-of-two moduli; the NTT path is not taken on them. Tests. Full corona test suite passes under both build modes: - CGO_ENABLED=0 go test ./... => all green - CGO_ENABLED=1 -tags gpu test => all green
Corona
Lux is not merely adding post-quantum signatures to a chain; it defines a hybrid finality architecture for DAG-native consensus, with protocol-agnostic threshold lifecycle, post-quantum threshold sealing, and cross-chain propagation of Horizon finality.
See LP-105 §Claims and evidence for the canonical claims/evidence table and the ten architectural commitments — single source of truth.
Corona is the Lux Ring-LWE post-quantum threshold signature library
for Quasar consensus. The 2-round threshold construction line traces back
to the Boschini–Kaviani–Lai–Malavolta–Takahashi–Tibouchi R-LWE paper
(ePrint 2024/1113). Corona adds the
production lifecycle that line lacked: Pedersen DKG over R_q with proper
hiding, proactive resharing for epoch validator rotation, identifiable
abort, and the integration surface Quasar consumes.
The Module-LWE sibling library lives at luxfi/pulsar.
Pulsar's threshold signature output is byte-equal to FIPS 204 single-party
ML-DSA (NIST MPTC Class N1). The two libraries are independent — there is
no import line between them — and Quasar consumes them as parallel kernels
selected per-chain via FinalitySchemeID.
Why "Corona"
A corona is the luminous ring of light surrounding a star — visible only when the brighter central body (the Pulsar / Quasar) is partially occluded. Brand-paired with Pulsar (Module-LWE) and Quasar (the consensus that consumes both): the same family of threshold-finality light, observed at a different layer.
Production lifecycle additions
The original Boschini et al construction (ePrint 2024/1113) is a research artefact — trusted-dealer DKG, no proactive resharing, no integration surface. Corona is the production track that fills those gaps:
| Layer | Original R-LWE construction | Corona |
|---|---|---|
| 2-round threshold sign | ✅ same byte-equal protocol | ✅ inherited |
| Trusted-dealer Gen | ✅ for fixed federation | ✅ retained for bridge MPC |
| Proactive resharing for epoch validator rotation | ❌ not specified | 🚧 corona/reshare/ (this fork) |
| Pedersen DKG over R_q with proper hiding | ❌ not specified | 🚧 corona/dkg2/ (this fork) |
| Per-validator triple-sign integration with Quasar | ❌ N/A | 🚧 corona/consensus/ integration |
Composition with Pulsar as optional layered PQ defense
Corona is independently usable: a chain can pick Ring-LWE Corona as its sole PQ threshold layer, no cross-dependency on Pulsar. Lux primary- network QuasarCert combines both lattice families as a Double Lattice layered defence so a break in one family does not break finality:
QuasarCert {
BLS — optional classical fast-path (BLS-12-381 aggregate)
Corona — Ring-LWE threshold ML-DSA (this repo)
Pulsar — Module-LWE threshold ML-DSA (luxfi/pulsar)
MLDSARollup — per-validator ML-DSA-65 rolled up via STARK/FRI (P3Q)
}
Each layer is checkable independently with no shared code; selecting
the layer happens at chain-construction time via the FinalitySchemeID
axis on the chain's ChainSecurityProfile. The pure-PQ profile drops
BLS entirely and runs on Corona + Pulsar.
Layout
sign/— 2-round threshold signing (byte-equal with upstream)primitives/— Shamir, hashes, MACs, PRFs (byte-equal with upstream)utils/— NTT, Montgomery, ring helpers (byte-equal with upstream)networking/— TCP peer-to-peer (byte-equal with upstream)dkg/— original Lux DKG (Feldman VSS without noise; broken for public broadcast — see RED-DKG-REVIEW). Retained for reference.dkg2/— proper Pedersen DKG over R_q (Pulsar addition; this fork)reshare/— proactive secret resharing for epoch rotation (Pulsar addition; this fork)cmd/— KAT oracle generators
Status
WIP. The 2-round Sign+Verify path is byte-equal-validated against the original R-LWE construction (ePrint 2024/1113) via 16 SHA-256 KATs. The production-lifecycle additions (resharing + Pedersen DKG) are under design and implementation.