Skip to content

post-quantum-overview.md

Latest commit

 

History

History
60 lines (46 loc) · 2.66 KB

post-quantum-overview.md

File metadata and controls

60 lines (46 loc) · 2.66 KB

Post-Quantum Overview

What it means that the Quantova tools are "post-quantum," and how that property holds across the whole toolkit.

The threat

Elliptic-curve signatures (ECDSA, Ed25519) that secure classical blockchains can be broken by a sufficiently capable quantum computer. Because public keys and signatures are public on-chain, an adversary can record them now and forge them once the hardware exists — a harvest-now, decrypt-later exposure that makes a chain's entire history retroactively forgeable.

Quantova's answer

Quantova is post-quantum from the signature layer up:

  • Signatures: the NIST post-quantum schemes Quantova supports — CRYSTALS- Dilithium (ML-DSA), Falcon (FN-DSA), and SPHINCS+ (SLH-DSA) — verified by the runtime's QSignature type. There is no classical fallback.
  • Accounts: every account address is derived from a post-quantum public key (SHA3-256 of the key, first 20 bytes, with the Q marker), so the account is the post-quantum key.
  • Hashing: SHA3-256 for transaction/state/block hashing; the QVM uses keccak-256 for the Solidity ABI. Hash functions are not broken by the quantum attack that breaks elliptic curves.
  • Consensus: validator authority keys are post-quantum (Falcon), so block production and finality are post-quantum too.

How the property holds across the tools

Because the post-quantum guarantee is fixed at the lowest layers, every tool inherits it:

  • qweb3.js / qweb3.py build and sign transactions with the post-quantum schemes.
  • QMask manages post-quantum keys and produces post-quantum signatures.
  • QVM executes Solidity with standard tooling, while the transaction authorizing each call is post-quantum.
  • QNS registrations and updates are post-quantum-signed, so name ownership is quantum-secure.
  • pq-test-vectors lets anyone confirm an implementation's post-quantum address derivation and signatures are correct.
  • reproducible-builds verifies releases that are themselves signed with post-quantum signatures (Dilithium / Falcon).

Choosing a scheme

All three schemes derive into the same Quantova address space, so the choice is per-account and does not affect the rest of the stack:

  • Dilithium — balanced signature size and verification speed; a good general default.
  • Falcon — compact signatures; also the validator authority scheme.
  • SPHINCS+ — hash-based and assumption-minimal; the conservative option.

In short

Using the Quantova tools means your integration is quantum-resistant by construction, and the verification tools let you prove it — for your own code, the node you depend on, and the releases you run.