ML-DSA vs ECDSA: Blockchain Signatures After Quantum Computers

By the Anti_Quantum Team · Updated September 2026 · 8 min read

Every major blockchain in production today — Bitcoin, Ethereum, Solana, BNB Chain — signs transactions with a classical elliptic-curve algorithm: ECDSA or its close relative EdDSA. Both are fast, compact, and, as far as any classical computer is concerned, unbreakable. Neither survives a sufficiently large quantum computer. This piece compares ECDSA against ML-DSA (formerly CRYSTALS-Dilithium), the NIST-standardized post-quantum signature algorithm most blockchain projects are converging on, across the dimensions that actually matter for a production system: security assumptions, performance, signature size, and migration path.

The core difference: what each algorithm's security rests on

ECDSA security rests on the elliptic curve discrete logarithm problem (ECDLP): given a point on an elliptic curve derived from a private key, it should be computationally infeasible to recover the private key. This holds against every classical computer that exists or is likely to exist. It does not hold against a quantum computer running Shor's algorithm, which solves discrete-logarithm-type problems in polynomial time.

ML-DSA is a lattice-based scheme: its security rests on the hardness of the Module Learning With Errors (MLWE) problem, a well-studied lattice problem with no known efficient algorithm on either classical or quantum computers. It was standardized by NIST in FIPS 204 (August 2024) after roughly eight years of open cryptanalysis during the NIST Post-Quantum Cryptography standardization process — the same rigor ECDSA itself went through decades ago via other standards bodies.

Side-by-side comparison

Where ML-DSA actually costs you something: size, not speed

The number that matters most for blockchain engineers isn't signing speed — ML-DSA's sign/verify performance is genuinely competitive with ECDSA. It's size. A secp256k1 ECDSA signature is roughly 64–72 bytes; an ML-DSA signature at NIST security level 2 runs 2.4–3.3 KB, roughly 35–50x larger. For a blockchain that batches thousands of transactions per block, that difference compounds into real storage and bandwidth costs, which is why most migration designs don't put raw ML-DSA signatures directly on a base layer 1 — they either:

• Use Layer 2 rollups where signatures are aggregated and only compact validity proofs (e.g., STARK-based) are settled on-chain, or
• Rely on signature aggregation and recursive proof composition to amortize the size cost across many transactions, or
• Accept the size cost for a wallet-level, non-L1 use case where per-transaction storage isn't the bottleneck.

Why ML-DSA over Falcon or SLH-DSA?

NIST standardized three post-quantum signature algorithms initially: ML-DSA (FIPS 204), SLH-DSA / SPHINCS+ (FIPS 205), and Falcon (FN-DSA, still finalizing as FIPS 206). Each has a different tradeoff:

• Falcon produces smaller signatures than ML-DSA, but its implementation relies on floating-point arithmetic that's genuinely hard to make constant-time, increasing side-channel attack risk in constrained environments like hardware wallets — a real concern, not a theoretical one.
• SLH-DSA (SPHINCS+) is fully hash-based with extremely conservative security assumptions independent of lattice problems entirely, but produces much larger signatures (8–50 KB), making it best suited as a fallback or high-security mode rather than the default.
• ML-DSA currently offers the best practical balance: mature, well-tested implementations, reasonable signature sizes, and strong library support (liboqs, pq-crystals, Cloudflare's CIRCL) — which is why it's the primary algorithm most blockchain post-quantum migration proposals, including ours, are building around, with SLH-DSA kept as a conservative secondary option.

A realistic migration path: hybrid signing

No production blockchain is going to flip a switch from ECDSA to ML-DSA overnight — the realistic path, and the one most seriously-proposed migrations (including account-abstraction-based designs on Ethereum via ERC-4337) converge on, is hybrid signing: supporting both a classical and a post-quantum signature during a transition window, so existing infrastructure keeps working while new wallets and contracts adopt post-quantum verification. This is also the approach the AntiQuantum Wallet takes for Solana: ML-DSA as the primary signature scheme, with hybrid compatibility for the existing ecosystem during migration.

Frequently asked questions

Is ML-DSA slower than ECDSA?

Signature generation and verification are comparable in speed for both, sometimes faster for ML-DSA depending on implementation and security level. The real cost difference is size: ML-DSA signatures and public keys run roughly 15–40x larger than secp256k1 ECDSA.

Why was ML-DSA chosen over Falcon for most blockchain post-quantum migrations?

Falcon produces smaller signatures, but its implementation is significantly more complex and more sensitive to side-channel attacks in constrained environments. ML-DSA's simpler, more mature implementations currently make it the more practical default.

Can a blockchain support both ECDSA and ML-DSA at the same time?

Yes — hybrid signing during a transition period is the standard recommended migration path, using mechanisms like account abstraction to add post-quantum validation without changing base-layer consensus rules.