Could Quantum Computers Break Ethereum? How Real the Risk Is—and What Comes Next

Could Quantum Computers Break Ethereum?

In late 2025, Vitalik Buterin did something unusual: he put a number on a risk that’s often treated as science fiction.

Relying on forecasting platform Metaculus, he argued there’s roughly a 20% chance that quantum computers powerful enough to break today’s cryptography will arrive before 2030, and that Ethereum should behave as if that risk is serious enough to prepare for.

He has since sharpened that message, warning that elliptic curve cryptography—the core of Ethereum’s current security model—could be vulnerable by 2028 under optimistic assumptions for quantum progress.

This doesn’t mean “quantum computers can break Ethereum today.” They can’t.

It does mean that over the next decade, there is a realistic chance that machines appear which can attack the cryptography securing billions of dollars in Ethereum assets. And if that happens, moving the network to safer foundations will take years, not months.

This article focuses on two questions:

How realistic is the quantum threat to Ethereum, actually?
What concrete solutions and migration paths are on the table?

Why Quantum Computing Threatens Ethereum’s Cryptography

Most of Ethereum’s security rests on a mathematical problem called the elliptic curve discrete logarithm problem (ECDLP).

Ethereum uses:

Private key: a large random 256-bit number.
Public key: a point on the elliptic curve derived from that private key.
Address: a hash of the public key.

On classical computers, going from private key → public key is easy, but going public key → private key is computationally infeasible. That asymmetry is the whole point.

Quantum computers change that asymmetry.

Shor’s Algorithm in a Nutshell

In 1994, Peter Shor introduced an algorithm that shows a sufficiently powerful quantum computer could solve:

Integer factorization (breaking RSA)
Discrete logarithms (breaking Diffie–Hellman & elliptic curve schemes like ECDSA)

in polynomial time. That’s a qualitative leap over classical brute force.

Both the Internet Engineering Task Force (IETF) and NIST agree: once cryptographically relevant quantum computers (CRQCs) exist, all widely used public key systems today—RSA, Diffie–Hellman, ECDSA—become insecure.

In Ethereum’s case, the main concern is ECDSA over secp256k1, used for:

Externally owned accounts (EOAs)
Many multisigs and treasury wallets
Some infrastructure components and tooling

A Subtle but Important Detail: Public Keys on Chain

Vitalik highlights a key nuance for Ethereum:

If an address has never sent a transaction, only the hash of the public key is visible on-chain. A hash of a public key is believed to be quantum-safe for now.
Once you spend from an address, the public key is revealed on-chain.

A future quantum attacker could:

Scan the Ethereum blockchain for any address with a revealed public key.
Use a large quantum computer running Shor’s algorithm to derive the corresponding private key.
Drain the account.

That means:

The risk isn’t that quantum computers break Keccak (Ethereum’s hash function) or its basic data structures.
The risk is that a critical mass of addresses with exposed public keys—which includes a large number of user wallets and smart contract treasuries—becomes vulnerable at once.

How Realistic Is the Timeline?

Vitalik did not invent his numbers; he leaned on Metaculus and broader expert signals.

Hardware Reality Check

Recent public milestones include:

Google Willow (2024): 105 physical qubits, with error-corrected logical qubits that can outperform classical supercomputers on narrow benchmarks.
IBM roadmap: aims to demonstrate fault-tolerant quantum computing by around 2029.

Yet, even Google’s own quantum AI team has been clear:

The Willow chip is not capable of breaking modern cryptography.

Academic estimates suggest that breaking 256-bit elliptic curve cryptography in ~1 hour could require:

Tens to hundreds of millions of high-quality physical qubits
With robust error correction (e.g., surface codes)

This is orders of magnitude beyond today’s devices.

Policy and Standards Bodies’ View

On the cryptography and policy side:

NIST has run a multi-year Post-Quantum Cryptography (PQC) competition.
In 2024, it standardized the first round of post-quantum schemes:
- ML-KEM (key encapsulation)
- ML-DSA and SLH-DSA (digital signatures)

The US government now expects federal agencies to migrate to PQC by the mid-2030s, and a joint NIST/White House report estimates ~$7.1B just to upgrade federal IT.

This tells us two things:

Experts believe Q-Day (when quantum becomes a practical cryptanalytic threat) is likely within the next 10–20 years, but not in the immediate present.
The migration cost and lead time are enormous, even for centralized entities—let alone a decentralized global network like Ethereum.

Vitalik’s “20% by 2030” and “possibly before 2028” framing sits roughly in the pessimistic-but-plausible end of mainstream estimates. The key point is uncertainty plus migration time, not that someone already has a secret code-breaking machine.

Vitalik’s “Quantum Emergency” Plan

Vitalik’s 2024 research post, “How to hard-fork to save most users’ funds in a quantum emergency,” asks a brutal question:

What if a large quantum computer goes online suddenly and attackers start draining ECDSA wallets before Ethereum has migrated?

His proposed response is not elegant—it’s a disaster-recovery protocol, not a preferred roadmap.

1. Detect and Roll Back

Once the community detects clear on-chain evidence of quantum-executed thefts at scale:

Ethereum would revert the chain to the last block before those thefts were visible.

This is politically and technically messy, but it buys time.

2. Freeze Legacy EOAs

Next, the protocol would:

Disable traditional EOA transactions that rely on ECDSA.

This stops attackers from continuing to drain exposed accounts, at the cost of freezing normal activity for those addresses.

3. Move Funds via Quantum-Resistant Smart Contract Wallets

To restore user control, Vitalik proposes a new transaction path:

Users generate a zero-knowledge STARK proof that they control the original seed/derivation path (e.g., a BIP-32 HD wallet preimage) corresponding to their vulnerable EOA.
That proof includes instructions to move the funds into a quantum-resistant smart contract wallet with new verification logic.

After verification:

The old EOA is effectively retired.
Control is now held by a smart contract that can enforce post-quantum signatures or other stronger schemes.

4. Batch Proofs for Practicality

ZK-STARK proofs are large and computationally heavy.

Vitalik’s plan anticipates batching:

Specialized aggregators collect many users’ proofs.
Submit them in batches to minimize gas costs while keeping each user’s secret data private.

Why This Matters Even If It Never Happens

Vitalik stresses this as Plan Z, not Plan A.

The practical takeaway is that being able to execute such a fork at all requires infrastructure Ethereum is already working on for other reasons:

Account abstraction (smart contract wallets as first-class citizens)
Robust zero-knowledge proof systems
Standardized post-quantum signature schemes

By treating “quantum emergency survivability” as a non-negotiable design constraint, Ethereum is nudged toward more flexible, upgradable cryptographic plumbing across the stack.

What Needs to Change in Ethereum

Assuming quantum progress continues—even if more slowly than the worst-case scenarios—the Ethereum ecosystem needs to prepare at three layers:

Wallets and user accounts
Core protocol and primitives
Social and governance mechanisms

1. Move from EOAs to Smart Contract Wallets

Plain externally owned accounts (EOAs) are tightly coupled to one signature scheme (secp256k1 + ECDSA). That makes migration painful.

Account abstraction—via standards like ERC-4337—lets users adopt smart contract wallets that:

Can define custom signature validation logic.
Can upgrade that logic later without changing the user’s visible address (depending on design).
Support features like social recovery, multi-sig, and rate limiting.

If most users are on smart contract wallets, then:

Migrating from ECDSA to post-quantum signatures becomes a matter of upgrading contract code, not forcing everyone to move funds to a new address in a panic.

Some projects already demonstrate Lamport or XMSS (eXtended Merkle Signature Scheme)-based quantum-resistant wallets on Ethereum as proofs of concept.

2. Adopt Post-Quantum Signature Schemes

Ethereum will need one or more post-quantum-safe signature algorithms for:

User authentication (wallet signatures)
Validators and consensus
Smart contract infrastructure

Likely candidates include:

NIST PQC signatures like ML-DSA and SLH-DSA.
Hash-based signatures (XMSS, LMS, SPHINCS+), which are conceptually simple and well-studied.

Each family comes with trade-offs:

Key size and signature size (affecting storage and gas)
Verification cost (affecting transaction throughput)
One-time vs. many-time usage semantics (e.g., some hash-based schemes are stateful)

Ethereum needs to:

Prototype these schemes on testnets.
Benchmark cost and performance.
Design transition formats so wallets can support both classical and post-quantum signatures during a long overlap period.

3. Build Crypto-Agility Into the Rest of the Stack

Elliptic curves in Ethereum are not just for EOAs.

They underpin:

BLS signatures (used in the consensus layer and some multisigs)
KZG commitments for data availability and polynomial commitments
Some rollup proving systems and layer-2 constructions

A robust quantum-resilient roadmap will need:

PQC-friendly replacements for BLS and KZG where possible.
Hybrid designs that allow both classical and post-quantum proofs/commitments during migration.
Careful performance engineering, since many PQC schemes are heavier than their elliptic curve counterparts.

In effect, Ethereum needs to become crypto-agile: able to swap out primitives without destabilizing the protocol.

4. Social and Governance Mechanisms

Even perfect cryptography cannot avoid the human dimension.

If Ethereum ever needs to:

Roll back blocks
Freeze legacy accounts
Mandate mass migrations

…it will be contentious.

Vitalik and other researchers have suggested:

Quantum canary mechanisms:
Deploy small, intentionally vulnerable test assets or keys and monitor them. If they are broken, that’s an early warning signal that CRQCs are real and active.
Gradual, opt-in migration:
Encourage users and institutions to adopt post-quantum-capable wallets long before any clear threat, so that by the time a Q-Day looms, most value is already protected.

How Realistic Is All This—Really?

Summarizing the landscape:

Today (mid-2020s):
Public quantum hardware is far too weak to break Ethereum’s cryptography. There is no realistic, immediate quantum threat to Ethereum keys.
Next ~10 years:
Most expert forecasts cluster around a 10–20-year horizon for truly cryptographically relevant quantum computers, with a nontrivial tail risk that it could be earlier (late 2020s) under aggressive hardware progress and error correction breakthroughs.
Migration lead time:
Large systems, especially decentralized ones, need many years to migrate safely. That alone justifies starting serious work now.

Vitalik’s position is essentially that of a safety engineer:

You don’t evacuate an entire city because there’s a 20% chance of a major earthquake in the next decade.
You do reinforce the bridges and retrofit critical infrastructure before it’s too late.

From that perspective, treating quantum risk as “distant future only” is itself a risk.

Practical Takeaways for Users and Builders

You don’t need to panic about quantum attacks today, but you can make quantum-aware decisions that future-proof your Ethereum presence.

If You’re an Individual User

Prefer upgradable wallets:
Use wallets (often smart contract–based) that can change their signature scheme or migrate logic without forcing a full asset move.
Minimize address reuse:
Avoid reusing the same address unnecessarily, so fewer public keys are exposed on-chain.
Track Ethereum’s PQC roadmap:
As the ecosystem standardizes on one or more post-quantum signature schemes, plan to migrate early, not at the last moment.

If You’re a Protocol or Infrastructure Builder

Design for crypto-agility:
Abstract away the signature and commitment layers so you can plug in post-quantum primitives later.
Experiment with PQC today:
Prototype ML-DSA, SLH-DSA, or hash-based signatures on L2s and testnets. Measure performance and gas.
Adopt account abstraction patterns:
Make your dApp compatible with smart contract wallets and flexible verification logic.
Plan social processes:
Think through governance and coordination for a potential mass migration, even if it’s never used.

Conclusion: Designing Ethereum for a Quantum World

Quantum computers are not yet a direct threat to Ethereum. Current devices lack the scale and error correction required to attack elliptic curve cryptography.

But there is a credible, non-negligible chance that this changes within the next couple of decades—and a smaller but real chance that it arrives earlier than most people expect.

Because migrating a global, decentralized financial system is slow and politically complex, the correct strategy is not fear, but early engineering:

Move users from fragile EOAs to flexible smart contract wallets.
Standardize and battle-test post-quantum signature schemes.
Build crypto-agility into every layer of the stack.
Design and socialize emergency plans, even if they remain unused.

In the long run, Ethereum’s resilience will depend less on whether quantum computing arrives in 2028 or 2040, and more on whether the ecosystem treats this as a serious but solvable engineering problem rather than a plot device from science fiction.

The work has already started. The question is how quickly the ecosystem chooses to follow through.