Solana's 90% Slowdown Proves What We Already Knew: Research Papers Don't Survive Production

Solana just tested quantum-resistant cryptography with Project Eleven. The results: signatures up to 40 times larger and the network roughly 90% slower. This is not a failure of post-quantum cryptography. This is a failure of bolting research implementations onto production infrastructure and expecting them to work.

What Happened

Solana partnered with Project Eleven to test NIST-standardized post-quantum signature algorithms on their network. The goal was to evaluate quantum-safe replacements for Ed25519, the elliptic curve signature scheme that currently secures every Solana transaction.

The results were exactly what anyone who has actually built a post-quantum system would have predicted. Dilithium signatures are 2,420 bytes compared to Ed25519's 64 bytes. That is a 38x size increase per signature. On a network that processes thousands of transactions per second, each containing multiple signatures, that size increase is not a minor detail. It is a structural problem that cascades through every layer of the stack.

Larger signatures mean larger transactions. Larger transactions mean fewer transactions per block. Fewer transactions per block means lower throughput. The reported result — roughly 90% throughput reduction — is the predictable mathematical consequence of multiplying the signature payload by 38 without changing anything else in the pipeline.

Why This Was Predictable

Post-quantum signature algorithms are larger and slower than their classical counterparts. This is not news. It is a fundamental property of lattice-based cryptography. The security comes from the computational hardness of lattice problems, and that hardness requires larger mathematical structures, which produce larger keys and larger signatures.

Dilithium (ML-DSA-65) produces a 3,309-byte signature. Falcon-512 produces a 690-byte signature. SPHINCS+ produces signatures ranging from 7,856 to 49,856 bytes depending on the parameter set. Ed25519 produces 64 bytes. There is no version of post-quantum signatures that is the same size as classical signatures. The math does not allow it.

Every research paper on post-quantum migration acknowledges this. Every NIST document discusses the tradeoffs. The information has been publicly available since the standardization process began in 2016. None of this should have surprised anyone.

The Research-to-Production Gap

Academic papers measure algorithms in isolation. They benchmark keygen(), sign(), and verify() on a single core with a single message. The numbers look reasonable. Dilithium sign takes a few hundred microseconds. Dilithium verify takes under a hundred. The papers conclude that post-quantum signatures are "practical" and publish.

Production is not a benchmark. Production is ten thousand transactions per second, each with two or three signatures, serialized into blocks, propagated across a peer-to-peer network, validated by every node, stored in an append-only ledger that grows by gigabytes per day. In production, the 38x signature size increase does not just slow down verification. It slows down serialization. It slows down network propagation. It slows down block assembly. It slows down storage I/O. It slows down state synchronization. Every subsystem that touches the signature — which is every subsystem — gets 38 times more data to process.

The research papers do not measure this. They cannot measure this. The cascading effects of larger signatures through a complete distributed system are emergent properties that only appear at production scale.

What Project Eleven Demonstrated (Unintentionally)

Project Eleven demonstrated three things, though probably not the three they intended:

First, retrofitting does not work. Solana's architecture was designed around the assumption that signatures are 64 bytes. The block format, the transaction format, the networking layer, the vote mechanism, the leader schedule, the turbine block propagation protocol — all of these were engineered for a world where signatures are small. Replacing Ed25519 with Dilithium changes the fundamental assumption that the entire system was built on. You cannot patch a foundational assumption. You have to rebuild around the new one.

Second, the performance gap is not incremental. A 90% throughput reduction is not something you optimize away. You cannot make Solana 10x faster to compensate for the post-quantum overhead. The network is already highly optimized. There is no 10x hiding in the existing architecture. The only way to recover that performance is to redesign the cryptographic pipeline from the ground up — different batching strategies, different serialization formats, different verification algorithms, different network protocols.

Third, the industry is not ready. If Solana — one of the most technically sophisticated blockchain projects in the world, with hundreds of engineers and billions in funding — cannot make post-quantum signatures work without a 90% performance hit, what chance does an average enterprise have? The talent, the tooling, and the infrastructure for production post-quantum systems do not exist in the open market. Companies that need post-quantum security cannot build it themselves.

How We Solved the Same Problem

H33 uses Dilithium ML-DSA-65 — the exact same algorithm that caused Solana's 90% slowdown. Our production benchmark: 2,209,429 operations per second with Dilithium signing and verification in the pipeline. Not 90% slower. Faster than most classical systems.

How? Not by using a different algorithm. Not by using faster hardware. Not by compromising on security parameters. By engineering the entire system around post-quantum from the beginning.

Batch attestation. Solana signs every transaction individually. We sign once per batch of 32. One Dilithium signature attests the entire batch. The 3,309-byte signature cost is amortized across 32 operations, reducing the per-operation cost by 97%. This is not a hack. It is a design decision that only works when the system is built for batch processing from day one.

Expanded key precomputation. The Dilithium signing key can be expanded into a form that eliminates redundant NTT (Number Theoretic Transform) computations during the signing process. This precomputation happens once at key load time and saves hundreds of microseconds per subsequent sign operation. Our v11 benchmark shows Dilithium sign+verify at 189 microseconds per batch — a 35% improvement over our v10 result because we optimized the expanded key path.

Pipeline integration. The Dilithium signature is not a standalone operation bolted onto the end of a pipeline. It is woven into the same pipeline as the FHE computation and the STARK proof. The SHA3-256 digest that Dilithium signs is computed incrementally as the FHE results come in. By the time the last FHE result is ready, the digest is already complete and signing begins immediately. Zero pipeline stall.

NTT optimization. Dilithium's internal operations rely heavily on polynomial multiplication via NTT. We implemented Montgomery NTT with Harvey lazy reduction, keeping butterfly values in [0, 2q) between stages to eliminate modular reduction overhead. The same NTT engine serves both the FHE pipeline and the Dilithium signer, meaning the CPU's L1 cache is warm with NTT twiddle factors when signing begins.

None of these optimizations are possible in a retrofit. They require the post-quantum algorithm to be a first-class citizen in the system architecture, not an afterthought bolted onto a classical pipeline.

The Signature Size Problem

Project Eleven's other finding — 40x larger signatures — is real and cannot be optimized away. Dilithium signatures are large. This is a property of the math.

But size only matters if you transmit and store signatures individually. In our architecture, one Dilithium signature covers 32 operations. The per-operation signature overhead is 3,309 / 32 = 103 bytes. That is 1.6x larger than Ed25519's 64 bytes, not 40x. The batch changes the math entirely.

For blockchain architectures that require per-transaction signatures, the path forward is either Falcon-512 (690 bytes, 10.8x Ed25519) or a hybrid scheme that uses classical signatures for consensus speed and post-quantum signatures for settlement finality. Both require architectural changes. Neither works as a drop-in replacement.

What This Means for the Industry

The Solana experiment is valuable because it puts a number on what the post-quantum community has been saying for years: retrofitting does not work. You cannot take a system optimized for classical cryptography and swap in post-quantum algorithms without fundamental performance regression.

The companies and protocols that will be quantum-safe are the ones that build for it from the ground up. Not the ones that wait for a drop-in replacement that will never come.

This is not a criticism of Project Eleven or Solana. Testing is essential. Publishing the results is courageous. The industry needed to see these numbers. But the conclusion should not be "post-quantum is too slow." The conclusion should be "post-quantum requires a different architecture."

That architecture exists. It runs 2.2 million operations per second with Dilithium, STARK proofs, and fully homomorphic encryption in the same pipeline. On a single ARM CPU. The tradeoffs that Solana encountered — the 90% slowdown, the 40x signature bloat — are engineering problems, not physics problems. They have solutions. Those solutions require building the system correctly from the start.

Post-quantum encryption was supposed to be too slow. It is not. It was supposed to be too large. It is not, when you batch correctly. It was supposed to require years of migration. It does not, when the system is designed as an API.

The research papers told us the algorithms work. Project Eleven told us the retrofits do not. The engineering is what fills the gap between those two facts.