Nine minutes to a private key, read from a qubit lab
Google now estimates that a superconducting quantum computer with fewer than half a million qubits could recover a Bitcoin or Ethereum private key in about nine minutes, and it backed the claim with a zero-knowledge proof that Trail of Bits then forged. What the numbers assume, how close today's hardware is to them, and what it means for Solana, from someone who spends her days on superconducting qubits.
On 31 March, Google Quantum AI published a whitepaper on breaking the elliptic-curve cryptography that protects Bitcoin, Ethereum and most other blockchains [1]. The headline number is that a superconducting quantum computer with fewer than half a million physical qubits could recover a private key in minutes [2]. I went through all fifty-odd pages the night before a whitepaper reading group in Singapore on Tuesday, and yesterday I spent 45 minutes at a Solana meetup answering questions about quantum computers and post-quantum cryptography.
I read the paper from an unusual seat. By day I work on superconducting qubits: the same kind of hardware the paper’s estimate is built on. By night, most of what I build is on-chain. This post is my attempt to connect the two: what the paper actually claims, what it assumes about hardware, how close that hardware is today, and why the most interesting part for me is the zero-knowledge proof that was supposed to make it all checkable.
What Google claims
The target is the elliptic-curve discrete logarithm problem on secp256k1, the curve used for Bitcoin and Ethereum signatures. A private key is a number k, the public key is the point Q it produces from a fixed generator point G, and the security rests on the fact that going backwards is infeasible for a classical computer:
Shor’s algorithm recovers k with a quantum period-finding step, and most of its cost is elliptic-curve point additions carried out in superposition. The paper compiles two versions of the circuit. One needs fewer than 1,200 logical qubits and 90 million Toffoli gates; the other fewer than 1,450 logical qubits and 70 million Toffoli gates [2]. Measured by space and time together, the authors put this at roughly an order of magnitude better than the best previous estimate for a single key.
Logical qubits are error-corrected qubits, each built from many physical ones. With physical error rates of 10−3, a planar chip where each qubit talks to four neighbours, and the surface code, the paper estimates that fewer than half a million physical qubits are enough [2]. That is about twenty times fewer than the previous best estimate, which is the number most headlines took.
Where the nine minutes come from
The part that caught my attention as someone who works on control hardware is how the runtime is calculated. The paper assumes the computer is “reaction-limited”: the speed is set by how fast the control system can read out an error-correction result, decode it and decide the next operation. It assumes a reaction time of 10 microseconds and a 50% overhead per Toffoli gate [2]:
With 90 million Toffolis it is 23 minutes. The first half of the algorithm depends only on the curve, not on anyone’s key, so a machine can run it in advance and wait in a “primed” state. From the moment a public key appears, the attack then takes about 9 or 12 minutes [2].
That is why the paper separates three kinds of attack [2]. The first, on-spend, intercepts a transaction while it waits to be confirmed: the attacker reads the public key from the pending transaction, computes the private key, and sends a competing transaction. The second, at-rest, targets public keys that have been sitting on-chain for a long time, where the attacker has days. The third, on-setup, targets fixed public parameters, such as the “toxic waste” of a trusted-setup ceremony. I wrote about those ceremonies in 2023, and it is striking to see them listed as a quantum target by name.
The comparison with block times is what makes the paper alarming for Bitcoin. Nine minutes is shorter than Bitcoin’s ten-minute average block, so a public key revealed in the mempool could in principle be broken before the transaction is confirmed. It is not the risk that matters for Solana, where a slot is about 400 milliseconds. I come back to Solana below.
The paper also explains why the type of hardware matters so much. Running 70 million Toffolis in 9 minutes needs about half a million “magic” T states per second, each of which takes about 50,000 qubit-rounds to produce [2]. The number of physical qubits spent on producing them scales with the length of one error-correction round:
where R is the rate of T states needed, about 5 × 105 per second. With superconducting qubits, whose rounds take about a microsecond, the magic-state factories are small next to the rest of the machine, so an on-spend attack arrives at the same time as an at-rest one. Neutral atoms and trapped ions, with rounds of 100 microseconds or more, would need millions of extra qubits, so they would be able to attack old coins well before live transactions [2]. The paper calls these “fast-clock” and “slow-clock” machines. That matches what I tell people who ask me about trapped ions, the platform I did my undergraduate project on: their gates take microseconds where superconducting gates take nanoseconds. Clock speed is not a detail. It decides which attack comes first.
How close is the hardware?
The fair way to judge the estimate is to compare its assumptions with what the same kind of hardware has actually shown. Google’s own below-threshold experiment on the Willow chip, published in Nature in December 2024, is the best reference point [3]:
| The attack assumes | Shown on Willow | |
|---|---|---|
| Physical qubits | < 500,000 | 101 in one logical qubit |
| Logical qubits | 1,200–1,450 | 1 (a memory) |
| Error-correction round | ~1 µs | 1.1 µs |
| Control reaction time | 10 µs | 63 µs average decoder latency (distance 5) |
| Error rates | 10−3 | below the surface-code threshold |
What surprised me is how close most rows are. The round time is already there, and the error rates are good enough for error correction to work. The decoder is about six times slower than the assumed reaction time, but these are not quite the same quantity, and decoders are exactly the kind of thing that gets faster with better FPGAs and ASICs. The gap that remains is the first row: roughly five thousand times more qubits, all working together.
From the bench, that row is the hard part, and it is not only a question of making more qubits on a chip. Every qubit needs control and readout lines running down a dilution refrigerator, with attenuators and filters at each temperature stage, and the refrigerator itself is a machine you do not rush: an old one can take a week to cool down. The field has ideas for this, from cryogenic control electronics to linking many refrigerators, but none of them exists yet at this scale. The paper is honest about the direction of travel, though: its own figure shows the estimate for breaking RSA-2048 falling from about a billion physical qubits in 2012 to about a million in 2025, and it quotes the cryptographers’ rule that “attacks always get better” [2].
My own view has not changed much. When Vitalik Buterin put the chance of such a machine arriving before 2030 at about 20%, citing forecasters on Metaculus [4], my own guess was under 10%, and nothing I see in the lab makes me raise it. But the paper does change something: the physical-qubit estimate just fell about twentyfold in one paper, and a migration takes years. The time to start migrating is set by how long the migration takes, not by when the machine arrives.
A proof that could be forged
The most unusual part of the paper is not the estimate but how it was published. Google did not release the circuits, on the grounds that publishing them would be a roadmap for attackers. Instead it released a zero-knowledge proof. The statement is precise: Google holds a classical reversible circuit of a stated size that computes secp256k1 point addition correctly on most inputs [2]. A Rust program checks the secret circuit on 9,000 random inputs derived from the circuit’s own hash, the program runs inside Succinct’s SP1 zkVM, and the result is compressed into a Groth16 proof that anyone can verify [2].
As a way of disclosing a vulnerability without handing it out, I think this is brilliant. It is also exactly the situation I wrote about four weeks ago in A proof can verify and still be wrong: a zero-knowledge proof shows that a program accepted some input, not that the program checks what you think it checks.
On 17 April, Trail of Bits showed this in the most direct way possible [5]. They published their own proof, verifying against Google’s unpatched verification code, that claimed a better circuit on every metric, including zero Toffoli gates. They had not found a better quantum algorithm. They had found two bugs in the checker. The first was an unchecked deserialisation in unsafe Rust: by feeding an out-of-range operation type, they could skip the code that counts Toffoli gates while the operation still ran. The second was that nothing stopped an operation’s inputs and output from being the same qubit, which allowed irreversible classical logic that no quantum computer could run [5].
Google has patched the checker, and its scientific claims stand [5]. The lesson I take from it is about where trust goes. A zero-knowledge proof does not remove the need to trust someone; it moves the trust from the authors’ claims to the checker’s code, the zkVM and the proof system. That is still a big improvement, because code can be audited and a bug, once found, is fixed for everyone. But “verified by a zero-knowledge proof” is a statement about software, and software has bugs.
Solana is exposed in a different way
For Solana, the nine-minute race is irrelevant: at 400 milliseconds a slot, a transaction settles long before any foreseeable attack finishes. The problem is at-rest exposure. A Solana address is the public key itself, so every account is exposed the moment it exists, not only when it spends. The paper puts Solana with Ethereum and the XRP Ledger in the category of chains where long-term exposure of public keys is unavoidable [2], and Project Eleven’s chief executive put it more bluntly: “In Solana, 100% of the network is vulnerable” [6].
The fixes are expensive for a chain built on speed. In tests with Project Eleven, post-quantum signatures were 20 to 40 times larger than today’s, and the network ran about 90% slower [6]. In the meantime, Winternitz vaults, which lock funds behind one-time hash-based signatures, can protect coins that do not move often [2]. I think one-time signatures fit another case well: short-lived wallets, such as the ones an AI agent uses to trade for a few hours, where each key needs to sign only once or a handful of times.
Other chains are moving. This week, Ripple published a four-phase plan to move the XRP Ledger to post-quantum signatures by 2028, starting with an emergency plan in case a quantum computer arrives early [7]. Google itself is working to a 2029 timeline for its own migration [1], and France’s cybersecurity agency, ANSSI, has told government ministries to inventory their systems in 2026 and 2027 and to deploy post-quantum cryptography by 2030 [8].
What I take from it
First, the estimate is credible, and the direction matters more than the number. Most per-qubit specifications in the paper have already been shown on real hardware. The missing piece is scale, and scale is an engineering problem, not a physics one.
Second, the clock speed of the hardware decides which attack comes first. For fast superconducting machines, live transactions and old coins become vulnerable at about the same time. Chains that expose public keys permanently, Solana among them, are exposed from day one either way.
Third, zero-knowledge proofs are a good way to disclose a dangerous result, but the proof only covers what the checker checks. Anyone who relies on “verified by ZK” should ask what was verified.
Nothing in the lab makes me think the first cryptographically relevant quantum computer is close. But a migration takes years, and the attacks always get better.
References
- Ryan Babbush and Hartmut Neven. Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly. Google Research blog, 31 March 2026. research.google.
- Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar, Hartmut Neven, Thiago Bergamaschi, Justin Drake and Dan Boneh. Securing elliptic curve cryptocurrencies against quantum vulnerabilities: resource estimates and mitigations. March 2026, version 2 of 15 April 2026. arXiv:2603.28846.
- Google Quantum AI and collaborators. Quantum error correction below the surface code threshold. Nature 638, 920–926, 2025 (published online 9 December 2024). doi:10.1038/s41586-024-08449-y.
- Bradley Peak. Why Vitalik believes quantum computing could break Ethereum's cryptography sooner than expected. Cointelegraph, 1 December 2025. cointelegraph.com.
- Keegan Ryan. We beat Google's zero-knowledge proof of quantum cryptanalysis. Trail of Bits blog, 17 April 2026. blog.trailofbits.com.
- Margaux Nijkerk. Solana's quantum-threat readiness reveals harsh tradeoff: security vs speed. CoinDesk, 4 April 2026. coindesk.com.
- Omkar Godbole. Ripple wants the XRP Ledger to be quantum-proof by 2028. Here is its plan. CoinDesk, 21 April 2026. coindesk.com.
- ANSSI. Publication de la feuille de route des efforts prioritaires en matière de sécurité numérique de l'État 2026-2027. 9 April 2026. cyber.gouv.fr.