Los tres esquemas de firma post-cuántica de NIST: dos estándares finalizados y uno aún en borrador (FN-DSA) — ahora verifican dentro de un zkVM y se comprueban en cadena en la testnet de Kaspa, cada uno con un control contra manipulación. Sin emparejamientos en ninguna parte.
El mismo flujo para los tres: verificar la firma en un zkVM RISC Zero → comprimir a un STARK conciso (FRI/Poseidon2) → un nodo de Kaspa verifica el STARK en cadena mediante el opcode ZK de KIP-16. Sin Groth16.
• FIPS-204 - ML-DSA-44 / Dilithium (reticular).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 - SLH-DSA / SPHINCS+ (basado en hash).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (borrador) — FN-DSA / Falcon-512 (reticular/NTRU), implementación de Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
Y un paso más allá de verificar firmas: un UTXO asegurado con PQ - una moneda que solo se mueve con una firma ML-DSA válida sobre exactamente ese gasto. El convenio reconstruye el mensaje firmado a partir de la propia transacción (introspección), de modo que los fondos no se pueden redirigir, y la prueba queda vinculada a la transacción de financiación específica que firmó.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
Reproducimos esa prueba contra una segunda moneda en el mismo lock; el nodo la rechazó, y esa moneda sigue sin gastarse en el lock — la prueba en cadena con la que el replay no pudo moverla:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
El coste del zkVM abarca ~15×: Falcon ~1,8 min, ML-DSA ~8, SLH-DSA ~27 (SLH-DSA es basado en hash → miles de compresiones de SHA-256). Cada esquema tiene un control negativo - una prueba alterada o reproducida, rechazada en cadena — así que no es un no-op.
En términos claros: esto es la capa de firmas, no "Kaspa está listo para lo cuántico" - la minería cuántica y el compromiso UTXO de MuHash son problemas separados, más difíciles, y esto no los toca.
Testnet-10 PoC; las transacciones aún son secp256k1.
Complementario a XMSS de @Max143672 — la ruta de él es la nativa.
(Nuestros internos han estado ocupados)
El mismo flujo para los tres: verificar la firma en un zkVM RISC Zero → comprimir a un STARK conciso (FRI/Poseidon2) → un nodo de Kaspa verifica el STARK en cadena mediante el opcode ZK de KIP-16. Sin Groth16.
• FIPS-204 - ML-DSA-44 / Dilithium (reticular).
b7add3df69d54ca96b171771d92cad300d231504ed80ea55a9873edb08094eca
• FIPS-205 - SLH-DSA / SPHINCS+ (basado en hash).
01f747bc0e559bb7080d3e77dae8a4c1902545da1d97b55a9b37be90870f2342
• FIPS-206 (borrador) — FN-DSA / Falcon-512 (reticular/NTRU), implementación de Pornin.
aec459a84600caa13f6ce2c13104285c1b55c8cb8a986340bf5c135b65f15bc3
Y un paso más allá de verificar firmas: un UTXO asegurado con PQ - una moneda que solo se mueve con una firma ML-DSA válida sobre exactamente ese gasto. El convenio reconstruye el mensaje firmado a partir de la propia transacción (introspección), de modo que los fondos no se pueden redirigir, y la prueba queda vinculada a la transacción de financiación específica que firmó.
e33a1332e72266f361b6276449c6b3273bbb03a6fe1caff4d7db71f56806ff90
Reproducimos esa prueba contra una segunda moneda en el mismo lock; el nodo la rechazó, y esa moneda sigue sin gastarse en el lock — la prueba en cadena con la que el replay no pudo moverla:
31366d00a6eee4f36e04d977e34812f07c5adc86f580e934ba35e3ef5b855920
El coste del zkVM abarca ~15×: Falcon ~1,8 min, ML-DSA ~8, SLH-DSA ~27 (SLH-DSA es basado en hash → miles de compresiones de SHA-256). Cada esquema tiene un control negativo - una prueba alterada o reproducida, rechazada en cadena — así que no es un no-op.
En términos claros: esto es la capa de firmas, no "Kaspa está listo para lo cuántico" - la minería cuántica y el compromiso UTXO de MuHash son problemas separados, más difíciles, y esto no los toca.
Testnet-10 PoC; las transacciones aún son secp256k1.
Complementario a XMSS de @Max143672 — la ruta de él es la nativa.
(Nuestros internos han estado ocupados)
