Ethereum Validator Keys and Quantum Computing

Everything here is runnable on your own circuit. Try it in the console

Ethereum's quantum exposure is usually discussed as though it were Bitcoin's. The account layer is: same curve, same number, and that part is worked through in the Bitcoin article because nothing about it is Ethereum-specific.

What is Ethereum-specific is a second set of keys Bitcoin has no equivalent of, on a different curve, securing consensus rather than balances. That is the larger target and the more interesting problem, so it goes first here.

The surface Bitcoin does not have

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 textbook 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 textbook estimate for elliptic curve discrete logs over prime fields, pairing-friendly curves have additional structure, and the methods that brought the 2026 estimates for secp256k1 far below 9n would plausibly lower this figure too.

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 account surface, shared with Bitcoin

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

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.

The estimates published in 2026 for this curve are far lower than the textbook figure: under 500,000 physical qubits running for minutes on superconducting hardware, and about 10,000 to 26,000 on neutral atoms or trapped ions running for days to months. The dated comparison, with sources, is 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 closing on fidelity and error correction rather than on qubit count.

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.

Where the estimates are heading

The textbook figures above assume a generic error-correcting code, a fixed target logical error rate and no co-design between algorithm and hardware. The 2026 estimates for secp256k1 improved on all three and landed between about 10,000 and 500,000 physical qubits, so read the BLS figure the same way: an upper bound, not a forecast.

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.

Shor's discrete logarithm algorithm, run against real elliptic curves of the same form as secp256k1, recovered private keys from public keys up to 7 bits on our CPU and GPU tiers:

Run on our engines

Shor's discrete logarithm algorithm on real elliptic curves y² = x³ + ax + b over F5 to F107, recovering each private key from its public key at 64 shots. On 25 September the 7-bit recovery ran again on exact.tpu, a Google TPU, recovering the same key from 25 usable shots in 271 seconds. Submitted to each kind of compute we offer, on 10, 24 and 25 September 2026. Every figure below is a real job on the service, priced as any customer would be priced.

Device	Engine	Kind	Qubits	Result	Cost
	exact.cpu	CPU	9	3-bit key recovered, d = 7, in 0.14 s *	$0.0001
	exact.cpu	CPU	12	4-bit key recovered, d = 11, in 0.57 s *	$0.0001
	exact.cpu	CPU	15	5-bit key recovered, d = 19, in 8.40 s *	$0.0002
	exact.cpu	CPU	18	6-bit key recovered, d = 35, in 6.70 s *	$0.0002
	exact.cpu	CPU	21	7-bit key recovered, d = 67, in 70.5 s *	$0.0020
	exact.gpu	GPU	21	7-bit key recovered, d = 67, in 66 s certificate	$0.1066
	exact.tpu	TPU	21	7-bit key recovered, d = 67, in 271 s certificate	$0.4534
	neural.tpu	TPU	—	Shor's algorithm is a circuit, not a Hamiltonian, so it does not reach the neural tier	—

* Run in-process on the exact.cpu engine rather than submitted as billed jobs. Each cost is the measured runtime priced at the rate the service quotes for CPU work, with its $0.0001 minimum. The steps are in the docs.

The same problem is yours to run: every instance here is seeded, so it rebuilds exactly. Open the console and a cost estimate is free before anything executes.

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.