Futures
Access hundreds of perpetual contracts
TradFi
Gold
One platform for global traditional assets
Options
Hot
Trade European-style vanilla options
Unified Account
Maximize your capital efficiency
Demo Trading
Introduction to Futures Trading
Learn the basics of futures trading
Futures Events
Join events to earn rewards
Demo Trading
Use virtual funds to practice risk-free trading
Launch
CandyDrop
Collect candies to earn airdrops
Launchpool
Quick staking, earn potential new tokens
HODLer Airdrop
Hold GT and get massive airdrops for free
Pre-IPOs
Unlock full access to global stock IPOs
Alpha Points
Trade on-chain assets and earn airdrops
Futures Points
Earn futures points and claim airdrop rewards
The impact of Google's quantum computing on Ethereum security
Author: ChainLink Community
Original link:
Disclaimer: This article is a reprint. Readers can obtain more information through the original link. If the author has any objections to the reprint, please contact us, and we will make modifications according to the author’s requirements. Reprints are for information sharing only and do not constitute any investment advice or represent Wu Shuo’s views and positions.
Although quantum computing still carries a strong hype aspect, with the improvement of Shor’s algorithm efficiency, Ethereum account security, consensus mechanisms, and Layer 2 proof systems indeed face long-term risks. When migrating to post-quantum standards from NIST, potential cryptographic backdoors should be guarded against.
Background (Context)
Researchers from Google, Berkeley, Stanford, and the Ethereum Foundation published a paper on substantive quantum algorithm optimization and its impact on cryptocurrencies.
Some necessary background here is that quantum computing is largely hype. It gains attention through hype and speculation, and thus receives continuous funding.
This is not to say that it is not a substantive optimization — it indeed is — but we should be aware of this context when reading about quantum cryptanalysis. We have time for classification and iteration, and considering the history involving NSA and NIST, we should first remain skeptical of lattice (Lattice) standards recommended by NIST.
What We’re Talking About (What We’re Talking About)
The paper targets Bitcoin (presumably due to suspicion of SECP256R1/P256) and the SECP256K1 (K256) curve used by many other chains. In this analysis, we will focus on the Ethereum network because Monero uses a different curve, and Bitcoin, in this specific context, neither provides privacy nor programmability.
Monero curve (ed25519) is not explicitly targeted, although the paper mentions that breaking it might not be significantly harder than K256.
Under quantum search algorithms, finding pre-images of hash digests (such as SHA256 or KECCAK256) will indeed have slight acceleration, but this improvement is not exponential. It does not pose a reasonable threat to these hash algorithms, and the paper does not improve algorithms to attack them.
Timelines (Timelines)
NIST is usually responsible for handling U.S. government cryptography standards and security notices. The internal NIST report 8547, released in November 2024, marks that: key exchange and signature protocols based on RSA and elliptic curve discrete logarithm problems will be deprecated before 2030 and banned before 2035. This is because Shor’s algorithm can provide exponential speedup against discrete logarithm problems.
The paper demonstrates an optimization that can significantly reduce the number of logical qubits and Toffoli gates needed to attack K256 in practice. It recommends deprecation sooner rather than later, although it does not specify a concrete date.
While it does not model other elliptic curves like BN254 or BLS12-381, the paper mentions that attacking them should not be significantly more difficult than K256. This makes bilinear pairings generally more vulnerable and may allow recovery of “toxic waste” in polynomial commitment systems (such as those used in zk-SNARK setups like KZG).
Risks for Ethereum (Risks For Ethereum)
The paper identifies five categories of vulnerabilities in Ethereum:
Account (Account)
Management (Admin)
Code (Code)
Consensus (Consensus)
Data Availability (Data Availability)
Account and Admin (Account and Admin)
Since account addresses are truncated hashes of K256 public keys, accounts that have not sent transactions or published signatures (such as permit signatures) do not expose their public keys. This means they are currently not threatened.
However, once an account publishes a signature, its public key can be recovered, exposing it to attack.
The “management” vulnerability refers to vulnerabilities in privileged addresses. M-of-N multi-signature accounts require M accounts to be compromised, but otherwise are unprotected. This means configurable contracts can be manipulated, and upgradeable proxy smart contracts could be replaced with drainers to steal tokens.
Code (Code)
This vulnerability refers to contracts relying on precompiled contracts (precompiles) that do not use post-quantum resistant primitives. Currently, these include:
K256 ECDSA
P256 ECDSA
KZG polynomial commitment proofs
BN254 point operations and bilinear pairings
BLS12-381 point operations and bilinear pairings
P256 ECDSA precompile contracts extend account issues to smart accounts using P256 curves, such as those signed by iOS and Android secure enclaves (face ID, fingerprint) authentication.
BN254 and BLS curves are used in privacy protocols and zk-SNARKs in Layer 2 rollups. Recovering “toxic waste” from these setups would allow attackers to forge proofs on any system relying on that commitment.
Consensus (Consensus)
Ethereum uses BLS12-381 for signature aggregation in its consensus algorithm. The impact varies depending on the affected network portion:
Breaking validators: can enforce slashing.
Breaking more than 1/3: can reject finality.
Breaking more than 1/2: can influence fork choice and force deep reorganizations.
Breaking more than 2/3: catastrophic; requires out-of-network recovery.
Data Availability (Data Availability)
Ethereum’s Blob system uses data availability sampling with KZG commitments. If toxic waste in the setup is recovered, it can create forged data availability proofs, causing issues for Layer 2 systems that depend on Blob storage for state transitions.
The Post-Quantum Problem (The Post Quantum Problem)
The direct solution is migrating to lattice-based (Lattice) or hash-based systems. NIST has established the following standards:
(FIPS 203) lattice-based key encapsulation mechanisms
(FIPS 204) lattice-based digital signatures
(FIPS 205) stateless hash-based digital signatures
However, due to NSA involvement, NIST standards have historically been questioned. Past cases include the EFF DES cracker, NSA’s backdoor in Dual EC DRBG, and NIST’s lack of transparency regarding NSA’s role in post-quantum cryptography.
Experts like D.J. Bernstein emphasize the significant attack surface of lattice cryptography and the fact that these implementations are still evolving to counter new attack vectors.
Key Takeaways (Takeaways)
We still have a few years. We should proceed with rapid but cautious adjustments. Ideally, we should use modular authentication systems to facilitate faster future iterations.
We must recognize that cryptography is transient; it buys time before data becomes trivially decryptable. We also need to be aware of how agencies like NSA might attempt to introduce backdoors into post-quantum suites.