Ethereum and Quantum Computing

Ethereum's quantum exposure is usually discussed as though it were Bitcoin's. It shares a curve with Bitcoin, so the headline number is the same, but the exposure profile is worse in one specific way and considerably better in another. Both are worth understanding, and both are calculable.

The same curve, the same number

Externally owned accounts sign with ECDSA over secp256k1, the same 256-bit curve Bitcoin uses. The resource estimate is therefore identical. An elliptic curve discrete logarithm over an n-bit prime field needs roughly 9n logical qubits:

9 x 256 = 2,304 logical qubits

At 0.1% physical error rate:   2,304 x 1,682 = 3,875,328 physical
At 0.01% physical error rate:  2,304 x   450 = 1,036,800 physical

The physical figure depends on surface-code overhead at a target logical error rate of 1e-15, and that overhead is driven by gate fidelity rather than by anything about Ethereum. The full working, including why the threshold row matters more than any other, is on the cryptography benchmark page, and the chain-specific mechanics of key exposure are worked through in the Bitcoin article.

For scale, the largest processor available through this platform is 108 physical qubits with no error correction. Machines above a thousand physical qubits exist elsewhere, and QuEra has demonstrated 96 logical qubits from 448 physical ones. The gap is four orders of magnitude, and it is closing on fidelity rather than on qubit count.

Where Ethereum is worse off than Bitcoin

This is the part that gets missed, and it is structural rather than incidental.

Bitcoin's pay-to-public-key-hash outputs store a hash of the public key. An address that has received funds and never spent them has never revealed a key, and a hash is not vulnerable to Shor's algorithm. A meaningful share of Bitcoin therefore sits behind keys that are not exposed to this attack at all.

Ethereum has no equivalent. An externally owned account's address is derived from the public key, and the public key is recoverable from any signature the account has produced. So the moment an account sends its first transaction, its public key is on-chain forever, derivable by anyone. There is no dormant, never-spent state that keeps a key hidden.

The practical consequence: essentially every EOA that has ever transacted is in the exposed set, permanently. Not at risk today, since the hardware does not exist, but enumerable today and stored against the day it does. The ledger is the harvest, and it happened years ago.

The second surface: validator signatures

The consensus layer does not use secp256k1. Validators sign with BLS over BLS12-381, chosen because BLS signatures aggregate, which is what makes a beacon chain with hundreds of thousands of validators tractable.

BLS security rests on discrete logarithms in pairing-friendly groups, which Shor's algorithm also breaks. Applying the same 9n construction to a 381-bit base field gives roughly 3,429 logical qubits, and at the same overheads:

9 x 381 = 3,429 logical qubits

At 0.1% physical error rate:   3,429 x 1,682 = 5,767,578 physical
At 0.01% physical error rate:  3,429 x   450 = 1,543,050 physical

That figure deserves a caveat the secp256k1 one does not. The 9n form is the standard estimate for elliptic curve discrete logs over prime fields, and pairing-friendly curves have additional structure. Treat the BLS number as an extrapolation of the same construction rather than a published estimate specific to BLS12-381. The order of magnitude is the useful part, and the order of magnitude says the consensus layer is a larger target than the account layer, not a smaller one.

What is not at risk

Keccak-256, and hash functions generally, are only quadratically weakened. Grover takes a 256-bit preimage search from 2^256 to about 2^128, which is not a number that becomes tractable, and the quadratic speedup assumes serial oracle queries besides. Hash-based security is weakened on paper and untouched in practice.

This matters more for Ethereum than it first appears, because it determines which parts of the L2 ecosystem inherit the problem. STARK-based systems rest on hash functions and collision resistance, so they are quantum-safe in the relevant sense. SNARK constructions built on pairings are not, and inherit the same exposure as BLS. A rollup's cryptographic assumptions decide its exposure, and the two families differ.

Where Ethereum is better off than Bitcoin

Account abstraction is the genuine structural advantage, and it is not a small one.

Bitcoin's migration path to post-quantum signatures runs through a soft fork: the signature scheme is part of the protocol, so changing it requires coordinated consensus change and every holder moving funds to new outputs. A migration requiring universal holder action does not complete.

Ethereum can validate signatures in contract code. An account can specify its own verification logic, which means a post-quantum scheme can be adopted per account without changing the base protocol's signature rules. The migration becomes an application-layer decision rather than a consensus fork, and accounts can move at their own pace.

That does not solve the exposed-key problem, since already-published keys stay published, and it does not cover the consensus layer, which is a protocol change either way. But it makes the account-layer transition cheaper than the equivalent on a chain where the signature scheme is welded to the protocol. It is the strongest quantum-resistance argument Ethereum has, and it is architectural rather than cryptographic.

What the timeline actually depends on

Not qubit count. Gate fidelity.

The overhead table above says it plainly: at a 1 percent physical error rate error correction does not work at all, at 0.1 percent each logical qubit costs 1,682 physical ones, and at 0.01 percent it costs 450. A tenfold improvement in fidelity cuts the physical requirement by nearly a factor of four. A processor with a thousand physical qubits and a 0.5 percent error rate is further from breaking anything than a smaller machine with 0.01 percent.

So when a headline announces a qubit count, the number that would tell you something is the one usually not in the headline. Track two-qubit gate fidelity and logical error rates. Everything else is packaging.

The standardised replacements and the broader migration picture are covered in the post-quantum cryptography primer.

The honest uncertainty

The weakest assumption in every figure above is the surface-code overhead: a generic code, a specific target logical error rate, and no algorithmic co-design. All three are being actively improved by people whose job that is. If overhead falls another order of magnitude, secp256k1 lands near 40,000 physical qubits and the conversation changes shape.

The direction is not uncertain, and neither is the exposure. Ethereum's public keys are already published. That part is done, and no future engineering undoes it.

Running the algorithms yourself

The algorithms in this article are runnable at sizes that fit, and the accuracy of every result is stated rather than assumed. A 40-qubit tensor-network job, for instance, reports a discarded weight of 1.887e-14 and therefore a measured error bound of 1.943e-07, published at api.zksf.org/certify/11f4e32a020a43ca with no account required to read it. That is the standard every approximate result here is held to, which is the opposite of how most quantum claims arrive.

Start in the browser with no signup at the circuit sandbox, or run the same circuits on hosted engines past 1,000 qubits and on real quantum processors from four vendors through a single API. The Android app runs the same engines from a phone. The applications benchmarks carry the full cryptographic resource estimation alongside the industrial problems where classical computing still wins, which is most of them, and we publish those too.