CRYSTALS-Dilithium Blockchain Signatures, Running Live

What is CRYSTALS-Dilithium (ML-DSA)?

CRYSTALS-Dilithium is a lattice-based digital signature scheme standardised by NIST in August 2024 as ML-DSA under FIPS 204. Its security rests on the hardness of the Module Learning With Errors and Module Short Integer Solution problems, which, unlike the elliptic-curve discrete logarithm problem underlying ECDSA and Ed25519, have no known efficient quantum attack. Shor's algorithm breaks elliptic curves on a sufficiently large quantum computer; it does nothing useful against lattices. Dilithium comes in three parameter sets, and the strongest, Dilithium5, corresponds to ML-DSA-87 at NIST security category 5. The practical cost of that security is size: a Dilithium5 public key is 2592 bytes and a signature is roughly 4.6 KB, versus 33 bytes and about 64 to 72 bytes for ECDSA. That size gap is the central engineering problem for any post-quantum blockchain, and it is solvable. Dilithium also favors implementers: signing and verification avoid the floating-point precision hazards that complicate Falcon, part of why ML-DSA reached final standardization ahead of Falcon's FN-DSA.

Why blockchains need post-quantum signatures early

Blockchains have a uniquely bad relationship with quantum risk. Signatures and public keys are published permanently, so the harvest-now-decrypt-later argument that motivates the whole NIST PQC program applies in its strongest form: everything signed today is archived forever, waiting for whatever cryptanalysis arrives. Worse, a chain cannot rotate its way out retroactively; coins controlled by an exposed vulnerable key stay stealable the moment the curve falls. The open question of when quantum computers break current crypto matters less than the migration timeline: rewiring signature verification through consensus, wallets, and tooling on a live network takes years, so chains that begin after a credible quantum threat emerges will be too late. This is why QBC took the position that new quantum-safe cryptocurrency infrastructure should be post-quantum from the protocol layer up, not patched later. Joint government guidance now tells enterprises the same thing: inventory cryptographic dependencies and begin migrating well before a cryptographically relevant quantum computer is announced, because the migration itself is the long pole.

How QBC runs Dilithium5 in production

On QuantumAI Blockchain, Dilithium5 signatures are live in two protocol roles. Mining identities sign with Dilithium5, so the authorship of every VQE-sealed block is bound to a post-quantum key. And decentralised training participants sign their pseudo-gradient submissions with Dilithium5, so every attested training epoch carries post-quantum provenance end to end. The chain also operates a native post-quantum wallet flow with browser-side signing, including confidential transfer machinery, and pairs signatures with ML-KEM encrypted node transport so both authentication and confidentiality are lattice-based. One deployment lesson worth sharing: because Dilithium verification treats the message as an opaque byte string, changing what gets signed was deployable as a pure runtime upgrade without touching node binaries, a property that made several of our signing-format migrations dramatically safer than they would have been with precomputed-curve tricks. Operationally, the large keys changed tooling too: key generation and backup flows had to treat multi-kilobyte keys as first-class objects, and the browser wallet signs Dilithium payloads client-side so secrets never leave the user's machine.

Worked example: one signed training submission

A concrete flow shows the size tradeoffs in practice. A training worker on the QBC network computes a sparse pseudo-gradient, a few kilobytes of update data, and signs it with its Dilithium5 key: roughly 4.6 KB of signature attached to a payload that can be smaller than the signature itself. That inversion looks absurd until you look at granularity: the signature covers one submission per round, not per byte, so post-quantum provenance costs a bounded, predictable overhead per epoch of useful work. Validators verify the signature, evaluate the update against held-out data, and a 2/3 quorum finalises the epoch, the loop that DiLoCo-style training structures and whose milestone run is recorded in the step-one-million writeup. The same key hierarchy signs mining identities on every block, so authorship of each VQE-sealed block also carries post-quantum provenance. What makes this worked example worth copying is the boundary discipline: expensive post-quantum signatures sit at points of protocol significance, epoch submissions and block authorship, while high-frequency internals ride inside the encrypted transport session. Sign where value concentrates, and the 70x size penalty becomes a rounding error in the system budget.

Post-quantum privacy: signatures are only half the ledger

Signatures authenticate; they do not hide. A chain can be perfectly quantum-safe on identity and still leak every amount and relationship on a transparent ledger, which is why QBC pairs Dilithium5 with post-quantum private transfer machinery. The design uses commitments and zero-knowledge proofs chosen for post-quantum assumptions, in contrast to the pairing-based constructions many privacy chains rely on, which fall to the same quantum adversary as elliptic curves. The engineering record is public: the post-quantum zero-knowledge private transfers log covers the transfer protocol, the quantum-secure wallets writeup covers the wallet flow, and the underlying STARK-based construction is specified in the PQ confidential STARK paper, with the longer-term proving roadmap in the masked-trace STARK roadmap. For readers mapping the territory: confidential transactions hide amounts, shielded transactions hide participants, and post-quantum private transactions deliver those properties under lattice and hash assumptions. STARKs matter here because, unlike SNARKs with trusted setups and pairing assumptions, they rest on hash functions, a distinction unpacked in STARKs vs SNARKs. Honest caveat: this privacy machinery is newer than the signature layer and its audit history is shorter.

The real costs: size, throughput, and how to engineer around them

Honesty about costs: a 4.6 KB signature is roughly 70 times an ECDSA signature, which pressures block space, network bandwidth, and archival growth. Verification speed is not the bottleneck, Dilithium verifies fast on modern CPUs, but transaction size is. Mitigations that work in practice: reserve post-quantum signatures for protocol roles where each signature covers substantial value, mining identity per block, one signed submission per training round, rather than micro-payments; keep signatures out of long-lived state where possible so pruning bounds growth; and batch semantics, one signature attesting a whole epoch of work rather than per-item signing. QBC's training loop follows exactly this shape: kilobyte-scale sparse updates, one Dilithium5 signature each, validator quorum attestation on-chain. For high-frequency user transactions, hybrid schemes and signature aggregation research remain the frontier, and we do not claim those problems are closed. A budgeting rule from our deployment: count signatures per block, not signature size alone, because protocol-level signing keeps the count small and predictable while user-level signing makes it scale with load.

Dilithium vs alternatives: SPHINCS+, Falcon, and hybrids

NIST standardised three signature schemes: ML-DSA (Dilithium), SLH-DSA (SPHINCS+), and FN-DSA (Falcon). SPHINCS+ is hash-based with the most conservative assumptions, but signatures reach 8 to 50 KB and signing is slow, workable for firmware, punishing for blocks. Falcon has the smallest signatures, around 0.7 to 1.3 KB, but requires floating-point-sensitive signing that is hard to implement safely, especially where side channels matter. Dilithium sits in the middle: moderate sizes, fast and constant-time-friendly implementations, and the reference position in the official CRYSTALS suite. For a chain signing protocol-level identities, that balance won. A reasonable counter-position is the hybrid approach, classical plus post-quantum together, which hedges against immaturity in lattice cryptanalysis; ecosystems with heavy legacy constraints should consider it. QBC, building fresh infrastructure for verifiable on-chain AI, chose full Dilithium5 for protocol roles and accepts the size cost as the price of category-5 margins.