Docs · Quantum emergency plan▾
Overview

The quantum emergency plan

In March 2024, Vitalik Buterin described how Ethereum could still protect most users if powerful quantum computers arrived suddenly. This page explains that plan in plain language, and where Winternitz fits in it.

How an address is made#

Almost every Ethereum address comes from a recovery phrase through a chain of steps. Most are hashes, and one is elliptic-curve math.

Recovery phrase

24 words

BIP-39, BIP-32↓one-way

Private key

signs

secp256k1↓quantum reverses

Public key

64 bytes

Shown by every signature

Keccak-256↓one-way

Address

20 bytes

Every step is easy to compute from left to right. The phrase is hashed into a private key (BIP-39 and BIP-32), and the address is the last 20 bytes of the public key's Keccak-256 hash; neither can be reversed, even by a quantum computer. The curve step can: Shor's algorithm finds the private key from the public key, which every signature (r, s, v) reveals.

The difference between the two kinds of step is the whole story:

  • Hashes are one-way. Keccak-256 and the hashing inside BIP-39 and BIP-32 cannot be run backwards. A quantum computer only speeds up guessing (Grover's algorithm), which still leaves them far out of reach.
  • The curve step is not. ECDSA assumes nobody can work out a private key from its public key. Shor's algorithm, on a large enough quantum computer, does exactly that.

An address that has never sent a transaction only shows its hash, so its public key stays hidden. As soon as it signs, the signature reveals the public key, and it stays on-chain forever. That is why public keys collected today could be attacked later.

The plan, step by step#

The proposal is an emergency hard fork, for the day it becomes clear that quantum computers are being used to steal funds.

  1. 1

    Roll back

    Blocks after large-scale theft becomes obvious are reverted, returning stolen funds.

  2. 2

    Stop ECDSA

    Ordinary transactions signed with an account's ECDSA key are no longer accepted.

  3. 3

    Prove the seed

    A new transaction type carries a STARK proving you know the words your key was derived from.

  4. 4

    Smart-contract validation

    The account carries on as a smart-contract wallet, with rules that do not depend on ECDSA.

What each user proves in step 3

“I know a recovery phrase that, hashed into a private key, gives a public key whose Keccak-256 hash ends in address A.”

The proof reveals nothing about the phrase. Thousands of proofs can be combined into one (a STARK of STARKs) to keep the cost low.

A thief with a quantum computer may hold your private key, but not the words it came from, because that would mean reversing hashes. Only the real owner can produce the proof.

The key insight is in step 3. Most private keys are themselves the result of hashing a recovery phrase. A quantum attacker can recover the private key from a public key, but cannot get from the private key back to the words, because that would mean reversing hashes. So knowledge of the words becomes the new proof of ownership, and a STARK lets you prove it without revealing them.

STARKs are themselves built only from hashes, which is why the proof is quantum-safe too.

What the plan cannot cover#

The plan is a rescue, and it has limits:

  • It needs a hard fork. The community has to agree on it, under time pressure, after an attack has already begun.
  • Some keys cannot be proven. Keys that were not derived from a recovery phrase, for example raw keys generated directly, have no hash preimage to prove.
  • Users still have to act. Each owner must generate and submit a proof to move their account to the new rules.

Where Winternitz fits#

The plan ends with accounts moving to smart-contract validation. A Winternitz account starts there: it is a smart-contract account (ERC-4337) whose signatures are hash-based from its very first transaction.

Ordinary address

ECDSA, an EOA

Public key exposed by its first transactionWaits for an emergency hard forkProves the seed with a STARKMoves to smart-contract validation

Winternitz account

ERC-4337, WOTS

Smart-contract validation with hash-based signatures, from its first transaction
The emergency plan rescues ordinary addresses after the fact. A Winternitz account already ends where that rescue ends, so it has nothing to wait for.

So a Winternitz account does not depend on the emergency plan happening, or happening in time. It also uses a 24-word recovery phrase like the one in the proof statement above, so moving to it feels familiar.

For existing addresses, the Future work page describes a readiness check and a guided migration that follow this plan.

Read the original

Vitalik Buterin, How to hard-fork to save most users' funds in a quantum emergency, ethresear.ch, March 2024. The diagrams on this page are our own illustration of the post, not part of it.