Vitalik: How to protect user funds in the event of sudden quantum attacks

Author: Vitalik Buterin; Compiler: Deng Tong, Golden Finance

Suppose it is announced tomorrow that quantum computers are available, and bad actors already have access to them and are able to use them to steal users' funds. Preventing this from happening is the goal of quantum-resistant cryptography (e.g. Winternitz signatures, STARKs), and once account abstraction is in place, any user You can switch to quantum-resistant signature schemes on your own terms. But what if we don’t have that much time, and the sudden quantum shift happened long before that?

I think, actually, we are ready to make a very simple recovery fork to deal with this situation. The blockchain will have to hard fork and users will have to download new wallet software, but few users will lose funds.

The main challenges of quantum computers are as follows. An Ethereum address is defined as keccak(priv_to_pub(k))[12:], where k is the private key and priv_to_pub is the elliptic curve multiplication that converts the private key to the public key. With quantum computers, elliptic curve multiplication becomes reversible (because it is a discrete logarithm problem), but hashing is still secure. If the user has not made any transactions using their account, only the address is publicly visible and they are already safe. However, if a user makes a transaction, the signature of that transaction reveals the public key, which in a post-quantum world allows the private key to be revealed. Therefore most users are vulnerable.

But we can do better. The key realization is that, in practice, most users' private keys are themselves the result of a bunch of hash calculations. Many keys are generated using BIP-32  which generates each address from a series of hashes starting with the main seed phrase. Many non-BIP-32 key generation methods work similarly, such as: If the user has a brain wallet, it's usually a series of hashes (or a KDF of medium difficulty) applied to some password.

This means that The natural structure of EIP is to recover from quantum emergencies by hard forking the chain:< /strong>

1. Restore the first apparent massive theft All blocks after the block;

2. Traditional EOA-based transactions are disabled;

3. New transactions have been added type to allow transactions from smart contract wallets (e.g. part of RIP-7560) if not already available;

4. To add a new transaction type or opcode, you can It provides a STARK proof that (i) the private preimage x, (ii) the hash function ID 1 <= i < k from the list of k approved hash functions, (iii) the public address A such that keccak (priv_to_pub(hashes[i](x)))[12:] = A. STARK also accepts the hash of this new verification code as a public input account. If the proof passes, your account code will be switched to the new verification code and you will be able to use it as a smart contract wallet from that point on.

For reasons of Gas efficiency (after all, STARK is large), we can make STARK a batch proof, proving that N STARKs of the above type (must be STARK-of- STARK, instead of directly proving multiple claims, since each user's x needs to be kept secret from the aggregator).

In principle,the infrastructure to implement such a hard fork could begin tomorrow, allowing Ethereum to The ecosystem is well prepared in case a quantum emergency does occur.