Research project · ten milestones · 237 tests

QChain

A research blockchain combining post-quantum signatures, quantum-randomized consensus, and real zk-STARK shielded payments. Built from scratch — every claim covered by tests.

post-quantum sigs
quantum randomness
zk-STARK proofs
shielded notes
P2P gossip
live dashboard
ELEVATOR PITCH

What is this?

QChain explores what it would take to build a system secure against today's adversaries AND against future quantum computers AND with real privacy AND on a working peer-to-peer network — all in one coherent project.

What it is

A complete research blockchain: transparent, shielded, and fully-anonymous transactions coexist in the same blocks, gossiped between real nodes, with a hand-rolled zk-STARK system written in Rust.

What it teaches

Post-quantum signatures, quantum randomness, zk-STARK design from scratch (AIR, FRI, Fiat-Shamir), shielded pool design, P2P consensus, fork resolution — by composing well-known primitives.

What it isn't

Production cryptocurrency software. No audits, no peer discovery, no DoS protection, in-memory only. Every shortcut is documented honestly in code and milestone READMEs.

THE THREAT MODEL

Two attacks. One chain that has to survive both.

Today's blockchains face two adversaries that aren't going away.

⚛ QUANTUM ADVERSARY

Shor's algorithm forges ECDSA

A sufficiently large quantum computer recovers private keys from public keys in polynomial time. Every secp256k1-signed transaction on Bitcoin / Ethereum becomes forgeable retroactively.

OUR ANSWER
Sign with Dilithium (NIST FIPS 204).
👁 SURVEILLANCE ADVERSARY

Public ledgers leak everything

Bitcoin and Ethereum reveal sender, recipient, and amount of every payment. Address clustering deanonymizes most users within months of normal activity.

OUR ANSWER
Spend via zero-knowledge STARK proof of ownership.
THE BIG IDEA

Five technical pillars

Each implemented end-to-end. Not stubbed.

1

Post-quantum signatures

Dilithium / ML-DSA-65 (NIST FIPS 204) replaces ECDSA on every transaction.

2

Quantum randomness

IBM Quantum QPU seeds stake-weighted PoS proposer selection.

3

Hand-rolled zk-STARKs

Custom AIR over Goldilocks in Rust. 96 tests including 14 adversarials.

4

Full P2P network

TCP gossip, message dedup, fork resolution, chain re-sync on join.

5

Live dashboard

FastAPI + WebSocket + React UI. Multi-node convergence in real time.

PRIVACY MATRIX

What each privacy layer hides

Compose them as needed. Or use all three.

Property Transparent Shielded (M3) Schnorr Anon (M4) STARK Anon (M8.6+)
Note values hidden
Recipient pubkey hidden
Spender pubkey hidden
Cross-spend unlinkability
Which leaf was spent: hiddenn/a
Value conservation in-proofn/a
Anonymity set sizen/an/a65,536
Post-quantum safe
KILLER DEMO · UNLINKABILITY

The same wallet. Two spends. Unlinkable.

What an external observer sees from each transaction.

SPEND A
nullifier63805cdddc692bd0…
leaf spent47f6c04a6e03ed45…
value commit0269eaf7239315e3…
pubkey commit02a4ff6a76084adb…
schnorr R021fc3089cdc1a20…
SPEND B
nullifierce0ad2f4c01929ac…
leaf spent561ca119d6037344…
value commit02cc03b10c7ea0a0…
pubkey commit02180887a34fef5f…
schnorr R03e2615d7f20763c…
MILESTONE 8 · ZK-STARK FROM SCRATCH

The gap M4 left open

M4's Schnorr proofs reveal the specific leaf being spent. And Schnorr breaks under quantum. So we built our own zk-STARK system in Rust.

The gap

M4 reveals which leaf was spent through the public Merkle path. That's unlinkable identity, not real anonymity. And Schnorr falls to Shor's algorithm.

What zk-STARK gives

A succinct proof that the spender knows some leaf in the pool — without revealing which one. Hash-based, quantum-safe by construction.

Why hand-rolled

Using an existing SNARK library would hide the AIR design choices that matter. The premise is honest cryptography end-to-end. Built on Winterfell; the AIR is ours.

Inside M8.3 — the AIR architecture

// trace layout: 17 cols × 64 rows
Block 0 (rows  0– 7):  LEAF       → P0
Block 1 (rows  8–15):  P0  + sib₁ → P1
Block 2 (rows 16–23):  P1  + sib₂ → P2
Block 3 (rows 24–31):  P2  + sib₃ → ROOT
Rows 32–63: padding (state unchanged)

// four constraint groups, all gated by periodic columns
hash round         deg 8    Rescue-Prime equation, fires within-block
block boundary     deg 3    next.input = swap_by_dir(prev.output, sibling)
witness static     deg 2    dir and sib stay constant within each 8-row block
direction binary   deg 2    dir × (dir − 1) = 0   — every direction bit is 0 or 1
MILESTONES 8.5 → 8.10

All four M8.5 gaps. Closed.

Every gap shipped open. Every gap closed in its own scoped milestone. None hand-waved.

GapWhat it wasM8.5FinalClosed by
A Value conservation — unshield amount not bound to leaf value OPEN CLOSED M8.8-A1 (range proof via 64 bit-decomposition cols)
B Nullifier binding — same note spendable many times OPEN CLOSED M8.6 (AIR computes nullifier = H(sk+1, r, v))
C Anonymity set ≤ 16 — too small to hide spends OPEN CLOSED M8.7-C (Merkle depth 4 → 16, set size 65,536)
D Pool not chain-replicated — each node had its own pool OPEN CLOSED M8.7-D (ShieldTransaction gossiped + replayed)
P2P propagation of STARK txs OPEN CLOSED M8.7 (new_stark_anon_tx wire message)
Chain replay validates historical STARK proofs OPEN CLOSED M8.10 (is_valid() re-verifies historical proofs)
BY THE NUMBERS

Real performance. Measured.

Release-mode single-core. No marketing math.

237
tests passing
96 Rust · 21 PyO3 · 120 Python
22ms
proof generation
depth 16 + range proof
0.6ms
proof verification
per STARK tx
STARK proving time · ms per proof
15.0
0.5
2.8
3.4
6.6
22.0
M8.1Fibonacci
M8.2Preimage
M8.3Merkle d=4
M8.6+ nullifier
M8.7depth 8
M8.8-A1depth 16
HONEST SCOPE

What's still NOT done — said openly

The line between cryptography and crypto-LARP is honesty about what works and what doesn't.

!
Sparse Merkle tree at depth 20+ — Depth 16 caps at 4 MB per tree. Depth 20 (1M-note set) needs sparse representation.
!
Partial-spend change outputs — Today every spend consumes the full leaf value. Partial spends need a second leaf hash inside the proof.
!
Anonymous deposits — Depositor address is visible at shield time. A mixer/CoinJoin layer would hide it.
!
Persistence — Chain is in-memory only. Restart loses everything.
!
DoS protection + peer authentication — Anyone who can TCP-connect is trusted. No rate limits, no TLS, no peer identity.
!
Wallet infrastructure — No hardware wallet support, recovery phrases, multi-device sync, or proper UI.
!
Security audit — The hand-rolled AIR has not been reviewed by a cryptography firm.