Três esquemas de assinaturas pós-quânticas do NIST — dois padrões finalizados e um ainda em rascunho (FN-DSA) — agora verificam dentro de um zkVM e são checados on-chain na testnet do Kaspa, cada um com um controle de adulteração. Sem pareamentos em lugar nenhum.
Mesmo pipeline para os três: verificar a assinatura em um zkVM RISC Zero → comprimir para um STARK sucinto (FRI/Poseidon2) → um nó do Kaspa verifica o STARK on-chain via a opcode ZK KIP-16. Sem Groth16.
• FIPS-204 - ML-DSA-44 / Dilithium (em reticulados).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 - SLH-DSA / SPHINCS+ (baseado em hash).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (rascunho) — FN-DSA / Falcon-512 (reticulado/NTRU), implementação do Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
E mais um passo além de verificar assinaturas: um UTXO protegido por PQ — uma moeda que só se move com uma assinatura válida do ML-DSA sobre exatamente aquele gasto. A cláusula (covenant) reconstrói a mensagem assinada a partir da própria transação (introspecção), então os fundos não podem ser redirecionados, e a prova fica vinculada à transação específica de funding que ela assinou.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
Reexecutamos essa prova contra uma segunda moeda no mesmo lock; o nó rejeitou, e essa moeda ainda permanece não gasta no lock — a prova on-chain que a repetição não conseguiu mover:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
O custo do zkVM varia em ~15×: Falcon ~1,8 min, ML-DSA ~8, SLH-DSA ~27 (SLH-DSA é baseado em hash → milhares de compressões de SHA-256). Cada esquema tem um controle negativo — uma prova adulterada ou reexecutada, rejeitada on-chain — então não é um no-op.
Em termos simples: é a camada de assinaturas, não “Kaspa está pronto para o quantum” — mineração quântica e o compromisso do UTXO MuHash são problemas separados e mais difíceis, que isto não toca.
Testnet-10 PoC; as transações ainda usam secp256k1.
Complementar ao XMSS de @Max143672 — o dele é o caminho nativo.
(Os nossos estagiários têm estado ocupados)
Mesmo pipeline para os três: verificar a assinatura em um zkVM RISC Zero → comprimir para um STARK sucinto (FRI/Poseidon2) → um nó do Kaspa verifica o STARK on-chain via a opcode ZK KIP-16. Sem Groth16.
• FIPS-204 - ML-DSA-44 / Dilithium (em reticulados).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 - SLH-DSA / SPHINCS+ (baseado em hash).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (rascunho) — FN-DSA / Falcon-512 (reticulado/NTRU), implementação do Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
E mais um passo além de verificar assinaturas: um UTXO protegido por PQ — uma moeda que só se move com uma assinatura válida do ML-DSA sobre exatamente aquele gasto. A cláusula (covenant) reconstrói a mensagem assinada a partir da própria transação (introspecção), então os fundos não podem ser redirecionados, e a prova fica vinculada à transação específica de funding que ela assinou.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
Reexecutamos essa prova contra uma segunda moeda no mesmo lock; o nó rejeitou, e essa moeda ainda permanece não gasta no lock — a prova on-chain que a repetição não conseguiu mover:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
O custo do zkVM varia em ~15×: Falcon ~1,8 min, ML-DSA ~8, SLH-DSA ~27 (SLH-DSA é baseado em hash → milhares de compressões de SHA-256). Cada esquema tem um controle negativo — uma prova adulterada ou reexecutada, rejeitada on-chain — então não é um no-op.
Em termos simples: é a camada de assinaturas, não “Kaspa está pronto para o quantum” — mineração quântica e o compromisso do UTXO MuHash são problemas separados e mais difíceis, que isto não toca.
Testnet-10 PoC; as transações ainda usam secp256k1.
Complementar ao XMSS de @Max143672 — o dele é o caminho nativo.
(Os nossos estagiários têm estado ocupados)
