jakiro
Author: Vitalik Buterin; Compiled by: Deng Tong, Bitchain Vision
Suppose that quantum computers are announced tomorrow and that 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 cryptography (e.g. Winternitz signature, STARK), and once the account is abstracted into place, any user can switch to the quantum signature scheme as they plan.But what if we don’t have that much time and the sudden quantum transfer happened long before that?
I think, in fact, we are ready,A very simple recovery fork can be made to deal with this situation.Blockchain will have to hard fork, and users will have to download new wallet software, but few users will lose money.
The main challenges of quantum computers are as follows.The 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 a public key.Using quantum computers, elliptic curve multiplication becomes reversible (because it is a discrete logarithmic problem), but hashing is still safe.If the user has not made any transactions with their account, only the address is publicly visible and they are already secure.However, if a user makes a transaction, the signature of that transaction will reveal the public key, which allows the disclosure of the private key in the post-quantum world.Therefore, most users are vulnerable to attacks.
But we can do better.The key understanding is that in practice,Most users’ private keys are the result of a bunch of hash calculations themselves.Many keys are generated using BIP-32, which generates each address through a series of hash values starting from the main seed phrase.Many non-BIP-32 key generation methods work similarly, for example: If a user has a brain wallet, it is usually a series of hash values (or moderately difficult KDFs) applied to certain passwords.
This meansThe natural structure of EIP is restored from quantum emergencies through hard bifurcated chains:
-
Recover all blocks after the first block that clearly had a massive theft;
-
Traditional EOA-based transactions are disabled;
-
Added a new transaction type to allow transactions from smart contract wallets (such as part of RIP-7560) if not available yet;
-
Add a new transaction type or opcode, through which you can provide STARK proof, proof (i) private image x, (ii) hash function ID from k approved hash function list 1 <= i <k, (iii) Public address A, such that keccak(priv_to_pub(hashes[i](x)))[12:] = A.STARK also accepts the hash value of the new verification code as a public input account.If the proof passes, your account code will switch to a new verification code, from then on you will be able to use it as a smart contract wallet.
For Gas efficiency reasons (after all STARK is very large), we can make STARK a batch proof, proving the N STARKs of the above type (must be STARK-of-STARK directly, rather than proving multiple declarations directly, because each user’sx requires confidentiality of the aggregator).
In principle,Infrastructures that implement such hard forks can begin construction tomorrow, thus making the Ethereum ecosystem fully prepared in case a quantum emergency does occur.
