Quantum threat in blockchain: distinguishing real priorities from fake urgencies

The real danger: harvest attacks and late decryption

The immediate risk posed by quantum computing is not hypothetical. It is known as “Harvest Now, Decrypt Later” (HNDL): sophisticated adversaries collect encrypted communications today with the intention of decrypting them when they have operational quantum capabilities. For data that must remain confidential for one or several decades — particularly sensitive state-level information — this threat is concrete and requires preventive action now. Systems that require protection for 10-50 years or more should already begin implementing quantum-resistant cryptographic schemes, without waiting for the technology to become fully accessible.

Digital signatures: a threat not so near

Unlike encryption, digital signatures face a different risk horizon. ECDSA and EdDSA signatures, pillars of blockchain security, do not contain private information susceptible to retroactive recovery if quantum algorithms manage to break them in the future. A successful quantum attack would only compromise future transactions and authorizations; it would never invalidate historical signatures or reveal past secrets. For this reason, although these signatures will eventually need to be updated, there is no immediate urgency to perform that migration.

Zero-knowledge proofs: the least of problems

zkSNARKs present a security model entirely different from symmetric or asymmetric encryption. Although many current implementations are based on elliptic curves, their fundamental property — demonstrating knowledge without revealing information — remains shielded against quantum attacks. Since the proofs do not contain private data recoverable by quantum algorithms, the “harvest and late decryption” scenario does not apply. Consequently, systems based on zkSNARKs have the lowest urgency level among all blockchain architectures.

Hierarchy of priorities for quantum migration

The quantum threat does not affect all layers of blockchain technology equally:

  • Highest urgency: privacy networks and long-term encryption systems storing data requiring future confidentiality
  • Medium urgency: conventional public chains relying on current signature schemes
  • Low urgency: systems based on zkSNARKs and zero-knowledge proofs
  • Special case: Bitcoin, which requires transition before others

Bitcoin: the exception demanding anticipation

Although most of the blockchain ecosystem can afford to wait, Bitcoin represents an anomaly that justifies starting quantum migration planning now. The reasons are multiple and complex.

First, Bitcoin’s protocol experiences extremely slow upgrade cycles. Any change related to consensus or cryptographic logic generates controversy, potentially triggering irreconcilable splits or hard forks. This institutional rigidity means that completing a quantum transition could take a decade or more.

Second, Bitcoin cannot enforce automatic asset migrations. Private keys are exclusively owned by users, and the protocol lacks mechanisms to force updates. It is estimated that millions of BTC remain in inactive, lost, or obsolete wallets, which would remain permanently vulnerable to future quantum attackers once quantum computing becomes viable.

Third, Bitcoin’s origins present a particular risk: the Pay-to-Public-Key (P2PK) structure directly exposes public keys on the blockchain. Shor’s algorithm would allow deriving private keys instantly from these visible public keys. In contrast, modern schemes — based on hashes that hide public keys — only expose these data during transactions, providing a window of time to act before attackers.

The migration of Bitcoin goes beyond mere technical aspects: it involves legal risks (proof of ownership issues), massive social coordination, realistic implementation schedules, and significant costs. Although the quantum threat is distant, Bitcoin must design today an irreversible and executable migration roadmap.

Prudent balance: avoid hasty migration

Paradoxically, although the danger exists, a sudden and comprehensive update of the ecosystem could introduce even greater risks. Current post-quantum algorithms present challenges that should not be underestimated: dramatic growth in signature size, high implementation complexity, and in several historical cases, vulnerabilities discovered years after initial adoption (Rainbow and SIKE are notable examples).

The main emerging post-quantum signatures — ML-DSA and Falcon — require signatures 10 to 100 times larger than current ones. Their implementation is susceptible to side-channel attacks, floating-point precision errors, or misconfigured parameters that can leak keys.

Recommended strategy: gradual and modular adoption

Blockchain should avoid blind migrations to post-quantum schemes. The alternative is a layered, diversified, and replaceable architectural strategy:

  • Hybrid encryption for sensitive long-term communications, combining post-quantum algorithms with proven classical schemes
  • Hash-based signatures in contexts where frequent signing is not necessary (firmware updates, system changes)
  • Ongoing research at the public protocol level, synchronized with cautious progress in Internet public key infrastructure
  • Abstract and modular architectures, allowing signature mechanisms to evolve without compromising historical identities or asset lineages on the chain

This approach ensures that blockchain can adapt without rushing, incorporating post-quantum decryption resistance when safe and necessary, without undermining current stability.

BTC0,36%
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Repost
  • Share
Comment
0/400
No comments
  • Pin

Trade Crypto Anywhere Anytime
qrCode
Scan to download Gate App
Community
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)