Post-Quantum Cryptography

TL;DR

Asentum uses ML-DSA-65 (Dilithium3), a NIST-standardized 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 (which is nearly all of them, after the first outgoing transaction) 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. The integrity of the chain's history is broken, not just its future.

How close is the threat?

Current quantum hardware (low thousands of noisy qubits) is nowhere near the millions of high-quality qubits needed to run Shor's against a 256-bit elliptic curve. Most expert estimates put practical "cryptographically relevant quantum computers" 10–25 years out, with substantial uncertainty. But:

• NIST standardized post-quantum signature schemes in August 2024. The migration can start now.
• Long-lived chains will need to migrate eventually. The cost and disruption of a migration grows with the size and value of the chain.
• Building PQC in from genesis is dramatically easier than retrofitting it.

Asentum's position is simple: the cost of building PQC 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)

The standard

In August 2024, NIST published FIPS 204, standardizing the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), derived from the academic scheme CRYSTALS-Dilithium. ML-DSA offers three security levels:

We use ML-DSA-65 (Dilithium3) — NIST security level 3, roughly equivalent to AES-192 against classical attack. The middle option, the typical sweet spot.

How it works (at a high level)

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 two related problems on high-dimensional lattices: Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS). Both problems are believed to be hard for quantum computers as well as classical ones.

Mechanically: signing produces a vector that satisfies a lattice constraint involving the message hash and the secret key. Verification recomputes the constraint and checks the math. The full construction uses a Fiat-Shamir transform with rejection sampling — the gnarly details live in the FIPS 204 spec.

What matters for us is that all of this is integer arithmetic. No floating point, no curve operations, no pairings.

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 behavior 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+)

The good: purely hash-based. Its security depends only on the security of the hash function — 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 finalized block — more than three times our Dilithium budget.

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 Ed25519 sig and a Dilithium sig.

Verdict: Not for v1. We commit to PQC-only from genesis. Hybrid doubles signature size and complexity for marginal benefit — and the classical link is still attackable now.

What it costs us

PQ signatures are not free. The honest accounting:

The signature-size ratio is the scary number, and it is why every architectural choice in Asentum has to assume PQC sigs are the dominant cost.

How we mitigate

• Bounded committee size. A ~100-validator BFT committee per block gives us roughly 330 KB of signature data per finalized block. Manageable. A "thousands of validators sign every block" design would not be.
• No signature aggregation in v1. PQ signature aggregation isn't a solved problem. We accept the per-validator overhead and compensate by capping the committee.
• Public-key reuse optimization. For accounts already known to the chain, transactions can reference the sender's public key by their address rather than re-including the full key. Saves ~1.9 KB per repeat-sender tx.
• Verification-first optimization. Validators verify orders of magnitude more sigs than they produce. Dilithium's verification is only ~5× slower than Ed25519's — acceptable given the security gain.
• No PQC inside contract execution. Smart contracts don't directly invoke PQ primitives in v1. Contract authors who need signature checks call precompiled host functions.

How we use it in Asentum

Key generation

Each user/validator account is identified by a Dilithium3 public key. Addresses are derived as:

address = BLAKE3(pubkey)[0:20]

A 20-byte hex address, formatted with an EIP-55-style mixed-case checksum. Familiar wallet UX, post-quantum key material underneath.

Transaction signing

A signed Asentum transaction carries: the transaction body (recipient, value, gas, payload, nonce, chain ID, etc.), the Dilithium3 public key of the sender (~1.9 KB) — or, for repeat senders, a reference to it — and the Dilithium3 signature over the body hash (~3.3 KB). Total signature overhead per fresh-sender transaction: ~5.2 KB.

Consensus voting

Validators sign their pre-vote and pre-commit messages with their Dilithium3 keys. These signatures accumulate in finalized block headers — roughly 100 sigs per block in steady state, totaling ~330 KB of consensus signatures per block.

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.

Open questions

These are unresolved and will need separate decisions:

• HD wallet derivation for Dilithium. No standardized BIP32 equivalent exists. We may need to define one, or pin to whatever the NIST/IETF community converges on.
• Multi-signature schemes. Native multi-sig vs pure smart-contract multi-sig.
• Threshold signatures. Distributed key generation and threshold signing for Dilithium are active research areas. Not v1.
• Future PQ migration. Even though Dilithium is the safest "boring" choice today, the protocol's signature layer should be cleanly upgradeable behind a hard fork.