Recent Bug Risks Far Exceed Quantum Attacks.
Author: Justin Thaler
Translation: Baihua Blockchain
The timeline for quantum computers related to cryptography is often exaggerated—leading to urgent calls for a comprehensive transition to post-quantum cryptography.
However, these calls often overlook the costs and risks of premature migration and ignore the starkly different risk profiles between various cryptographic primitives:
Post-quantum encryption, despite its costs, still demands immediate deployment: “Harvest-Now-Decrypt-Later (HNDL) attacks are already underway, as sensitive data encrypted today will still hold value when quantum computers arrive, even if that is decades later. The performance overhead and implementation risks of post-quantum encryption are real, but HNDL attacks leave data requiring long-term confidentiality with no choice.
Post-quantum signatures face different considerations. They are not susceptible to HNDL attacks, and their costs and risks (larger sizes, performance overhead, immature implementations, and errors) require thoughtful rather than immediate migration.
These distinctions are crucial. Misunderstandings can distort cost-benefit analyses, leading teams to overlook more pressing security risks—such as bugs.
The real challenge in successfully transitioning to post-quantum cryptography lies in matching urgency with actual threats. Below, I will clarify common misconceptions about the threat of quantum computing to cryptography—covering encryption, signatures, and zero-knowledge proofs—and particularly focus on their implications for blockchain.
How is our timeline progressing?
Despite widely publicized claims, the likelihood of cryptography-related quantum computers (CRQC) emerging in the 2020s is extremely low.
What I mean by “cryptography-related quantum computers” refers to a fault-tolerant, error-corrected quantum computer capable of running Shor's algorithm at a sufficient scale to break {secp}256{k}1 or {RSA-2048} attacks on elliptic curve cryptography or RSA within a reasonable timeframe (e.g., within a month of continuous computation).
Based on any reasonable interpretation of publicly available milestones and resource estimates, we are far from cryptography-related quantum computers. Companies sometimes claim that CRQC may appear before 2030 or as far out as 2035, but publicly known progress does not support these claims.
As background, among all current architectures—trapped ions, superconducting qubits, and neutral atom systems—today's quantum computing platforms are nowhere near the hundreds of thousands to millions of physical qubits required to run Shor's algorithm attacks on {RSA-2048} or {secp}256{k}1 (depending on error rates and error correction schemes).
The limiting factors are not just the number of qubits but also gate fidelity, qubit connectivity, and the depth of error-correcting circuits required to run deep quantum algorithms. While some systems now exceed 1,000 physical qubits, the raw number of qubits is itself misleading: these systems lack the qubit connectivity and gate fidelity necessary for cryptography-related computations.
Recent systems are approaching the physical error rates where quantum error correction begins to take effect, but no one has demonstrated more than a few logical qubits with sustained error-correcting circuit depth… let alone the thousands of high-fidelity, deep-circuit, fault-tolerant logical qubits required to actually run Shor's algorithm. The gap between proving quantum error correction is feasible in principle and achieving the scale needed for cryptanalysis remains vast.
In short: unless both the number and fidelity of qubits increase by several orders of magnitude, cryptography-related quantum computers remain out of reach.
However, corporate press releases and media reports can easily confuse. Here are some common sources of misunderstanding and confusion, including:
Demonstrations claiming “quantum advantage” currently target artificially designed tasks. These tasks are chosen not for their practicality but because they can run on existing hardware while seemingly exhibiting significant quantum speedup—a fact that is often obscured in announcements.
Companies claiming to have achieved thousands of physical qubits. But this refers to quantum annealers, not the gate model machines required to run Shor's algorithm attacks on public key cryptography.
Companies freely using the term “logical qubits.” Physical qubits are noisy. As mentioned earlier, quantum algorithms require logical qubits; Shor's algorithm needs thousands. Using quantum error correction, one logical qubit can be realized with many physical qubits—often hundreds to thousands, depending on error rates. But some companies have stretched this term beyond recognition. For example, a recent announcement claimed to have implemented one logical qubit using distance-2 codes with only two physical qubits. This is absurd: distance-2 codes can only detect errors, not correct them. The true fault-tolerant logical qubits needed for cryptanalysis each require hundreds to thousands of physical qubits, not two.
More generally, many quantum computing roadmaps use the term “logical qubits” to refer to qubits that only support Clifford operations. These operations can be efficiently classically simulated, making them insufficient for running Shor's algorithm, which requires thousands of error-corrected T gates (or more generally, non-Clifford gates).
Even if one of the roadmaps aims to “achieve thousands of logical qubits in X years,” this does not mean the company expects to run Shor's algorithm to break classical cryptography in the same year X.
These practices severely distort the public's perception of how close we are to cryptography-related quantum computers, even among mature observers.
That said, some experts are indeed excited about progress. For instance, Scott Aaronson recently wrote that given the “current astonishing pace of hardware development,”
I now think that having a fault-tolerant quantum computer running Shor's algorithm before the next U.S. presidential election is a realistic possibility.
But Aaronson later clarified that his statement did not mean cryptography-related quantum computers: he believes that even a fully fault-tolerant Shor's algorithm running factoring 15 = 3 \times 5 would count as an achievement—whereas this computation can be done faster with pencil and paper. The standard remains small-scale execution of Shor's algorithm, not cryptography-related scale, as previous experiments factoring 15 on quantum computers used simplified circuits rather than the full, fault-tolerant Shor's algorithm. Moreover, these experiments always factored the number 15 for a reason: arithmetic modulo 15 is easy, while factoring slightly larger numbers like 21 is much more difficult. Thus, claims of quantum experiments factoring 21 often rely on additional hints or shortcuts.
In simple terms, the expectation of a cryptography-related quantum computer capable of breaking {RSA-2048} or {secp}256{k}1 emerging within the next 5 years—which is crucial for practical cryptography—is not supported by any publicly known progress.
Even 10 years is still ambitious. Given how far we are from cryptography-related quantum computers, excitement about progress fits a timeline of over a decade.
So, what about the U.S. government's setting 2035 as the deadline for a comprehensive post-quantum (PQ) migration of government systems? I think this is a reasonable timeline for completing such a large-scale transition. However, it is not a prediction that cryptography-related quantum computers will exist by then.
In which cases do HNDL attacks apply (and which do not)?
Harvest-Now-Decrypt-Later (HNDL) attacks refer to an adversary storing encrypted traffic now and then decrypting it when cryptography-related quantum computers exist. Nation-state-level adversaries are certainly already archiving encrypted communications from the U.S. government on a large scale to decrypt these communications years after CRQC actually exists.
This is why encryption needs to transition immediately—at least for anyone with confidentiality needs of 10-50 years or more.
However, digital signatures—which all blockchains rely on—are different from encryption: there is no confidentiality to retroactively attack.
In other words, if a cryptography-related quantum computer arrives, signature forgery indeed becomes possible from that point onward, but past signatures are not “hiding” secrets like encrypted messages. As long as you know that the digital signature was generated before the arrival of CRQC, it cannot be forged.
This makes the transition to post-quantum digital signatures less urgent than the post-quantum transition for encryption.
Major platforms are taking action accordingly: Chrome and Cloudflare have launched hybrid {X}25519+{ML-KEM} for network transport layer security (TLS) encryption.
In this piece, for readability, I use the term encryption, although strictly speaking, secure communication protocols like TLS use key exchange or key encapsulation mechanisms rather than public key encryption.
Here, “hybrid” means simultaneously using both a post-quantum secure scheme (i.e., ML-KEM) and an existing scheme ({X}25519) to achieve a combination of security assurances. This way, they can (hopefully) block HNDL attacks through ML-KEM while maintaining classical security through {X}25519 in case ML-KEM is proven insecure even against today’s computers.
Apple's iMessage has also deployed this hybrid post-quantum encryption through its PQ3 protocol, and Signal has deployed it through its PQXDH and SPQR protocols.
In contrast, the promotion of post-quantum digital signatures to critical network infrastructure is being delayed until cryptography-related quantum computers are truly imminent, as current post-quantum signature schemes would incur performance penalties (which will be detailed later in this piece).
zkSNARKs—zero-knowledge succinct non-interactive arguments of knowledge, which are key to the long-term scalability and privacy of blockchain—are in a similar position to signatures. This is because, even for non-post-quantum secure {zkSNARKs} (which use elliptic curve cryptography, just like today’s non-post-quantum encryption and signature schemes), their zero-knowledge properties are post-quantum secure.
The zero-knowledge properties ensure that no information about the secret witness is leaked in the proof—even to quantum adversaries—therefore, there is no confidential information available for “harvesting” to decrypt later.
As a result, {zkSNARKs} are not easily susceptible to Harvest-Now-Decrypt-Later attacks. Just as non-post-quantum signatures generated today are secure, any {zkSNARK} proof generated before the arrival of cryptography-related quantum computers is trustworthy (i.e., the statement being proven is absolutely true)—even if the {zkSNARK} uses elliptic curve cryptography. Only after the arrival of cryptography-related quantum computers can an attacker find convincing false statements to prove.
What This Means for Blockchain
Most blockchains are not exposed to HNDL attacks:
Most non-privacy chains, such as today’s Bitcoin and Ethereum, primarily use non-post-quantum cryptography for transaction authorization—i.e., they use digital signatures rather than encryption.
Similarly, these signatures are not at risk from HNDL: “Harvest-Now-Decrypt-Later” attacks apply to encrypted data. For example, the Bitcoin blockchain is public; the quantum threat is signature forgery (deriving the private key to steal funds), not decrypting already public transaction data. This eliminates the immediate urgency for encryption posed by HNDL attacks.
Unfortunately, even analyses from trusted sources like the Federal Reserve incorrectly claim that Bitcoin is vulnerable to HNDL attacks, which exaggerates the urgency of transitioning to post-quantum cryptography.
That said, the reduced urgency does not mean Bitcoin can wait: it faces different timeline pressures from the huge social coordination required to change protocols.
The current exception is privacy chains, many of which encrypt or otherwise hide the recipient and amount. Once quantum computers can break elliptic curve cryptography, this confidentiality can now be compromised and retrospectively de-anonymized.
For such privacy chains, the severity of the attack varies by blockchain design. For example, for Monero, which uses curve-based ring signatures and key images (to prevent the linkability tags of each output), the public ledger itself is sufficient to retrospectively reconstruct the spending graph. But in other chains, the damage is more limited—see the discussion by Zcash cryptographic engineer and researcher Sean Bowe for details.
If it is important that users' transactions are not exposed by cryptography-related quantum computers, privacy chains should transition to post-quantum primitives (or hybrid schemes) as soon as feasible. Alternatively, they should adopt architectures that avoid placing decryptable secrets on-chain.
Bitcoin's Unique Dilemma: Governance + Abandoned Coins
Particularly for Bitcoin, two realities drive the urgency to begin transitioning to post-quantum digital signatures. Neither is related to quantum technology.
One concern is the speed of governance: Bitcoin changes slowly. If the community cannot reach consensus on an appropriate solution, any contentious issue could trigger a destructive hard fork.
Another concern is that the transition to post-quantum signatures cannot be a passive migration: owners must actively migrate their coins. This means that abandoned, quantum-vulnerable coins cannot be protected. Some estimates place the number of quantum-vulnerable and potentially abandoned BTC at millions of coins, worth tens of billions of dollars at current prices (as of December 2025).
However, the quantum threat to Bitcoin will not be a sudden, overnight disaster… but rather a selective, gradual targeting process. Quantum computers will not simultaneously break all cryptography—Shor's algorithm must target one public key at a time. Early quantum attacks will be extremely costly and slow. Therefore, once a quantum computer can break a single Bitcoin signature key, attackers will selectively prey on high-value wallets.
Moreover, users who avoid address reuse and do not use Taproot addresses—which directly expose public keys on-chain—are largely protected even without protocol changes: their public keys are hidden behind hash functions until their coins are spent. When they eventually broadcast a spending transaction, the public key becomes visible, and there will be a brief real-time race between honest spenders needing to confirm the transaction and quantum-equipped attackers wanting to find the private key and spend those coins before the true owner’s transaction is finalized. Thus, truly vulnerable coins are those whose public keys have been exposed: early pay-to-public-key (P2PK) outputs, reused addresses, and Taproot holdings.
For abandoned vulnerable coins, there is no simple solution. Some options include:
The Bitcoin community agrees on a “flag day” after which any un-migrated coins are declared destroyed.
Abandoned quantum-vulnerable coins can easily be seized by anyone with a cryptography-related quantum computer.
The second option would create serious legal and security issues. Using a quantum computer to seize coins without the private key—even claiming to have legitimate ownership or good intentions—could trigger serious problems under theft and computer fraud laws in many jurisdictions.
Moreover, “abandoned” itself is based on the presumption of inactivity. But no one really knows whether these coins lack living owners with the keys. Evidence that you once owned these coins may be insufficient to provide the legal authority to break the cryptographic protection to recover them. This legal ambiguity increases the likelihood that abandoned quantum-vulnerable coins fall into the hands of malicious actors willing to ignore legal constraints.
The final unique issue for Bitcoin is its low transaction throughput. Even if a migration plan is ultimately determined, migrating all quantum-vulnerable funds to post-quantum secure addresses would take months at Bitcoin's current transaction rate.
These challenges make it crucial for Bitcoin to start planning its post-quantum transition now—not because cryptography-related quantum computers may arrive before 2030, but because the governance, coordination, and technical logistics required to migrate tens of billions of dollars in coins will take years to resolve.
The quantum threat to Bitcoin is real, but the timeline pressure comes from Bitcoin's own limitations, not from imminent quantum computers. Other blockchains face their own challenges with quantum-vulnerable funds, but Bitcoin faces unique exposure: its earliest transactions used pay-to-public-key (P2PK) outputs, placing public keys directly on-chain, making a significant portion of BTC particularly vulnerable to attacks from cryptography-related quantum computers. This technical difference—combined with Bitcoin's age, value concentration, low throughput, and governance rigidity—exacerbates the problem.
Note that the vulnerabilities I described above apply to the cryptographic security of Bitcoin's digital signatures—but do not apply to the economic security of the Bitcoin blockchain. This economic security derives from the proof-of-work (PoW) consensus mechanism, which is not easily attacked by quantum computers for three reasons:
PoW relies on hashing, thus only affected by quadratic quantum speedup from Grover's search algorithm, not by the exponential speedup of Shor's algorithm.
The practical overhead of implementing Grover's search makes it extremely unlikely that any quantum computer could achieve even moderate practical speedup on Bitcoin's proof-of-work mechanism.
Even if significant speedup were achieved, it would give large quantum miners an advantage over small miners, but would not fundamentally undermine Bitcoin's economic security model.
The Costs and Risks of Post-Quantum Signatures
To understand why blockchains should not rush to deploy post-quantum signatures, we need to understand the performance costs and our evolving confidence in post-quantum security.
Most post-quantum cryptography is based on one of the following five approaches:
Hashing
Codes
Lattices
Multivariate quadratic systems (MQ)
Isogenies.
Why are there five different approaches? The security of any post-quantum cryptographic primitive is based on the assumption that quantum computers cannot efficiently solve specific mathematical problems. The more “structured” the problem, the more efficient the cryptographic protocols we can build from it.
But this has its pros and cons: additional structure also creates more room for attack algorithms to exploit. This leads to a fundamental contradiction—stronger assumptions can achieve better performance, but at the cost of potential security vulnerabilities (i.e., the increased likelihood that the assumptions are proven wrong).
In general, hash-based methods are the most conservative in terms of security, as we are most confident that quantum computers cannot effectively attack these protocols. However, they are also the least performant. For example, the NIST-standardized hash-based signature scheme has a size of 7-8 KB even at its minimum parameter settings. In contrast, today’s elliptic curve-based digital signatures are only 64 bytes. This is about a 100-fold size difference.
Lattice schemes are the main focus of deployment today. NIST has chosen the only encryption scheme and two of the three signature algorithms for standardization that are based on lattices. One lattice scheme (ML-DSA, formerly known as Dilithium) produces signatures ranging from 2.4 KB (at 128-bit security level) to 4.6 KB (at 256-bit security level)—making it about 40-70 times larger than today’s elliptic curve-based signatures. Another lattice scheme, Falcon, has slightly smaller signatures (Falcon-512 is 666 bytes, Falcon-1024 is 1.3 KB), but comes with complex floating-point operations, which NIST itself has labeled as special implementation challenges. One of Falcon's creators, Thomas Pornin, described it as “the most complex cryptographic algorithm I have ever implemented.”
The implementation security of lattice-based digital signatures is also more challenging than that of elliptic curve-based signature schemes: ML-DSA has more sensitive intermediate values and non-trivial rejection sampling logic, requiring side-channel and fault protection. Falcon introduces constant-time floating-point issues; in fact, several side-channel attacks on Falcon implementations have recovered secret keys.
These issues pose immediate risks, unlike the distant threat of cryptography-related quantum computers.
There is ample reason to remain cautious when deploying higher-performance post-quantum cryptographic methods. Historically, leading candidates like Rainbow (a signature scheme based on MQ) and SIKE/SIDH (a cryptographic scheme based on isogenies) have been broken classically, meaning they were compromised using today's computers, not quantum computers.
This occurred in the late stages of the NIST standardization process. This is healthy science at work, but it illustrates that premature standardization and deployment can be counterproductive.
As mentioned earlier, internet infrastructure is taking a thoughtful approach to signature migration. This is particularly noteworthy given how long it takes for the encryption transition of the internet to be implemented once it begins. The transition from MD5 and SHA-1 hash functions—which have been technically deprecated by network authorities for years—took many years to be actually implemented in infrastructure, and in some cases, it is still ongoing. This happened because these schemes were completely broken, not just potentially vulnerable to future technologies.
Unique Challenges of Blockchain vs. Internet Infrastructure
Fortunately, blockchains like Ethereum or Solana, actively maintained by open-source developer communities, can upgrade faster than traditional network infrastructure. On the other hand, traditional network infrastructure benefits from frequent key rotations, meaning its attack surface moves faster than early quantum machines can target—a luxury that blockchains do not have, as coins and their associated keys can be exposed indefinitely.
Overall, blockchains should still follow the thoughtful signature migration approach of networks. Signatures in both settings are not exposed to HNDL attacks, and regardless of how long the keys last, the costs and risks of prematurely migrating to immature post-quantum schemes remain significant.
There are also blockchain-specific challenges that make premature migration particularly risky and complex: for example, blockchains have unique requirements for signature schemes, especially the ability to quickly aggregate many signatures. Today, BLS signatures are often used for their ability to achieve very fast aggregation, but they are not post-quantum secure. Researchers are exploring post-quantum signature aggregation based on SNARKs. This work is promising but still in its early stages.
For SNARKs, the community is currently focused on hash-based structures as the leading post-quantum option. However, a significant shift is coming: I believe that in the coming months and years, lattice-based options will become attractive alternatives. These alternatives will perform better in various aspects than hash-based {SNARKs}, such as shorter proofs—similar to how lattice-based signatures are shorter than hash-based signatures.
Current Greater Issue: Implementation Security
In the coming years, implementation vulnerabilities will pose a greater security risk than cryptography-related quantum computers. For {SNARKs}, the primary focus is on bugs.
Bugs have already been a challenge for digital signature and encryption schemes, and {SNARKs} are much more complex. Indeed, a digital signature scheme can be viewed as a very simple {zkSNARK} used to state, “I know the private key corresponding to my public key, and I have authorized this message.”
For post-quantum signatures, immediate risks also include implementation attacks, such as side-channel and fault injection attacks. These types of attacks can be substantiated and can extract secret keys from deployed systems. They pose a more urgent threat than the distant quantum computing threat.
The community will work for years to identify and fix bugs in {SNARKs} and harden post-quantum signature implementations against side-channel and fault injection attacks. Given that the dust has not yet settled on post-quantum {SNARKs} and signature aggregation schemes, blockchains that transition too early face the risk of being locked into suboptimal solutions. When better options emerge, or when implementation vulnerabilities are discovered, they may need to migrate again.
What Should We Do? 7 Recommendations
In light of the realities I outlined above, I will conclude with recommendations for various stakeholders—from builders to policymakers. The primary principle: take the quantum threat seriously, but do not act on the assumption that cryptography-related quantum computers will arrive before 2030. This assumption is not supported by current progress. Nevertheless, there are things we can and should do now:
We should immediately deploy hybrid encryption.
Or at least in cases where long-term confidentiality is important and costs are manageable.
Many browsers, CDNs, and messaging applications (like iMessage and Signal) have already deployed hybrid approaches. Hybrid methods—post-quantum + classical—can defend against HNDL attacks while hedging against potential weaknesses in post-quantum schemes.
Immediately use hash-based signatures when size is manageable.
Software/firmware updates—and other such low-frequency, size-insensitive scenarios—should immediately adopt hybrid hash-based signatures. (The hybrid approach is to hedge against implementation errors in the new scheme, not because there are doubts about the security assumptions of hash-based methods.)
This is conservative and provides society with a clear “lifeboat” in the unlikely event that cryptography-related quantum computers appear unexpectedly early. If post-quantum signature software updates are not deployed in advance, we will face a bootstrapping problem after the emergence of CRQC: we will not be able to safely distribute the post-quantum cryptographic fixes we need to defend against it.
Blockchains should not rush to deploy post-quantum signatures—but should start planning immediately.
Blockchain developers should follow the lead of the network PKI community and take a thoughtful approach to post-quantum signature deployment. This allows post-quantum signature schemes to continue maturing in terms of performance and our understanding of their security. This approach also gives developers time to re-architect systems to handle larger signatures and develop better aggregation techniques.
For Bitcoin and other L1s: The community needs to define a migration path and policies regarding abandoned quantum-vulnerable funds. Passive migration is not possible, so planning is crucial. Moreover, due to Bitcoin's unique non-technical challenges—slow governance and a large number of high-value potential abandoned quantum-vulnerable addresses—it is especially important for the Bitcoin community to start planning now.
At the same time, we need to allow research on post-quantum {SNARKs} and aggregatable signatures to mature (which may take years). Again, premature migration carries the risk of being locked into suboptimal solutions or needing a second migration to address implementation errors.
A note on Ethereum's account model: Ethereum supports two types of accounts, which have different implications for post-quantum migration—Externally Owned Accounts (EOAs), the traditional account type controlled by {secp}256{k}1 private keys; and smart contract wallets with programmable authorization logic.
In non-urgent situations, if Ethereum adds support for post-quantum signatures, upgradable smart contract wallets can switch to post-quantum verification through contract upgrades—while EOAs may need to transfer their funds to new post-quantum secure addresses (though Ethereum will likely also provide a dedicated migration mechanism for EOAs).
In a quantum emergency, Ethereum researchers have proposed a hard fork plan to freeze vulnerable accounts and allow users to recover funds by using post-quantum secure {SNARKs} to prove knowledge of their mnemonic phrases. This recovery mechanism would apply to both EOAs and any smart contract wallets that have not yet upgraded.
Practical implications for users: Well-audited, upgradable smart contract wallets may offer a slightly smoother migration path—but the differences are not significant and come with trade-offs in trust regarding wallet providers and upgrade governance. More importantly, the Ethereum community should continue its work on post-quantum primitives and emergency response plans.
Broader design lessons for builders: Many blockchains today tightly couple account identities with specific cryptographic primitives—Bitcoin and Ethereum with ECDSA signatures on {secp}256{k}1, and other chains with EdDSA. The challenges of post-quantum migration highlight the value of decoupling account identities from any specific signature scheme. Ethereum's move towards smart accounts and similar account abstraction work on other chains reflects this trend: allowing accounts to upgrade their authentication logic without sacrificing their on-chain history and state. This decoupling does not trivialize post-quantum migration, but it does provide more flexibility than hardcoding accounts to a single signature scheme. (This also supports unrelated functionalities such as sponsored transactions, social recovery, and multi-signatures).
For privacy chains, which encrypt or hide transaction details, they should prioritize an earlier transition if performance is manageable.
The user confidentiality on these chains is currently exposed to HNDL attacks, although the severity varies by design. Chains that can achieve complete retrospective de-anonymization solely through public ledgers face the most urgent risks.
Consider hybrid schemes (post-quantum + classical) to prevent surface-level post-quantum schemes from being proven insecure even classically, or implement architectural changes to avoid placing decryptable secrets on-chain.
In the near term, prioritize implementation security—rather than quantum threat mitigation.
Especially for complex cryptographic primitives like {SNARKs} and post-quantum signatures, bugs and implementation attacks (side-channel attacks, fault injection) will pose a much greater security risk in the coming years than cryptography-related quantum computers.
Immediately invest in auditing, fuzz testing, formal verification, and deep defense/layered security approaches—do not let quantum concerns overshadow the more urgent threat of implementation errors!
Fund quantum computing development.
An important national security implication of all the above is that we need to continuously fund and train talent in quantum computing.
A major adversary achieving cryptography-related quantum computing capabilities before the United States will pose a serious national security risk to us and other countries around the world.
Maintain perspective on quantum computing announcements.
As quantum hardware matures, there will be many milestones in the coming years. Ironically, the frequency of these announcements itself demonstrates how far we are from cryptography-related quantum computers: each milestone represents one of the many bridges we must cross before reaching that point, and each milestone will generate its own headlines and waves of excitement.
Treat press releases as progress reports that require critical assessment, rather than cues for sudden action.
Of course, there may be surprising advancements or innovations that accelerate the expected timeline, just as there may be serious scaling bottlenecks that extend it.
I would not argue that the emergence of cryptography-related quantum computers within five years is absolutely impossible, just extremely unlikely. The above recommendations are robust against this uncertainty, and following them can help avoid more immediate and likely risks: implementation errors, hasty deployments, and common pitfalls in cryptographic transitions.
Justin Thaler is a research partner at a16z and an associate professor in the Department of Computer Science at Georgetown University. His research interests include verifiable computation, complexity theory, and algorithms for large-scale datasets.
Article link: https://www.hellobtc.com/kp/du/12/6156.html
Source: https://a16zcrypto.com/posts/article/quantum-computing-misconceptions-realities-blockchains-planning-migrations/
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
