a16z | Quantum Computing and Blockchain: Matching "Urgency" with Real Threats

Chainfeeds Guide:

This article clarifies common misconceptions about quantum threats, including their impact on encryption algorithms, signature mechanisms, and zero-knowledge proofs (ZKP), and discusses what they mean for blockchain systems.

Source:

a16z

Opinion:

a16z: The first real security risk brought by quantum computing is not a "future attack," but rather the Harvest Now, Decrypt Later (HNDL) attack. In this scenario, attackers store encrypted communications now and wait until they have quantum computing capabilities in the future to decrypt them. This means that highly confidential communications (especially at the national level), even if unbreakable today, could still be exposed in the future. Therefore, for systems requiring confidentiality for 10-50 years or more, new quantum-resistant encryption needs to be deployed now. However, this threat does not apply to digital signature systems. Digital signatures do not contain "privacy content that can be retroactively decrypted," nor is there a problem where "past verifications could be overturned by quantum computing." Even if quantum computers can forge signatures in the future, they would only affect future transactions and authorizations, not invalidate past signatures or leak hidden information. Based on this logic, the most commonly used signature mechanisms on blockchains (ECDSA, EdDSA) will need to be upgraded in the future, but there is no urgent need to migrate immediately. In addition, the security model of zkSNARKs is even more distinct from encryption. Even if today's zkSNARKs are based on elliptic curves, their zero-knowledge property itself remains secure against quantum attacks, because the proof does not contain private data that can be recovered by quantum algorithms. Therefore, zkSNARKs also do not face the risk of being archived and waiting for decryption. In other words, privacy chains are more urgent, public chains are less urgent, signatures can be upgraded later than encryption, and SNARKs are even less urgent than signatures—this is the real priority order of quantum threats in the blockchain world. Although the blockchain as a whole does not need to immediately switch to quantum-resistant signatures, Bitcoin is an exception. The reason is not that the quantum threat is imminent, but because of slow governance, historically complex transaction structures, and active migration depending on user behavior. First, changes to the Bitcoin protocol are extremely slow, and any changes involving consensus or security logic can trigger controversy, splits, or even hard forks. Second, Bitcoin upgrades cannot automatically migrate all assets, because signature keys are held by users and the protocol cannot force upgrades. This means that expired, lost, or unmanaged wallets (estimated to contain millions of BTC) will be permanently exposed to future quantum attacks. Even more problematic, early Bitcoin used P2PK (address structure exposing the public key directly), and these public keys are already visible on-chain, allowing quantum computers to use Shor's algorithm to directly derive the private key from the visible public key. This is different from modern address patterns (hashing to hide the public key), where the public key is only exposed when a transaction is made, allowing for a race against attackers within a time window. Therefore, Bitcoin's migration is not simply a technical issue, but a long-term project involving legal risks (lost vs. proof of ownership), social collaboration, implementation time, and costs. Even if the quantum threat is distant, Bitcoin needs to start formulating an irreversible migration roadmap now. Although the quantum threat does exist, a hasty comprehensive upgrade would actually bring greater real-world risks. At this stage, many quantum-resistant algorithms have significant performance costs, implementation complexity, and even historical cases of being directly broken by classical algorithms (such as Rainbow, SIKE). For example, current mainstream post-quantum signatures like ML-DSA and Falcon are tens or even hundreds of times larger than current signatures, and their implementations are prone to side-channel attacks, floating-point vulnerabilities, or parameter errors leading to key leaks. Therefore, blockchains should not migrate blindly, but should adopt a phased, multi-track, and replaceable architecture strategy: deploy hybrid encryption (post-quantum + classical) for long-term confidential communications; use hash-based signature systems in scenarios where frequent signing is not required (firmware, system updates); keep planning and research at the public chain layer, taking a cautious pace consistent with Internet PKI; and adopt account abstraction or modular design so that future signature systems can be upgraded without breaking on-chain identity and asset history. [Original text in English]