⚛️ Project Qbit

Quantum-Resistant Blockchain Infrastructure for the Post-Quantum Era

Building the cryptographic foundation that will outlast quantum computers.

🌐 Overview

Project Qbit is a next-generation, post-quantum blockchain protocol engineered to withstand the full cryptographic threat posed by fault-tolerant quantum computers. It is one of the first blockchain architectures to be designed from the ground up around the NIST-finalized post-quantum cryptography (PQC) standards (FIPS 203/204/205/206), rather than retroactively patching classical schemes.

Recent research (Google Quantum AI, 2026) suggests that elliptic-curve cryptography underpinning Bitcoin and Ethereum could be broken with fewer than 500,000 qubits — placing a realistic horizon as close as 2029–2032. Classical blockchains face existential "harvest now, decrypt later" attacks today. Qbit has no such legacy debt.

The protocol is implemented entirely in Rust for memory safety, zero-cost abstractions, and performance, and is architected around crypto-agility — the ability to swap cryptographic primitives without disrupting consensus, wallets, or the chain history.

🚀 Key Features

🔐 Cryptographic Layer (Updated for 2025 NIST Standards)

Algorithm	NIST Standard	Role in Qbit
ML-KEM (Kyber)	FIPS 203	Key encapsulation for P2P channels, session keys
ML-DSA (Dilithium)	FIPS 204	Primary transaction and block signing
SLH-DSA (SPHINCS+)	FIPS 205	Fallback/backup signatures (hash-based; no lattice dependency)
FN-DSA (Falcon)	FIPS 206	Compact validator signatures for consensus votes
HQC	Pending (2027)	Code-based KEM backup; different math from ML-KEM

Why multiple schemes? Qbit follows the defense-in-depth principle. If a mathematical breakthrough compromises lattice-based schemes (ML-DSA, Falcon), the hash-based SLH-DSA fallback remains secure. HQC, once standardized, adds a third mathematical family as a backup KEM.

⚖️ Quantum-Resistant Proof-of-Stake (QPoS)

Validator selection via post-quantum Verifiable Random Function (PQ-VRF) replacing classical ECVRF
Block proposals and votes signed exclusively with FN-DSA (Falcon) for compact footprint (~666 bytes vs ECDSA's 64 bytes)
Threshold signature aggregation using lattice-based threshold schemes for committee signing
Post-quantum BFT finality — Byzantine fault tolerance with PQ-signed vote messages
Quantum-aware Sybil resistance: validator identity anchored to ML-DSA keys, not ECDSA

🧠 Qbit VM — Quantum-Safe Smart Contracts

zk-STARK-based verification for smart contract proofs (hash-function-based, inherently PQ-safe)
Built-in opcodes for on-chain PQ signature verification (ML-DSA, FN-DSA, SLH-DSA)
Wasm-based execution environment with formal safety guarantees
Quantum-safe random beacons via Verifiable Delay Functions (VDFs) for contract randomness

🔁 Signature Compression & Aggregation

Merkle Signature Tree aggregation reduces multi-signature blocks by committing multiple validator signatures into a single compact root
Off-chain bulk signature storage in content-addressed systems (IPFS/Arweave) with on-chain hash commitments — critical because SPHINCS+ signatures reach up to 41 KB
Batch verification support for ML-DSA to recover throughput (~Dilithium2: 2,420 bytes per sig)

🔒 Security Hardening (New in v0.2+)

Crypto-agility layer: Algorithm identifiers are first-class protocol citizens — upgrades are governance-voted, not hard-forks
Hybrid signing mode (classical + PQ) during transition period, allowing clients to verify with either scheme
Constant-time implementations of all PQ algorithms to prevent timing side-channels
Secure erasure of signing secrets after use (XMSS statefulness handled safely via atomic disk writes)
Memory-safe Rust enforcement — no unsafe blocks in the cryptographic core

🌉 Interoperability & Migration

Bridge contracts for Ethereum/Bitcoin with dual-signature transaction adaptation
Classical-to-quantum wallet migration path (one-time key ceremony)
Protocol-level support for "harvest now, decrypt later" countermeasures: encrypted mempool data uses ML-KEM session keys

🛡️ Threat Model

Threat	Attack	Qbit Mitigation
Shor's Algorithm	Breaks ECDSA/RSA signatures	All signatures use NIST PQC schemes
Grover's Algorithm	Halves hash security (n-bit → n/2-bit)	All hashes use SHA-3-512 / BLAKE3-512 (256-bit post-quantum margin)
Harvest Now Decrypt Later	Capture traffic today, decrypt when QC available	ML-KEM for all session keys; no RSA/ECDH on wire
Lattice Cryptanalysis	Future breaks in ML-DSA or Falcon	SLH-DSA (hash-based) and HQC (code-based) fallbacks in crypto-agility layer
Side-Channel / Timing	Infer secrets from execution time	Constant-time implementations, no early exit branches
State Management (XMSS)	Reuse of one-time keys	Atomic state file with `fsync`, crash-recovery journal
51% Quantum Acceleration	Grover speeds up validator brute-force	Hash sizes doubled (SHA-3-512), block time tuned for honest-majority stability

🛠️ Tech Stack

Component	Technology	Rationale
Language	Rust 1.78+	Memory safety, zero-cost abstractions, constant-time primitives
Primary Signatures	ML-DSA (Dilithium) — FIPS 204	NIST standard, efficient, well-analyzed
Consensus Signatures	FN-DSA (Falcon) — FIPS 206	Compact size suits high-frequency validator votes
Backup Signatures	SLH-DSA (SPHINCS+) — FIPS 205	Hash-based, independent security assumption
Key Encapsulation	ML-KEM (Kyber) — FIPS 203	NIST standard, IND-CCA2 secure
KEM Backup	HQC (2027 target)	Code-based; different math from ML-KEM
Hashing	SHA-3-512 + BLAKE3	Grover-resistant at 512-bit, defense-in-depth
VM Proofs	zk-STARKs	Hash-based, inherently PQ-safe
P2P Network	libp2p + Noise protocol (ML-KEM handshake)	Quantum-secure transport layer
Storage	RocksDB with Merkleized state	Efficient state access and proof generation
Consensus	Custom QPoS (BFT + PQ-VRF)	Purpose-built, no classical crypto assumptions

📁 Repository Structure

project-qbit/
│
├── crypto/                    # Cryptographic primitives
│   ├── mldsa/                 # ML-DSA (Dilithium) — FIPS 204
│   ├── fndsa/                 # FN-DSA (Falcon) — FIPS 206
│   ├── slhdsa/                # SLH-DSA (SPHINCS+) — FIPS 205
│   ├── mlkem/                 # ML-KEM (Kyber) — FIPS 203
│   ├── hqc/                   # HQC KEM (future/optional)
│   ├── hybrid/                # Classical+PQ hybrid transition layer
│   ├── agility/               # Crypto-agility registry (algorithm IDs + routing)
│   └── zk/                    # zk-STARK primitives for VM
│
├── consensus/                 # QPoS consensus engine
│   ├── qpos/                  # Quantum Proof-of-Stake core
│   ├── pq_vrf/                # Post-quantum VRF for validator selection
│   ├── threshold/             # Lattice threshold signatures for committee voting
│   ├── bft/                   # Byzantine fault-tolerant finality layer
│   └── vdf/                   # Verifiable Delay Function for randomness
│
├── core/                      # Blockchain core
│   ├── block.rs               # Block structure (PQ-signed headers)
│   ├── tx.rs                  # Transaction format (algorithm-agnostic)
│   ├── mempool.rs             # Encrypted mempool (ML-KEM session keys)
│   ├── state.rs               # World state (Merkleized)
│   └── chain.rs               # Chain management and fork choice
│
├── vm/                        # Qbit Virtual Machine
│   ├── executor/              # Wasm-based smart contract executor
│   ├── opcodes/               # PQ-specific opcodes (verify_mldsa, verify_fndsa, etc.)
│   ├── stark/                 # zk-STARK verifier integration
│   └── stdlib/                # Standard library for PQ-aware contracts
│
├── wallet/                    # Key management
│   ├── keygen.rs              # PQ key generation (all supported schemes)
│   ├── hd_wallet.rs           # PQ-HD wallet (BIP32-analog for PQC)
│   ├── migration.rs           # Classical-to-quantum migration tool
│   └── secure_erase.rs        # Memory-safe secret deletion
│
├── network/                   # P2P layer
│   ├── transport.rs           # libp2p + ML-KEM Noise handshake
│   ├── gossip.rs              # Block/tx propagation
│   └── bridge/                # Ethereum/Bitcoin interoperability bridges
│
├── node/                      # Full node binary
│   ├── main.rs
│   ├── config.rs              # Crypto-agility configuration
│   └── rpc/                   # JSON-RPC API
│
├── cli/                       # Command-line tools
│   ├── wallet.rs              # Wallet management CLI
│   ├── node.rs                # Node management CLI
│   └── migrate.rs             # Key migration CLI
│
├── security/                  # Security tooling
│   ├── constant_time/         # CT wrappers and audit tools
│   ├── fuzzing/               # Cargo-fuzz targets for all crypto modules
│   └── formal/                # Formal verification specs (Verus/Creusot)
│
├── tests/
│   ├── unit/                  # Per-module unit tests
│   ├── integration/           # Cross-module integration tests
│   ├── vectors/               # NIST KAT (Known Answer Test) vectors
│   └── adversarial/           # Simulated quantum adversary tests
│
├── benchmarks/                # Performance benchmarks (criterion.rs)
│
└── README.md

🏗️ Architecture Flowchart

The diagram below shows the full data flow through Qbit — from a user signing a transaction all the way down to the P2P network and interoperability bridges. Every layer relies exclusively on NIST-finalized PQC primitives. The crypto-agility registry underpins all layers and allows future algorithm upgrades without hard-forks.

flowchart TD
    subgraph WALLET["🔑 Wallet Layer"]
        W1[ML-DSA key]
        W2[FN-DSA key]
        W3[SLH-DSA key]
        W4[ML-KEM key]
        WN["Key generation · HD derivation · Secure erasure · Classical migration"]
    end

    subgraph TX["📄 Transaction Layer"]
        T1["AlgorithmId field · Signature · Public key · Crypto-agility routing"]
    end

    subgraph MEM["🔒 Encrypted Mempool"]
        M1["ML-KEM session keys · Anti harvest-now-decrypt-later · Batch verification"]
    end

    subgraph CONS["⚖️ QPoS Consensus Layer"]
        C1["PQ-VRF\nValidator selection lottery"]
        C2["Block Proposal\nFN-DSA signed headers"]
        C3["BFT Voting\nThreshold lattice signatures"]
        C4["VDF Beacon\nRandomness for contracts"]
        C1 --> C2 --> C3 --> C4
    end

    subgraph CORE["⛓️ Blockchain Core"]
        BC["Block · State · Chain · Fork choice"]
        MS["Merkleized State\nSHA-3-512 · RocksDB · Proof gen."]
        BC <--> MS
    end

    subgraph VM["🧠 Qbit VM"]
        V1["Wasm executor · PQ opcodes: VERIFY_MLDSA · VERIFY_FNDSA · KEM_ENCAP"]
        V2["zk-STARK verifier · Gas metering · Formal verification"]
    end

    subgraph NET["🌐 P2P Network Layer"]
        N1["libp2p · ML-KEM Noise handshake · Gossip · Eclipse attack mitigations"]
    end

    subgraph BRIDGE["🌉 Interoperability Bridges"]
        B1["Ethereum Bridge\nDual-sig relay · ECDSA + ML-DSA hybrid"]
        B2["Bitcoin Bridge\nHash-lock adapters · PQ commitments"]
    end

    subgraph AGILITY["🔐 Crypto-Agility Foundation"]
        A1["ML-DSA FIPS 204 · FN-DSA FIPS 206 · SLH-DSA FIPS 205 · ML-KEM FIPS 203 · HQC backup 2027"]
    end

    WALLET -->|"PQ-signed tx"| TX
    TX -->|"Validated tx"| MEM
    MEM -->|"Ordered txs"| CONS
    CONS -->|"Finalized block"| CORE
    CORE --> VM
    VM --> NET
    NET -->|"Bridges"| BRIDGE

    AGILITY -.->|"underpins"| WALLET
    AGILITY -.->|"underpins"| CONS
    AGILITY -.->|"underpins"| VM
    AGILITY -.->|"underpins"| NET

🗺️ Implementation Plan

Phase 0 — Foundation (Months 1–3) ✅ In Progress

Goal: Establish the cryptographic core with full NIST PQC compliance.

Integrate pqcrypto and oqs Rust crates for ML-DSA, FN-DSA, SLH-DSA, ML-KEM
Implement NIST Known Answer Test (KAT) runner for all four algorithms
Build the crypto-agility registry: AlgorithmId enum, algorithm routing, version negotiation
Implement constant-time wrappers and audit all existing code for timing branches
SHA-3-512 and BLAKE3 dual-hash internal hashing module
Secure memory erasure module (zeroize crate integration)
Basic transaction structure with algorithm-agnostic signature fields
Initial CI with KAT-based regression testing

Deliverable: A verified, NIST-compliant cryptographic library passing all KAT vectors.

Phase 1 — Core Blockchain (Months 4–6)

Goal: Working single-node blockchain with PQ-signed blocks and transactions.

Block structure: PQ-signed headers (ML-DSA), Merkle-rooted body
Transaction format: multi-algorithm aware (AlgorithmId + signature + public key)
UTXO or account-based state with Merkle Patricia Trie
Mempool with ML-KEM-encrypted transaction storage (anti harvest-now attack)
Basic chain validation and fork choice rule
RocksDB-backed state persistence
JSON-RPC API (get block, submit tx, query state)
Single-node integration test suite

Deliverable: A single-node blockchain that produces and validates PQ-signed blocks.

Phase 2 — QPoS Consensus (Months 7–10)

Goal: Multi-node consensus with post-quantum validator protocol.

PQ-VRF implementation for validator lottery (based on lattice-based VRF constructions)
Validator registration: staking with ML-DSA identity keys
FN-DSA (Falcon)-based block proposals and pre-vote/pre-commit messages
BFT finality layer (Tendermint-inspired, PQ-signed messages throughout)
Threshold signature committee: lattice threshold scheme for aggregate vote proofs
Slashing conditions with PQ-provable evidence
VDF-based random beacon for fair validator selection
Multi-node devnet (5–20 validators)
Adversarial simulation: Byzantine validator tests, network partitions

Deliverable: Functioning multi-node testnet with QPoS consensus achieving finality.

Phase 3 — Qbit VM & Smart Contracts (Months 11–14)

Goal: Quantum-safe smart contract execution environment.

Wasm executor with sandboxed contract execution
PQ opcodes: VERIFY_MLDSA, VERIFY_FNDSA, VERIFY_SLHDSA, KEM_ENCAP, KEM_DECAP
zk-STARK verifier opcode for privacy-preserving contract logic
Gas metering calibrated to PQ operation costs
Solidity-to-Qbit-assembly transpiler (for Ethereum migration)
Standard library: PQ token standard, PQ multisig, PQ escrow
Formal verification of the VM execution model (using Verus or Creusot)
Smart contract auditing tooling

Deliverable: Turing-complete VM with native PQ cryptographic primitives.

Phase 4 — Network Security & Interoperability (Months 15–18)

Goal: Secure P2P layer and bridges to classical blockchains.

libp2p transport with ML-KEM Noise protocol handshake (quantum-secure channels)
Block and transaction gossip with encrypted propagation
Ethereum bridge: dual-signature relay (ECDSA + ML-DSA hybrid during transition)
Bitcoin bridge: hash-lock adapters with PQ commitments
Classical wallet migration ceremony (one-time key migration with audit log)
HD wallet derivation for PQC keys (BIP32-analog)
Eclipse attack mitigations (peer diversity requirements)
DoS resistance: proof-of-work puzzles on connection establishment

Deliverable: Interoperable testnet with Ethereum and Bitcoin bridges.

Phase 5 — Hardening, Auditing & Mainnet (Months 19–24)

Goal: Production readiness with formal security assurances.

Third-party cryptographic audit (target: NCC Group, Trail of Bits, or equivalent)
Fuzzing campaign: cargo-fuzz targets for all crypto and consensus code paths
Formal verification of consensus safety and liveness properties
Performance optimization: AVX-512 acceleration for NTT operations in lattice schemes
Hardware wallet integration (Ledger/Trezor PQC firmware support)
Governance framework for future algorithm upgrades
HQC integration (upon NIST finalization ~2027)
Mainnet genesis ceremony

Deliverable: Audited, production-grade mainnet launch.

⚡ Performance Benchmarks (Target)

Operation	Algorithm	Target Throughput
Signature Generation	ML-DSA (Dilithium2)	~3,000/sec/core
Signature Verification	ML-DSA (Dilithium2)	~5,000/sec/core
Signature Generation	FN-DSA (Falcon-512)	~1,500/sec/core
Key Encapsulation	ML-KEM-768	~15,000/sec/core
Tx Throughput (batch verify)	ML-DSA batched	~500 TPS (initial)
Block Finality	QPoS BFT	~3 seconds

Note: PQ signatures are 20–50x larger than ECDSA. Qbit uses off-chain signature storage and batch verification to recover throughput. Falcon's 666-byte signature is used for consensus messages to minimize block bloat.

🔒 Security Considerations for Contributors

No classical crypto in core paths. RSA, ECDSA, ECDH, and secp256k1 are only permitted inside the bridge/ and hybrid/ modules.
Constant-time requirement. Any code touching secret key material must use the subtle crate for comparisons and have a CI check via cargo clippy -- -D clippy::suspicious_arithmetic_impl.
XMSS/LMS state safety. If implementing stateful hash-based schemes for any reason, all state mutations must use atomic disk writes with a crash-recovery journal. Never allow state reuse.
Zeroize secrets. All structs holding private keys must implement zeroize::Zeroize and be annotated with #[zeroize(drop)].
No panics in crypto paths. Use Result types throughout; panics may be exploitable as timing side-channels or DoS vectors.
Third-party dependencies. New crypto dependencies require a security review issue before merging. Prefer pqcrypto, oqs, or liboqs-rust — all of which bind to constant-time reference implementations.

🧠 Design Decisions & Rationale

Why ML-DSA as primary, Falcon for consensus?

ML-DSA (Dilithium) has the fastest signing speed at 0.65 ms vs Falcon's 3.28 ms, making it better for high-volume user transactions. Falcon's advantage is signature compactness (~666 bytes vs ~2,420 bytes for Dilithium2), which matters for high-frequency validator vote messages where aggregate size dominates block overhead.

Why zk-STARKs over zk-SNARKs for the VM?

zk-SNARKs rely on elliptic-curve pairings (BN254, BLS12-381), which are broken by Shor's algorithm. zk-STARKs are based entirely on hash functions and are inherently post-quantum secure. The performance tradeoff (larger proofs) is acceptable for a PQ-first design.

Why not XMSS as the primary scheme?

XMSS is stateful — a signer must track which one-time keys have been used, and reuse is catastrophic. This makes it difficult to use safely at scale across distributed nodes. SLH-DSA (SPHINCS+) is stateless and offers equivalent hash-based security without the state management risk. XMSS remains available as an option in the crypto-agility layer for use cases where its smaller signature size is critical.

Why HQC as a future backup KEM?

NIST selected HQC (March 2025) specifically because it uses a different mathematical foundation (coding theory) than ML-KEM (lattice theory). If a breakthrough compromises lattice-based schemes, HQC provides a fallback KEM that remains secure under a completely different assumption.

📚 References & Further Reading

🤝 Contributing

Project Qbit is in active development. Contributions are welcome in the following areas:

Cryptographic primitive implementations and KAT validation
Consensus protocol research and implementation
Formal verification of safety properties
Performance optimization (AVX-512 NTT, parallelism)
Documentation and specification writing

Please read CONTRIBUTING.md before opening a PR. All cryptographic contributions require an accompanying security rationale and test vectors.

📄 License

Project Qbit is licensed under the Apache-2.0 License. See LICENSE for details.

⚠️ Disclaimer

Project Qbit is research-grade software. It has not been independently audited. Do not use it with real assets until a formal third-party audit has been completed and published. The cryptographic landscape is rapidly evolving — algorithm recommendations may change as new research emerges.

Built with 🦀 Rust and the conviction that the post-quantum era deserves a blockchain designed for it from day one.

Name		Name	Last commit message	Last commit date
Latest commit History 7 Commits
LICENSE		LICENSE
README.md		README.md

Folders and files

Latest commit

History

Repository files navigation

⚛️ Project Qbit

🌐 Overview

🚀 Key Features

🔐 Cryptographic Layer (Updated for 2025 NIST Standards)

⚖️ Quantum-Resistant Proof-of-Stake (QPoS)

🧠 Qbit VM — Quantum-Safe Smart Contracts

🔁 Signature Compression & Aggregation

🔒 Security Hardening (New in v0.2+)

🌉 Interoperability & Migration

🛡️ Threat Model

🛠️ Tech Stack

📁 Repository Structure

🏗️ Architecture Flowchart

🗺️ Implementation Plan

Phase 0 — Foundation (Months 1–3) ✅ In Progress

Phase 1 — Core Blockchain (Months 4–6)

Phase 2 — QPoS Consensus (Months 7–10)

Phase 3 — Qbit VM & Smart Contracts (Months 11–14)

Phase 4 — Network Security & Interoperability (Months 15–18)

Phase 5 — Hardening, Auditing & Mainnet (Months 19–24)

⚡ Performance Benchmarks (Target)

🔒 Security Considerations for Contributors

🧠 Design Decisions & Rationale

Why ML-DSA as primary, Falcon for consensus?

Why zk-STARKs over zk-SNARKs for the VM?

Why not XMSS as the primary scheme?

Why HQC as a future backup KEM?

📚 References & Further Reading

🤝 Contributing

📄 License

⚠️ Disclaimer

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Packages