Original Title: Quantum computing and blockchains: Matching urgency to actual threats
Original Author: Justin Thaler, a16zcrypto
Translation: Peggy, BlockBeats

Editor's Note: The narrative of quantum threat is being "over-urgentized" in the market, but post-quantum transition should not be a one-size-fits-all approach. The key point of this article is: encryption should move to hybrid solutions as soon as possible, because "Harvest Now Decrypt Later" (HNDL) is already a realistic risk; however, digital signatures and zkSNARKs do not need to rush, as an early switch could bring more direct security costs such as bloating, performance regression, and implementation vulnerabilities.

The author of this article, Justin Thaler, is a16z's research partner, associate professor of computer science at Georgetown University, researching topics such as verifiable computation. He reminds the industry that the post-quantum era is not about panic-driven migration, but about directing resources to truly urgent risks.

Below is the original article:

How far are quantum computers from "being able to threaten existing cryptographic systems," the market's timetable is often overly advanced, leading to the "must immediately and fully switch to Post-Quantum Cryptography (PQC)" urgent narrative.

However, the problem is that such calls often overlook a key reality: premature migration itself comes with significant costs and new risks. More importantly, cryptographic systems are not a one-size-fits-all solution, with significant differences in the attack vectors and risk exposure of different cryptographic primitives:

The logic of post-quantum encryption is more urgent: even if the cost is high, deployment must be done as soon as possible. The reason is that "Harvest Now Decrypt Later" (HNDL) attacks are already happening—adversaries can first store today's encrypted sensitive data and decrypt it when future quantum computers actually appear. Even if quantum computers may not arrive for decades, as long as this data remains valuable at that time, it poses a real threat. Post-quantum encryption does have performance overhead and implementation risks, but for data requiring long-term confidentiality, the HNDL attack leaves us no choice.

The computation of post-quantum signatures, on the other hand, is different: they are not affected by HNDL attacks, and their costs and risks (larger size, performance overhead, immature implementation, vulnerability risks) dictate that migration should be more cautious, more rhythmic, rather than an immediate full-scale deployment.

These distinctions are crucial. Misconceptions can skew cost-benefit analysis, leading teams to overlook more pressing security risks—such as code vulnerabilities (bugs). The true challenge in advancing post-quantum cryptography lies in aligning "urgency" with "actual threat." Below, I will clarify some common misunderstandings about quantum threats and cryptography—covering encryption, signatures, zero-knowledge proofs, and emphasizing their impact on blockchain.

Where Are We Now in Terms of Timeline?

In the 2020s, the emergence of a Cryptographically Relevant Quantum Computer (CRQC) is highly unlikely, despite some high-profile claims suggesting otherwise.

By "cryptographically relevant quantum computer," I mean a fault-tolerant, error-corrected quantum computer capable of running the Shor algorithm at a sufficient scale to feasibly break elliptic curve cryptography or RSA (e.g., capable of breaking secp256k1 or RSA-2048 in roughly a month of sustained computation).

From any reasonable interpretation of publicly available milestones and resource estimates, we are still far from CRQC. Some companies claim CRQC could be achieved by 2030 or well before 2035, but publicly visible progress does not support these claims.

For comparison: across all mainstream architectures such as ion traps, superconducting qubits, and neutral atom systems, no platform comes close to the scale required to run the Shor algorithm: to attack RSA-2048 or secp256k1 often necessitates tens to millions of physical qubits (depending on error rates and error-correction schemes).

The limiting factors are not just qubit count but also gate fidelity, qubit connectivity, and error-corrected circuit depth needed to run deep quantum algorithms long-term. While some systems have surpassed 1000 physical qubits, a simple headcount can be deceiving: these systems lack the connectivity and gate fidelity required for "cryptographically relevant computation."

The physical error rates of some recent systems do approach the threshold where quantum error correction starts to become effective, but as of now, no one has demonstrated more than a few logical qubits that can be sustained under sufficiently deep error-corrected circuits—let alone the thousands of high-fidelity, deep, fault-tolerant logical qubits that Shor's algorithm truly demands.

The gap between "proof of concept for quantum error correction" and "reaching a scale big enough for cryptanalysis" is still immense.

In short: CRQC remains a distant goal until both the number of physical qubits and the fidelity are improved by several orders of magnitude.

But why is the public easily misled?

Corporate press releases and media coverage can easily create confusion, with common sources of misunderstanding including:

Some demonstrations claim to achieve "quantum advantage," but these are often targeted at artificially designed tasks that are not practical. These tasks are chosen not for their real-world value but because they can be run on existing hardware and "appear" to exhibit significant quantum speedup, a fact that is often downplayed in the announcements.

Some companies claim to have achieved "thousands of physical qubits," but this usually refers to a quantum annealer, not a gate-model quantum computer required to run the Shor algorithm.

There are companies that misuse the term "logical qubit." Physical qubits are noisy, and quantum algorithms require logical qubits; the Shor algorithm, for example, requires thousands of logical qubits. Logical qubits are typically formed by error correction with many physical qubits—each logical qubit often needs hundreds to thousands of physical qubits (depending on the error rate). However, some companies have "stretched this concept beyond recognition." For example, an announcement claimed to achieve 48 logical qubits using a distance-2 code, where each logical qubit is encoded with only two physical qubits—this is absurd: a distance-2 code can only detect errors, not correct them. True fault-tolerant logical qubits used for cryptanalysis require hundreds to thousands of physical qubits per logical qubit, not two.

More generally, in many quantum computing roadmaps, "logical qubits" refer to bits that support only Clifford operations; however, Clifford operations can be efficiently simulated by a classical computer and are therefore insufficient to run the Shor algorithm. The Shor algorithm requires a large number of error-corrected T gates (or more generally, non-Clifford gates).

Therefore, even if a roadmap says "thousands of logical qubits by year X," it does not mean that the company expects to be able to run the Shor algorithm to break classical cryptography in the same year.

These practices severely distort the public's perception of the distance to CRQC, even among some professional observer communities.

Experts Are Excited, But That Doesn't Mean "Breaking Encryption" Is Around the Corner

Indeed, some experts are excited about the progress. For example, Scott Aaronson recently wrote that given the "astonishing current rate of hardware progress," he thinks it is a "realistic possibility" to have a fault-tolerant quantum computer capable of running the Shor algorithm before the next U.S. presidential election.

But Aaronson later clarified: he is not referring to CRYPTOGRAPHIC quantum computing. Even for a fully fault-tolerant execution of the Shor algorithm that can factor 15 = 3×5, he would consider that an "achievement." Yet this computation is faster on paper with a pen. The threshold is still to run at "small scale," not at a scale "sufficient for breaking cryptographic codes."

Furthermore, why do many experiments always resort to factoring 15? Because the arithmetic modulo 15 is simple, while factoring slightly larger numbers, such as 21, is much more difficult. Therefore, experiments claiming to factor 21 often rely on additional hints or shortcuts.

In conclusion: there is no publicly known progress supporting the belief that within the next 5 years there will be a quantum computer capable of cracking RSA-2048 or secp256k1 (which is the actual concern of practical cryptography).

Even within 10 years, it is still very aggressive. Considering how far we are from CRYPTOGRAPHIC quantum computing, being excited about hardware advancements can coexist entirely with a "timeline of ten years or more."

As for the U.S. government viewing 2035 as the target deadline for a full transition of government systems to post-quantum: I believe this is a reasonable "timeline for completing a large-scale transition," but it is not a prediction that "CRYPTOGRAPHIC quantum computing will appear before 2035."

Where Does the HNDL Attack Apply (and Where Doesn't It)?

The "Harvest Now, Decrypt Later" (HNDL) attack refers to: adversaries currently storing encrypted communication traffic to decrypt it when CRQC appears in the future. Nation-state adversaries almost certainly have been archiving encrypted U.S. government communications at scale to decrypt years later.

Therefore, the encryption systems need to start transitioning today—at least for those who need confidentiality for 10-50 years or more.

However, the digital signatures on which blockchain relies are different from encryption: the signature itself does not carry "secret content," so there is no secrecy to be decrypted afterward.

In other words: if CRQC emerges, it may indeed be possible to forge a signature from that moment onwards; however, historical signatures do not "hide secrets" like encrypted messages. As long as you know a signature was generated before the appearance of CRQC, it cannot be forged.

This makes the post-quantum digital signature migration urgency far lower than the post-quantum encryption.

Therefore, mainstream platform actions also follow this rhythm:

Chrome and Cloudflare have introduced a hybrid scheme of X25519 + ML-KEM in TLS encryption.
（Note: For readability, I use "encryption scheme" here, but strictly speaking, TLS uses a key exchange or key encapsulation mechanism, not traditional public key encryption.）

The term "hybrid" refers to the simultaneous use of both post-quantum secure scheme (ML-KEM) and existing scheme (X25519) to obtain the security guarantees of both: on one hand, ML-KEM defends against HNDL, and on the other hand, even if ML-KEM is proven insecure for classical computers, the classical security of X25519 is still maintained.

Apple's iMessage deployed a similar hybrid post-quantum encryption through the PQ3 protocol; Signal also deployed a similar approach through the PQXDH and SPQR protocols.

In contrast, the deployment of post-quantum digital signatures on key internet infrastructure has been delayed until CRQC is truly imminent, as existing post-quantum signature schemes bring significant performance degradation (explained later).

The Situation of zkSNARK is Similar to Signature, Not Encryption

zkSNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is very critical for the long-term scalability and privacy of blockchain. Its situation is similar to signature: even though some zkSNARKs are not post-quantum secure (because they use elliptic curve cryptography, just like today's non-post-quantum encryption and signature schemes), their zero-knowledge nature is still post-quantum secure.

Zero-knowledge nature means the proof will not reveal any information about the "secret witness," even in the face of a quantum adversary, so there is no confidential content that can be "collected first, then decrypted."

Therefore, zkSNARK is not susceptible to HNDL attacks. Just like today's generated non-post-quantum signatures are still reliable, as long as a zkSNARK proof was generated before CRQC appears, it is trustworthy (the proposition of the proof must be true), even if the zkSNARK uses elliptic curve cryptography. Only after CRQC appears, attackers may forge a proof of "seemingly trustworthy but actually false proposition."

What Does This Mean for Blockchain?

Most blockchains are not exposed to the HNDL attack: non-privacy-focused chains like Bitcoin and Ethereum primarily use post-quantum cryptography for transaction authorization, meaning they use digital signatures instead of encryption. Signatures are not an HNDL risk point: HNDL targets encrypted data. For example, the Bitcoin chain is public, and the quantum threat is "signature forgery (deriving private keys to steal coins)" rather than "decrypting transaction data that is already public." Therefore, HNDL does not bring about an "immediate must migrate" cryptographic urgency.

Unfortunately, even trusted sources like the Federal Reserve have at times incorrectly claimed that Bitcoin would be vulnerable to the HNDL attack, leading to an exaggeration of the urgency of quantum migration.

Of course, reduced urgency does not mean Bitcoin can take its time: its time pressure comes from another source—the significant social coordination cost required to change the protocol. (The following text will discuss Bitcoin's specific challenges.)

The real current exception is privacy chains: many chains in this category encrypt or hide the recipient and amount. This level of confidentiality can be "harvested now" and de-anonymized in the future by quantum computers after breaking elliptic curve cryptography.

The severity of attacks on privacy chains depends on their specific design. For example, Monero's ring signature and key image-based structure, designed to prevent double-spending, may allow for a significant reconstruction of historical spending from a public ledger alone. On the other hand, some privacy schemes may suffer less damage—details can be found in discussions by Zcash's cryptography engineer and researcher, Sean Bowe.

If users are very concerned that their transactions will not be exposed after the arrival of CRQC, privacy chains should quickly migrate to post-quantum primitives (or hybrid schemes) or adopt architectures that avoid writing decryptable secrets on-chain.

Bitcoin's "Special Headache": Governance + Dormant Coins

For Bitcoin, two real-world factors are driving the need for early planning of a post-quantum signature migration—and both are unrelated to quantum technology:

Governance speed: Bitcoin upgrades very slowly. Any contentious issue could lead to a disruptive hard fork if the community cannot agree.

Migration cannot be passive: Bitcoin's transition to post-quantum signatures cannot happen "automatically"; coin holders must actively move their assets. In other words, dormant, quantum-vulnerable coins will be left unprotected. Some estimates suggest that such potentially dormant and quantum-vulnerable BTC could number in the millions and be worth hundreds of billions of dollars at December 2025 prices.

However, the quantum threat to Bitcoin will not be an overnight doomsday event, but more like a "selective, incremental" attack process. Quantum computers will not break all keys at once: the Shor algorithm needs to attack public keys one by one. Early quantum attacks will be extremely expensive and slow. Therefore, once a single Bitcoin signature key is compromised, attackers will prioritize high-value wallets.

Furthermore, users who do not reuse addresses and do not use Taproot addresses (Taproot exposes the public key directly on the chain) are relatively safe even without protocol changes: their public keys are hidden by a hash function until spending. Only when a spending transaction is broadcasted, the public key becomes visible, triggering a brief "real-time race"—the legitimate holder needs the transaction to be confirmed quickly while the quantum attacker attempts to derive the private key and spend ahead of them. Therefore, those coins that have keys already exposed are the ones truly vulnerable: early P2PK outputs, reused addresses, and Taproot holdings.

For exposed and potentially abandoned coins, there is no simple solution, and possible options include:

The community setting a "flag day," where after a certain date, any unmigrated coins are considered destroyed;

Or leaving these abandoned quantum-vulnerable coins to be directly "taken over" in the future by anyone with CRQC.

The second option would bring serious legal and security issues: using a quantum computer to take control of coins without possessing the private key could potentially violate theft or computer fraud laws in many jurisdictions, even if the claim of ownership is legitimate or in good faith.

Moreover, "abandonment" itself is based on speculation about long-term inactivity, and no one can confirm whether these coins truly have no living owner or accessible keys. Merely providing evidence of "I used to own these coins" is often insufficient to legally authorize asset recovery by bypassing password protection. This legal ambiguity increases the likelihood of malicious attackers getting a head start.

Bitcoin also faces an additional issue: low on-chain throughput. Even with a migration plan in place, moving all quantum-vulnerable funds to post-quantum secure addresses at the current Bitcoin transaction rate could take months.

These challenges necessitate Bitcoin to start planning for post-quantum migration now—not because CRQC is expected before 2030, but because governance, coordination, and technical migration alone will take years to resolve.

The quantum risk facing Bitcoin is indeed real, but the time pressure comes from its own constraints, not from an imminent quantum computing threat. Other blockchains will also have issues with quantum-vulnerable funds, but Bitcoin is particularly unique: its early transactions used P2PK outputs, directly exposing public keys on the chain, making the proportion of its quantum-vulnerable coins especially significant. Adding to that, Bitcoin has a longer history, more concentrated value, lower throughput, and stricter governance, making the issue particularly grave.

It is important to emphasize that the vulnerability above affects the security of Bitcoin's digital signature, not the security of the Bitcoin chain's economics. Bitcoin's economic security comes from PoW (Proof of Work), and the threat of quantum computing to PoW is relatively limited for three reasons:

PoW relies on hashing, so it is only subject to a quadratic speedup from Grover's search algorithm, not the exponential speedup of Shor's algorithm;

The practical cost of implementing Grover's search is significant, making it unlikely for a quantum computer to achieve even "modest practical speedup" on Bitcoin's PoW;

Even if a significant speedup occurs, it would mainly benefit large miners (quantum miners), giving them a relative advantage, rather than fundamentally breaking Bitcoin's economic security model.

Cost and Risk of Post-Quantum Signatures

To understand why blockchain should not hastily deploy post-quantum signatures, we must consider both the performance cost and the evolving confidence in post-quantum security.

Most post-quantum cryptographic schemes are based on one of five approaches:

Hashing, Codes, Lattices, Multivariate Quadratic Systems (MQ), Isogenies

Why five approaches? Because the security of any post-quantum cryptographic primitive is based on an assumption: a quantum computer cannot efficiently solve a specific mathematical problem. The stronger the problem structure, the more efficient protocols we can construct.

However, a stronger structure also means a larger attack surface, more likely to be exploited by algorithms. This creates a fundamental trade-off: stronger structural assumptions lead to better performance but also potentially higher security risks (greater probability of the assumption being overturned).

In general, the Hashing approach is the most conservative in terms of security because we are more confident that quantum computers will struggle to efficiently attack them; however, they also have the worst performance. For example, NIST-standardized hash-based signatures, even with minimal parameters, have signatures of 7–8KB. In comparison, today's elliptic curve-based digital signatures are only 64 bytes, approximately 100 times smaller.

Lattice cryptography is currently a focus of deployment: NIST-selected standardized post-quantum cryptography, including two of the three signature algorithms, is lattice-based.

For example, the signature size of ML-DSA (formerly Dilithium) is approximately:

128-bit security level: 2.4KB

256-bit security level: 4.6KB

Approximately 40–70 times larger than elliptic curve signatures.

Another lattice-based signature scheme, Falcon signature, is smaller (666 bytes for Falcon-512, 1.3KB for Falcon-1024), but requires complex floating-point operations. NIST also specifically pointed out the implementation difficulty of Falcon signatures. One of Falcon's authors, Thomas Pornin, even referred to it as "the most complex cryptographic algorithm [he has] ever implemented."

From an implementation security perspective, lattice-based signature schemes are also harder to deploy securely compared to elliptic curve schemes: ML-DSA has more sensitive intermediate values and complex rejection sampling logic, requiring side-channel and fault attack protections; Falcon involves challenges such as constant-time floating-point implementation, and indeed, there are side-channel attacks against Falcon implementations that can recover private keys.

These issues are immediate risks rather than long-term CRYC risks.

Caution comes with historical lessons: some previously leading candidate schemes, such as Rainbow (MQ signatures) and SIKE/SIDH (supersingular elliptic curve isogeny cryptography), were later broken by classical computers, meaning they could be broken with today's computers, not quantum computers.

And they were broken late in the NIST standardization process. This undoubtedly shows the scientific process at work, but it also reminds us that premature standardization and deployment may backfire.

For this reason, the internet infrastructure is taking a more robust approach to signature migration. Even once initiated, internet cipher migration often takes a very long time to fully materialize: the retirement of MD5 and SHA-1 demonstrates this, as these algorithms have long been deprecated but their complete elimination from infrastructure has taken many years and still persists in some scenarios. This is even after these algorithms were "completely broken," not just "potentially breakable in the future."

Blockchain vs. Internet Infrastructure: Some Unique Challenges

The good news is that active open-source community-maintained blockchains like Ethereum and Solana often upgrade faster than traditional internet infrastructure.

However, traditional internet infrastructure has its advantages: it frequently rotates keys, making the attack surface constantly shifting, making it difficult for early quantum machines to break through one by one. Blockchain does not have this "luxury" condition because coins and their corresponding keys can be exposed for long periods and remain static.

Overall, blockchain should still adopt an "Internet-like" robust pace of signature migration: because signatures are not facing HNDL, the cost and risk of prematurely migrating to immature post-quantum schemes are still significant.

At the same time, blockchain has some special requirements that make premature migration more complex: such as the need for on-chain rapid aggregation of a large number of signatures. Today, BLS signatures are common because of their extremely fast aggregation, but they are not post-quantum secure. Researchers are exploring using SNARK for aggregated post-quantum signatures, which is very promising but still in its early stages.

For SNARK, the community currently mostly regards hash-based constructions as the primary post-quantum scheme. However, in the coming months to years, lattice-based schemes may become a better-performing alternative, bringing advantages such as shorter proofs — similar to a comparison like "lattice signatures are shorter than hash-based signatures."

Main Issue Now: Achieving Security, Not Quantum Threat

In the many years to come, implementation vulnerabilities will be far more likely to be the primary security risk compared to CRQC. For SNARK, the primary concern is bugs.

Digital signatures and cryptography are inherently difficult to implement without vulnerabilities, and SNARK's complexity is even higher. In fact, digital signature schemes can be seen as a very simple form of zkSNARK: they prove "I know the private key corresponding to this public key and authorize this message."

For post-quantum signatures, we currently have to deal with implementation attacks such as side-channel attacks and fault injection. These attacks are very mature in the real world and are sufficient to extract private keys from deployed systems, posing a threat much more pressing than the "distant quantum computers."

In the next few years, the community needs to continue discovering and fixing bugs in SNARK and strengthening post-quantum signature implementations to withstand side-channel attacks and fault injections. As post-quantum SNARK and signature aggregation schemes are still evolving, chains that migrate too early may be locked into suboptimal solutions and may have to undergo a second migration when better solutions emerge or vulnerabilities are discovered.

What Should We Do? 7 Recommendations

Given the above realities, my advice to different roles (developers, policymakers, etc.) is: take the quantum threat seriously, but do not assume that CRQC will arrive before 2030. This assumption does not align with public progress. However, we can and should still take immediate action:

#1 Deploy hybrid encryption immediately.
At least where long-term confidentiality is required and costs are manageable. Browsers, CDNs, and communication software have widely adopted a "post-quantum + classical" hybrid approach to withstand HNDL, while hedging against potential weaknesses in post-quantum schemes.

#2 When the size allows, immediately use hash-based signatures.
For example, in low-frequency and size-insensitive scenarios such as software/firmware updates, hybrid hash signatures should be adopted as soon as possible (the hybrid is to hedge against implementation bugs, not to doubt the hash security assumption).

This is equivalent to preparing a "lifeboat" for society: if CRQC unexpectedly emerges prematurely and we do not have a post-quantum signature software update mechanism, we will face a bootstrapping problem—we wouldn't even be able to securely distribute patches to address CRQC.

#3 Blockchain does not have to immediately adopt post-quantum signatures, but it must start planning from now on.
Blockchain should follow the steady pace of the Internet PKI community, allowing post-quantum signatures to continue to mature, giving time for system refactoring to accommodate larger signatures and develop better aggregation technologies.

Compared to Bitcoin and other L1s: a migration path and a policy for handling quantum-vulnerable funds must be determined as soon as possible, as passive migration is not feasible. The challenges for Bitcoin mostly stem from slow governance and a large number of potentially high-value abandoned addresses, making it crucial to start planning now.

Sufficient time should also be allocated for research on post-quantum SNARKs and aggregatable signatures to mature (perhaps one or two years, or even longer). Premature migration may result in being locked into suboptimal solutions or being forced into secondary migration after implementation vulnerabilities are exposed.

Regarding the Ethereum account model supplement: Ethereum has two types of accounts that influence the post-quantum migration approach: Externally Owned Accounts (EOAs), controlled by secp256k1 private keys, and smart contract wallets with programmable authorization logic.

In non-emergency situations, if Ethereum were to adopt post-quantum signature support, upgradeable contract wallets could switch their verification logic through an upgrade; EOAs would more likely need to migrate their assets to a new post-quantum secure address (Ethereum may also provide a specific mechanism). In a "quantum emergency state," Ethereum researchers have proposed a hard fork to freeze vulnerable accounts and allow users to recover funds by proving they know the mnemonic phrase through a post-quantum secure SNARK, a mechanism that can be applied to both EOAs and non-upgraded contract wallets.

For users: upgradeable contract wallets, which have undergone thorough audits, may be slightly easier to migrate; however, the differences are minimal and come with trade-offs in trust in the wallet provider and upgrade governance. More important than the account type is Ethereum's continuous advancement in post-quantum primitive research and emergency solutions.

A more general design insight for developers: many chains tightly couple account identity with a specific signature primitive (e.g., Bitcoin/Ethereum binding to secp256k1, other chains binding to EdDSA). The post-quantum migration highlights the value of "decoupling account identity from a specific signature scheme." Ethereum's advancement of smart accounts and other chains' advancement of account abstraction reflect this trend: allowing for account upgradeable authentication logic without having to discard on-chain history and state. While this does not make post-quantum migration "easy," it significantly increases flexibility while also supporting features such as delegated payments, social recovery, multi-signature, etc.

#4 Regarding Privacy Chains: Prioritize Early Migration (if performance allows).
The privacy of a private chain will be affected by the HNDL risk, and the more a design can be publicly traced back to de-anonymize, the more urgent the risk. Consider hybrid solutions, or adjust the architecture to avoid writing decryptable secrets on-chain.

#5 The most immediate priority should be achieving security, not quantum readiness.
For complex primitives like SNARKs and post-quantum signatures, bugs, side channels, and fault injections will remain far more dangerous than CRQC for many years to come. Immediate investment in audits, fuzz testing, formal verification, and defense-in-depth is necessary, without letting "quantum anxiety" overshadow more pressing vulnerability risks.

#6 Fund Quantum Computing Development.
If a primary adversary achieves CRQC before the U.S., it will pose a serious national security risk. Therefore, continuous investment in quantum computing research and talent development is essential.

#7 Maintain a Calm Perspective on Quantum Computing Announcements.
There will be numerous hardware milestones in the coming years. In a sense, frequent milestones actually indicate how far we still are from CRQC: each milestone is just one of many bridges to CRQC, triggering waves of sensationalist headlines and excitement. Press releases should be treated as "progress reports requiring critical assessment" rather than a "signal for immediate comprehensive action."

Of course, unexpected innovations could accelerate the timeline in the future, or serious bottlenecks could lead to delays. I wouldn't say that achieving CRQC within five years is entirely impossible from a physical standpoint, just highly improbable. The above suggestions are intended to maintain robustness in the face of such uncertainty while avoiding the more realistic, higher-probability risks: vulnerabilities, hasty deployment, and human errors common in cryptographic migration.

[Original Article Link]

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia