3. Cryptographic Primitives Deep-Dive
Section 2 described which algorithms Quantos uses and why. This section documents the supporting primitives in quantos/src/crypto/ that make a post-quantum chain practical at scale. Post-quantum objects are large and expensive; without these accelerations and constructions, a PQC-native L1 would not meet its latency or bandwidth targets.
3.1 Hashing and Domain Separation
All hashing uses the SHA-3 family — SHA3-256 for fixed-length digests and SHAKE256 as an extendable-output function (XOF) — both of which retain a 128-bit security margin against Grover search at 256-bit output (crypto/hash.rs).
Every signed or hashed object is domain-separated (crypto/domains.rs): a context tag is prepended before hashing so that a signature valid in one context (e.g. a transaction, DOMAIN_TX) can never be replayed as a valid signature in another (e.g. a pipeline vote, DOMAIN_PIPELINE_VOTE). This eliminates an entire class of cross-protocol signature-confusion attacks.
3.2 Post-Quantum Merkle Trees
crypto/merkle_pq.rs implements quantum-resistant Merkle trees over SHA3-256. These back account storage roots, the signature-aggregation commitments, the L0 attestor trees, and the cross-shard availability proofs. Because security rests only on the collision resistance of a hash function — not on any number-theoretic assumption — Merkle proofs remain secure against quantum adversaries with no parameter changes.
3.3 ML-KEM-768 Internals
crypto/kyber_kem.rs provides the Kyber768-compatible KEM wrapper used for P2P session establishment.
3.4 Hardware Acceleration
Post-quantum verification is CPU-bound, so the crypto layer is heavily optimised:
| Module | Optimisation |
|---|---|
crypto/simd.rs | SIMD vectorisation of lattice polynomial arithmetic |
crypto/precomputed.rs | Precomputed NTT twiddle-factor tables |
crypto/zero_copy.rs | Zero-copy verification paths avoiding buffer allocation |
crypto/memory_pool.rs | Reusable buffer pools to avoid per-verification allocation |
crypto/batch.rs, crypto/batch_verify.rs | Parallel batch verification across cores |
crypto/verify_worker.rs | Dedicated verification worker threads |
These modules are intended to reduce allocation and verification overhead. Signature cost and scaling depend on the concrete ML-DSA-65 implementation, compiler, hardware, batch size and workload; no universal microsecond figure is established here.
3.5 Primitive Inventory
The current cryptographic inventory includes ml_dsa.rs (ML-DSA-65), kyber_kem.rs (ML-KEM-768-compatible), sphincs.rs (SPHINCS+), vrf_hashbased.rs (Rescue-Prime + STARK VRF), Merkle/hash modules, signature aggregation, batch verification, and key lifecycle code. Their protocol roles are not interchangeable: ordinary signing, finality, P2P KEM, VRF-style selection and L0 aggregation use different paths. The exact active set must be tied to the node configuration and source commit.