Q-day for proofs

Shor's algorithm (1994) finds discrete logarithms in polynomial time. Every elliptic-curve system depends on that problem being hard: Ed25519 signatures, the BN254 pairings behind Groth16, and the ristretto255 ElGamal behind confidential transfers. On a large enough quantum computer, all of them fall completely.

Grover's algorithm (1996) speeds up brute-force search by a square root. Against a hash it halves the security bits in theory, and in practice it does less, because Grover's steps can't be spread across machines nearly as well as classical search. Hash-based systems survive by using big enough outputs. SHA-256, which this site's STARK uses, has room to spare.

In 2017, Roetteler and colleagues estimated about 2,330 logical qubits to break a 256-bit curve. In March 2026, a Google Quantum AI team brought that under 1,200 logical qubits and 90 million Toffoli gates, which they translate into fewer than 500,000 physical qubits running for minutes. Other 2026 papers trade time for space: one trapped-ion design needs far fewer physical qubits but runs for weeks.

No machine that size exists. Nobody can honestly give a date, either. But estimates keep falling, and anything that has to stay secret for years is exposed today if it can be recorded now and decrypted later.

“Quantum breaks ZK” is too vague to act on. Split it in two:

• Does the secret stay secret? Groth16 is perfectly zero-knowledge: a proof is statistically independent of the witness. An attacker with unlimited compute, quantum or not, learns nothing about your secret from proofs you already published.
• Does a forgery still get caught? No. The setup's public points encode τ, α, β and δ in the exponent, and Shor extracts them. With them, anyone can make a proof that verifies for a false statement: a claim from a non-member, a transfer that mints money.

So for Groth16 the danger is in the future, not the past. Every verifier that trusts Groth16 has to move off it before Q-day. The data under old proofs is fine.

Confidential transfers encrypt amounts with twisted ElGamal. The ciphertext is a Pedersen commitment C = x·G + r·H plus a decrypt handle D = r·P, where the public key is P = s⁻¹·H. The commitment part on its own would hide x perfectly. But D and P sit on chain, and Shor gives s from P. Then C − s·D = x·G, and a small discrete log (the same baby-step giant-step decryption the owner uses) gives the amount.

Every ciphertext ever written is therefore readable after Q-day by anyone who saved it. In the current SDK (a September 2026 change), both of a wallet's confidential-transfer keys are derived from its signature over the fixed message solana-conf-bal/v1. Ed25519 signatures are deterministic, so whoever recovers the wallet key can rebuild both. The lab shows the whole chain by breaking a deliberately weak key on your own computer.

A STARK commits to its computation with Merkle trees of hashes and checks it with FRI, a test that a committed function is close to a low-degree polynomial. There's no curve, no pairing and no setup. Chiesa, Manohar and Spooner proved in 2019 that this family stays secure against quantum attackers in the quantum random-oracle model.

The cost is bytes. This site's STARK, for the same statement as the 256-byte Groth16 proof, is 99,629 bytes (99.6 KB) at 120 bits of conjectured security. Winterfell reports 51–128 KB at 96 bits and 102–252 KB at 128 bits for its examples, so ours is in the normal range. That's 81× a legacy 1,232-byte transaction and 24× the new 4,096-byte v1 limit.

The common fix, wrapping the STARK in a SNARK, makes it small again by putting a pairing back on top. So the result is quantum-weak again. Small, quantum-safe and checkable in one transaction: today you get two of the three.

1. Inventory. List every place you verify a Groth16 proof or store ElGamal ciphertexts. Note who can upgrade each verifier key and program.
2. Keep long-lived secrets in hashes. Commitments and nullifiers survive. Ciphertexts under curve keys don't.
3. Don't put lasting secrets in confidential balances. They protect against today's observers, not tomorrow's.
4. Keep verifiers swappable. A program that can point at a new proof system is easier to migrate than one with a hardcoded key.
5. Track the size budget. v1 transactions (4,096 B) cut a STARK upload from 97 transactions to about 26. Hash-based verification on chain is getting less absurd.