> For the complete documentation index, see [llms.txt](https://esper.gitbook.io/esperchain-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://esper.gitbook.io/esperchain-docs/architecture/publish-your-docs.md). # Post-quantum cryptography Quantum computers are no longer science fiction. Major technology companies including Google, Microsoft, and IBM are actively developing quantum computing systems that demonstrate exponential improvements in computational power. Google's quantum supremacy claims and IBM's roadmap toward fault-tolerant quantum systems signal that we are approaching what cryptographers call "Q-Day" — the moment when quantum computers become powerful enough to break the cryptographic foundations that secure our digital world. This quantum milestone poses an existential threat to blockchain technology. Every major blockchain network today, including Bitcoin, Ethereum, Solana, and emerging Layer 2 solutions, relies on elliptic curve cryptography (ECC) for digital signatures and authentication. When Q-Day arrives, these networks will become vulnerable overnight. **TL;DR***: From genesis, every cryptographic primitive on Esper chain is chosen to remain secure against large‑scale quantum computers:* lattice‑based or hash‑based signatures, hash‑based VRF, STARK proofs, and 512‑bit Poseidon hashing. ### Understanding the Quantum Attack Vector The quantum threat to blockchains stems from two fundamental quantum algorithms: **Shor's Algorithm** can efficiently solve the discrete logarithm problem that underpins elliptic curve cryptography. This means quantum computers can: * Derive private keys from exposed public keys * Forge digital signatures for any account * Compromise wallet security across all ECC-based blockchains **Grover's Algorithm** effectively halves the security strength of symmetric cryptographic primitives, requiring a doubling of key sizes to maintain equivalent security. #### The Blockchain Vulnerability Timeline 1. **Transaction Broadcast**: When users send transactions, their public keys become visible on-chain 2. **Key Exposure**: These exposed public keys become targets for quantum attacks 3. **Private Key Recovery**: Quantum computers running Shor's algorithm can derive private keys from public keys 4. **Total Compromise**: Attackers gain full control over accounts, enabling theft and network manipulation Current blockchain networks using ECDSA (Bitcoin, Ethereum) or Ed25519 (Solana, Sui, Aptos) signatures are completely defenseless against this attack vector. Even proposed solutions like hybrid signatures or ZK-proof approaches only provide temporary mitigation rather than fundamental quantum resistance. ### Esper's Quantum-Native Architecture Unlike other blockchain projects that attempt to retrofit quantum resistance onto classical cryptographic foundations, **Esper is designed from genesis to be quantum-secure**. Every cryptographic primitive in the Esper protocol has been carefully selected to remain secure against large-scale quantum computers: #### Core Cryptographic Primitives **Lattice-Based Signatures**: Esper implements CRYSTALS-Dilithium, a NIST-standardized post-quantum signature scheme based on the hardness of lattice problems. Unlike elliptic curve cryptography, lattice-based cryptography has no known quantum attack, even with theoretical advances in quantum computing. **Hash-Based Verifiable Random Functions (VRF)**: Our consensus mechanism employs hash-based VRF construction that remains secure against both classical and quantum adversaries, ensuring unpredictable and verifiable randomness for block production. **STARK Zero-Knowledge Proofs**: Esper leverages Scalable Transparent Arguments of Knowledge (STARKs) for privacy and scalability. STARKs are inherently quantum-resistant as they rely only on hash functions and information-theoretic security assumptions. **512-bit Poseidon Hashing**: All cryptographic commitments and Merkle tree constructions use 512-bit Poseidon hashing, providing 256 bits of quantum security (double the classical requirement due to Grover's algorithm). And this is not all: we are working on unique isogeny-based post-quantum cryptography leveraging higher mathematics. #### Why Quantum-Native Matters **Future-Proof Security**: While other blockchains face costly migration challenges when quantum computers become viable, Esper users and applications remain secure without any required upgrades or migrations. **No Hybrid Complexity**: Unlike hybrid approaches that require multiple signature verifications and complex key management, Esper's quantum-native design maintains simplicity and efficiency. **Economic Certainty**: Users and institutions can deploy long-term infrastructure on Esper with confidence that their cryptographic investments won't become obsolete. **Developer Confidence**: Smart contract developers can build applications knowing that the underlying security assumptions will remain valid throughout the quantum transition. ### The Path Forward The quantum threat to blockchain infrastructure is not a distant concern—it is an engineering reality that demands immediate attention. While the broader cryptocurrency ecosystem scrambles to develop quantum-resistant upgrades, Esper provides a quantum-secure foundation from day one. By choosing quantum-resistant cryptographic primitives at the protocol level, Esper ensures that when Q-Day arrives, our network will continue operating securely while other blockchains face existential security crises. This quantum-native approach positions Esper as the infrastructure for the post-quantum digital economy. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://esper.gitbook.io/esperchain-docs/architecture/publish-your-docs.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.