Post-Quantum Cryptography
Canonical reference · Estimated read time: 12 minutes
TL;DR
Valdium uses ML-DSA-65 (Dilithium3), a NIST-standardised post-quantum digital signature scheme, for all transaction and consensus signatures. Every signature ever written to the chain is quantum-safe from genesis. There is no migration period, no legacy classical signatures, and no planned cryptographic upgrade for the foreseeable future.
Why post-quantum matters
The threat
Modern blockchains rely on elliptic-curve digital signatures — ECDSA, EdDSA, BLS. The security of all of these schemes depends on a single mathematical problem: the discrete logarithm problem in elliptic-curve groups.
In 1994, Peter Shor proved that a sufficiently large quantum computer can solve the discrete logarithm problem in polynomial time. A quantum computer running Shor's algorithm doesn't weaken ECDSA — it breaks it completely. Every blockchain account whose public key is publicly visible becomes vulnerable.
"Harvest now, decrypt later"
The natural objection is "large-scale quantum computers don't exist yet, why worry?" That objection misses the most important property of a blockchain: the ledger is permanent.
Every signature ever written to a blockchain is publicly recorded forever. An adversary can copy the entire chain history today, archive it cheaply, and wait for quantum hardware to mature. The day a sufficiently large quantum computer exists, every classical signature on every blockchain becomes a potential attack vector — retroactively. Funds can be stolen from dormant accounts. Historical transactions can be repudiated.
Valdium's position is simple: the cost of building post-quantum cryptography in from day one is small. The cost of retrofitting it later — or being wrong about the timeline — is enormous.
What we picked: ML-DSA-65 (Dilithium3)
In August 2024, NIST published FIPS 204, standardising the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), derived from the academic scheme CRYSTALS-Dilithium.
| Variant | NIST Level | Sig size | Public key |
|---|---|---|---|
| ML-DSA-44 (Dilithium2) | Level 2 | ~2.4 KB | ~1.3 KB |
| ML-DSA-65 (Dilithium3) | Level 3 | ~3.3 KB | ~1.9 KB |
| ML-DSA-87 (Dilithium5) | Level 5 | ~4.6 KB | ~2.6 KB |
We use ML-DSA-65 — NIST security level 3, roughly equivalent to AES-192 against classical attack. The middle option; the typical sweet spot.
Dilithium is a lattice-based signature scheme. Instead of relying on the discrete logarithm problem (which Shor's breaks), it relies on the hardness of Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) — both believed hard for quantum computers.
Alternatives we considered and rejected
Falcon-512
Sig size: ~666 bytes — five times smaller than Dilithium3. The catch: Falcon's signing operation requires constant-time floating-point arithmetic with very specific numerical precision. Implementing this correctly in JS/WASM is brutal — float behaviour in WASM is implementation-dependent, and getting deterministic, side-channel-resistant signing across Pi/x86/Apple Silicon is at the edge of a research problem. Verdict: the bandwidth win is real, but not worth the implementation risk for a JS-first chain.
SLH-DSA (SPHINCS+)
Purely hash-based — the most conservative post-quantum signature scheme. The catch: signatures are 8–17 KB depending on parameters. With a 100-validator committee, that's roughly a megabyte of signature data per finalised block. Verdict: beautiful theory, too expensive for our bandwidth target.
Hybrid schemes (classical + PQ)
Some early PQ deployments use a "belt and suspenders" approach: every signature is both an ECDSA sig and a Dilithium sig. Verdict: not for v1. Hybrid doubles signature size and complexity for marginal benefit — and the classical link is still attackable today.
What it costs us
| Resource | Classical (ECDSA) | Dilithium3 | Cost ratio |
|---|---|---|---|
| Signature size | 64 bytes | ~3,300 bytes | ~52× |
| Public key size | 32 bytes | ~1,900 bytes | ~59× |
| Signing time (Pi 4) | ~0.1 ms | ~5 ms | ~50× |
| Verification time (Pi 4) | ~0.3 ms | ~1.5 ms | ~5× |
The signature-size ratio is the significant number, and it is why every architectural choice in Valdium assumes PQC sigs are the dominant cost. We mitigate it via: bounded committee size (~100 validators gives ~330 KB of signature data per block), public-key reuse optimisation (transactions from known senders reference the key by address rather than re-including the full 1.9 KB), and verification-first optimisation (Dilithium's verification is only ~5× slower than ECDSA's — acceptable given the security gain).
Implementation
- Reference library: PQClean, the canonical C implementation of NIST PQ standards. We use the Dilithium3 (ML-DSA-65) variant.
- Bindings: WASM compiled with Emscripten. Native node addons for x86 and ARM64 as a performance fallback.
- Version pinning: the exact PQClean commit hash is part of the chain's protocol spec. Bumping it requires a hard fork.
- Determinism: all PQ operations are integer-only and deterministic across all supported platforms. Verified by cross-platform test vectors in CI.
- Audit posture: we do not roll our own crypto. We do not modify upstream PQClean. Any improvement is upstreamed first, then adopted.