Research-stage protocol for scalable post-quantum blockchain infrastructure

Build the post-quantum migration layer before it becomes urgent

QLSA aggregates thousands of post-quantum signatures into a single constant-size proof, targeting scalable blockchain verification without trusted setup and without forcing a hard fork.

View GitHub See Roadmap

QLSA (Quantum-Layered Signature Aggregation) is an open deep-tech project exploring how ML-DSA, Merkle commitments, and STARK proofs can make post-quantum blockchain systems operationally viable.

FocusInfrastructure, not just cryptography
ApproachBenchmark-first MVP with staged proof integration
StatusPhase 1 — Core implementation

The Problem

Direct migration from classical signatures to post-quantum signatures can severely inflate block payloads. That turns protocol safety progress into an operational scaling problem.

Signature Size 3000 tx block Operational impact
ECDSA (current)~70 bytes~220 KBFits today’s assumptions
ML-DSA-65 (FIPS 204)~2,420 bytes~7.2 MBSevere throughput penalty
~30–40×Payload overhead from direct migration
FIPS 204Standardized signature base
Hash-firstNo trusted setup in the proving path
L2-readyDeployment path without hard fork

The Solution

QLSA is not a new signature scheme. It is a post-quantum aggregation layer that aims to make large signature sets proof-friendly, compact, and verifiable at fixed on-chain cost.

What QLSA does

  • Aggregates N ML-DSA signatures into one batch commitment
  • Uses Merkle commitments to structure batch data
  • Generates a STARK proof for batch correctness
  • Allows fixed-cost on-chain verification independent of batch size

Why the architecture matters

  • Heavy proving remains off-chain
  • Public inputs can be kept minimal with commitment roots
  • MVP can ship before full ML-DSA-inside-AIR is solved
  • The system remains crypto-agile across future upgrades

Architecture

The system is split into three layers so that user flows stay familiar, proving stays off-chain, and on-chain verification remains lean.

Layer 1

Signing

Wallet-level signing using post-quantum keys.

  • ML-DSA-65 for signatures
  • Address derived from SHA3-256(pubkey)
  • Intended to preserve a familiar wallet-style UX
Layer 2

Aggregation

Batch formation and proving pipeline.

  • Collect transactions off-chain
  • Verify ML-DSA signatures off-chain in the MVP
  • Build Merkle tree with SHA3-512
  • Generate STARK proof for correctness claims
Layer 3

Verification

Constant-cost contract-side validation.

  • Verify proof in Solidity verifier contract
  • Store merkle_root and finalize the batch
  • Favor commitment roots over raw pubkey arrays in public inputs

MVP Strategy

The project intentionally separates realistic implementation milestones from the hardest research component.

StageWhat STARK provesML-DSA in STARK
MVP-1Core crypto onlyNo
MVP-2Merkle correctnessNo
MVP-3ML-DSA verificationResearch target

Key risks

  • ML-DSA inside STARK: NTT and modular arithmetic can make AIR expensive.
  • Aggregator trust model: the MVP relies on off-chain verification before challenge systems exist.
  • Adoption timing: the need is real, but mainstream migration may still take years.
Research-driven Benchmark-first Security-aware

Tech Stack

The technical stack reflects a staged path: fast iteration now, stronger proving infrastructure later.

Cryptographic core

  • ML-DSA-65
  • SHA3-512 for Merkle hashing
  • SHA3-256 for address derivation
  • Python 3.10+
  • liboqs-python >= 0.14.0

STARK layer

  • Winterfell for prototyping AIR
  • Stwo / Circle STARK for production path
  • FRI-based proofs
  • No trusted setup

Contracts & infra

  • Solidity + Hardhat
  • Target L2: Polygon zkEVM or Starknet
  • Aggregator node architecture planned
  • Benchmarks and docs published in-repo

Performance targets

Batch size3,000 tx
Proof size90–200 KB
On-chain verificationO(1)
Current proving focusMerkle-first MVP

Repository snapshot

QLSA/
├── core/
├── aggregator/
├── stark/
├── contracts/
├── sdk/
├── benchmarks/
├── docs/
├── tests/
└── CONTEXT.md

Roadmap

The roadmap prioritizes a credible implementation path before expanding into the hardest proving research.

Phase 1 — Core

In progress

ML-DSA keys, signing, verification, and Merkle tree implementation.

Phase 2 — STARK Prototype

Planned

Merkle correctness inside STARK, plus benchmarks and feasibility measurements.

Phase 3 — Smart Contracts

Planned

On-chain verifier and batch registry for fixed-cost verification flow.

Phase 4 — Aggregator Node

Planned

Mempool integration, batching logic, and off-chain proof pipeline.

Phase 5 — SDK

Planned

Developer-facing Python and JavaScript tooling for wallet and transaction integration.

Phase 6 — Testnet

Future

Public deployment, end-to-end demo, and benchmark-backed technical validation.

FAQ

Short answers to the questions most people will ask when they first encounter the project.

Is QLSA a new signature algorithm?

No. QLSA is an aggregation and verification architecture built around post-quantum signatures such as ML-DSA.

Why not just replace ECDSA directly?

Because the size increase of post-quantum signatures can cause major throughput and cost problems if deployed naively.

Does the MVP already prove ML-DSA inside STARK?

No. The MVP intentionally starts with a lower-risk path and treats full ML-DSA-inside-STARK as a later research milestone.

Is this production-ready?

No. QLSA is currently research-stage software and should not be used in production systems.

Interested in PQC, ZK proofs, or blockchain infrastructure?

QLSA is an open research and engineering effort. Contributions, technical feedback, research discussion, and collaboration are welcome.

Email: research@qlsa-protocol.online
GitHub: github.com/hoxitoo/QLSA
Contact Open Repository