Kaspa Kii@KaspaKii
Hi Pavel, happy to.
Sound vs bound: both, and worth separating two layers. The guest runs the actual verification algorithm (RustCrypto ml-dsa/slh-dsa, Pornin's fn-dsa-vrfy) and only halts with exit code 0 if verify returns valid. The STARK proves that exact program - pinned by its image ID - executed and halted over the committed journal. So a valid proof to the real verification ran on the committed (pk, message) and accepted: soundness, not just a binding.
The two layers, kept separate: the three on-chain results in the table prove verification - the real verifier ran in-zkVM and accepted a (pk, msg) committed in the journal. By themselves they're replayable attestations, not spend authorsation. Spend-binding is a separate construction (a PQ-UTXO, tx e33a1332): there the covenant reconstructs the signed message - input outpoint + the single output's amount/spk - from the tx via KIP-10 introspection, so the proof only validates this spend. So don't read the table rows as spend-auth; spend-auth is the PQ-UTXO.
The one thing none of it asserts is that the verifier matches FIPS bit-for-bit , a valid proof faithfully proves "this code ran and accepted," so correctness rests on the verifier (→ KATs) plus RISC0's STARK soundness (FRI proximity-gap conjecture + Fiat-Shamir-in-QROM heuristic ~ conjectured, not proven; no DL/pairing, so no Shor exposure).
KATs - we ran them. All 29 official NIST ACVP sigVer vectors ran through the crate's verify_with_context - byte-identical source to what the guest compiles to RISC-V, executed host-native (the full sweep in-zkVM is just slow, not different; deterministic, so host-native == in-zkVM). ML-DSA-44 (FIPS-204): 15/15 match NIST (3 accept, 12 should-reject, all correctly rejected). SLH-DSA-SHA2-128s (FIPS-205): 14/14. To close the "did you run the actual ELF" gap, I ran the real in-zkVM guest ELF on a valid + a one-byte-tampered case per scheme -accepts valid, rejects tampered. So: 29for29 on the exact source, 2-per-scheme end-to-end in-circuit.
Falcon: FIPS-206 is draft with no final NIST ACVP, so that verifier I have only via roundtrip + the on-chain proof - explicitly not claiming Falcon KAT-clean (its on-chain ✓ means the proof verifies that this verifier ran, not that it's FIPS-conformant; same-day re-run when the vectors drop).
Benchmarks:: (single M1 Max, CPU, unoptimised; prove = composite + succinct compression; proof is a constant 222,668-byte succinct receipt, size-fixed regardless of cycle count):
Falcon-512 ~2.4 min (115s + 29s, measured this session);
ML-DSA-44 ~9 min,
SLH-DSA-SHA2-128s ~28 min (last two: composite from prior runs on the same machine, succinct tail re-measured - stable to the minute).
SLH-DSA heaviest because hash-based verification is thousands of SHA-256 - your point exactly, proving is the gating constraint.
Prover network I guess it's under consideration. Proving is also compute-heavy and embarrassingly parallel, which makes pointing otherwise stranded compute (and the energy behind it) at a verifiable-proof market an interesting angle. I think more to consider once it's past a sketch.
Scopewise fully agreed. Spend-auth layer. The tx envelope is secp256k1 Schnorr and mining is kHeavyHash PoW both classical so "Kaspa is PQ" would be wrong and we don't say it. (One place we've started poking past spend-auth is a hash-only UTXO-set accumulator - the MuHash/commitment layer -feasibility primitive, not consensus-integrated).
