Все три постквантовые схемы подписи NIST — две уже стандартизированные и одна всё ещё в черновике (FN-DSA) — теперь проверяются внутри zkVM и проверяются в блокчейне на Kaspa testnet, для каждой предусмотрен контроль подмены. Нигде нет парных отображений (pairings).
Один и тот же конвейер для всех трёх: проверяем подпись в RISC Zero zkVM → сжимаем в succinct STARK (FRI/Poseidon2) → узел Kaspa проверяет STARK в цепочке через KIP-16 ZK opcode. Никакого Groth16.
• FIPS-204 — ML-DSA-44 / Dilithium (решётки).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 — SLH-DSA / SPHINCS+ (хэш-основанная).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (черновик) — FN-DSA / Falcon-512 (решётки/NTRU), реализация Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
И шаг дальше проверки подписей: PQ-обеспеченный UTXO — монета, которая перемещается только с валидной подписью ML-DSA по этому точному расходу. Ковенант пересобирает подписанное сообщение из самого транзакционного содержимого (интроспекция), поэтому средства нельзя перенаправить, а доказательство привязано к конкретной финансирующей транзакции, которую оно подписало.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
Мы проиграли (replay) это доказательство второй монете с той же блокировкой; узел его отклонил, и эта монета всё ещё не потрачена на блокировке — то есть ончейн-доказательство реплея не смогло её переместить:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
Стоимость zkVM охватывает примерно ~15×: Falcon ~1,8 мин, ML-DSA ~8, SLH-DSA ~27 (SLH-DSA хэш-основанная → тысячи сжатий SHA-256). Для каждой схемы есть отрицательный контроль — подменённое или реплейнутое доказательство, которое отклоняется в цепочке, так что это не «no-op».
По сути, простыми словами: это слой подписи, а не «Kaspa уже квантово-готова» — квантовый майнинг и коммитмент UTXO в MuHash — отдельные, более сложные задачи, которые это не затрагивает.
Testnet-10 PoC; транзакции пока всё ещё secp256k1.
Дополнительно к @Max143672'у XMSS — у него нативный путь.
(Наши стажёры были заняты)
Один и тот же конвейер для всех трёх: проверяем подпись в RISC Zero zkVM → сжимаем в succinct STARK (FRI/Poseidon2) → узел Kaspa проверяет STARK в цепочке через KIP-16 ZK opcode. Никакого Groth16.
• FIPS-204 — ML-DSA-44 / Dilithium (решётки).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 — SLH-DSA / SPHINCS+ (хэш-основанная).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (черновик) — FN-DSA / Falcon-512 (решётки/NTRU), реализация Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
И шаг дальше проверки подписей: PQ-обеспеченный UTXO — монета, которая перемещается только с валидной подписью ML-DSA по этому точному расходу. Ковенант пересобирает подписанное сообщение из самого транзакционного содержимого (интроспекция), поэтому средства нельзя перенаправить, а доказательство привязано к конкретной финансирующей транзакции, которую оно подписало.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
Мы проиграли (replay) это доказательство второй монете с той же блокировкой; узел его отклонил, и эта монета всё ещё не потрачена на блокировке — то есть ончейн-доказательство реплея не смогло её переместить:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
Стоимость zkVM охватывает примерно ~15×: Falcon ~1,8 мин, ML-DSA ~8, SLH-DSA ~27 (SLH-DSA хэш-основанная → тысячи сжатий SHA-256). Для каждой схемы есть отрицательный контроль — подменённое или реплейнутое доказательство, которое отклоняется в цепочке, так что это не «no-op».
По сути, простыми словами: это слой подписи, а не «Kaspa уже квантово-готова» — квантовый майнинг и коммитмент UTXO в MuHash — отдельные, более сложные задачи, которые это не затрагивает.
Testnet-10 PoC; транзакции пока всё ещё secp256k1.
Дополнительно к @Max143672'у XMSS — у него нативный путь.
(Наши стажёры были заняты)
