Kaspa no es una red resistente a la computación cuántica. Lo que ocurrió en julio de 2026 fue una prueba de laboratorio en una red de pruebas, y el número que viajó por la cobertura —de 28 minutos a 16 segundos— mide el costo de generar una prueba criptográfica en una GPU alquilada, no la validación de una transacción en la red. Además, la «verificación independiente» que acompañó al anuncio no enfrenta al proyecto con un tercero: las dos tablas de cifras que circulan salieron del mismo proveedor.
Qué no cambió
En la red principal de Kaspa las transacciones se siguen firmando con Schnorr sobre secp256k1 —con ECDSA como alternativa, ambas de 64 bytes—, exactamente la criptografía de curva elíptica que una computadora cuántica suficientemente grande rompería. Las billeteras no migraron. La minería no cambió. No hay tipo de dirección poscuántica en producción.
Lo que existe es una propuesta identificada como KIP-16, con la etiqueta tag-0x21, corriendo en la testnet-10. El repositorio de Kii, la organización que desarrolla productos comerciales sobre Kaspa, se describe a sí mismo como artefacto de investigación pre-producción, sin auditar y sin declaración de disponibilidad para producción.
Por qué el tema aparece ahora
El NIST publicó como estándares FIPS-204 (ML-DSA) y FIPS-205 (SLH-DSA) en agosto de 2024; FIPS-206 (FN-DSA/Falcon) continúa en borrador. Lo que se movió después fueron los calendarios, no el estándar.
En Bitcoin, BIP-360 tiene número asignado desde diciembre de 2024 y sigue en estado Draft. Conviene leer qué hace: elimina el gasto por clave de Taproot para cerrar los ataques de exposición larga, reduciendo la exposición futura de claves públicas, pero no sustituye el esquema de firmas Schnorr en uso. Su propio texto deja las firmas poscuánticas para una propuesta posterior. BIP-361, asignada el 11 de febrero de 2026 y también en borrador, propone un apagado gradual de ECDSA y Schnorr, y consigna que al 1 de marzo de 2026 más del 34% del suministro de bitcoin tenía su clave pública expuesta en cadena. Ethereum discute una ruta distinta, con bifurcación dura y pruebas STARK.
Qué mide realmente el número
Las firmas poscuánticas pesan mucho más que los 64 bytes actuales: una ML-DSA-44 ocupa 2.420 bytes y una SLH-DSA-SHA2-128s, 7.856. Verificarlas dentro de una cadena cuesta espacio y tiempo. La salida que propone Kii es no anclar la firma en cadena sino una prueba de conocimiento cero: una computadora verifica la firma fuera de la cadena y genera una prueba compacta de que esa verificación salió bien. La red solo comprueba la prueba, que es corta, en vez de repetir el cálculo completo en cada nodo.
El precio de esa compresión es el trabajo de generar la prueba. Las mediciones publicadas por GhostProver, la infraestructura de pruebas de NTH MOMENT, desglosan el caso más pesado en una RTX 4090 con CUDA 12.8: 11,33 segundos de STARK compuesto más 4,89 de compresión sucinta, 16,22 segundos totales para SLH-DSA-128s. El mismo repositorio fija la línea base en CPU en 1.731,67 segundos y describe la mejora como 107 veces.
De dónde sale esa ganancia importa. SLH-DSA está construida sobre funciones hash y RISC Zero incluye un acelerador de SHA-256 que la corrida aprovecha, sumado a la GPU. No hay avance matemático nuevo: hay ingeniería de pruebas y silicio caro. El zkVM, además, solo prueba la verificación; la generación de llaves y la firma corren en el equipo anfitrión.
Las dos tablas vienen de la misma fuente
El repositorio de Kii presenta 1,91 segundos para Falcon-512, 5,35 para ML-DSA-44 y 16,33 para SLH-DSA, y aclara en su propio README que esos números los produjo de forma independiente GhostProver / NTH MOMENT, no Kii, sobre RISC Zero 3.0.6. El repositorio de GhostProver publica 2,47, 5,89 y 16,22 segundos, en corridas fechadas el 16 de julio de 2026 con RISC Zero 3.0.5.
No es el número del proyecto contra el número del auditor: son dos corridas del mismo laboratorio con dos versiones distintas de la herramienta. Parte de la cobertura en español invirtió las versiones, atribuyendo la 3.0.6 a la corrida independiente y la 3.0.5 al benchmark de Kii, cuando 3.0.5 es la versión que el repositorio de Kii fija para su propio código. Ninguna de las dos partes explica por qué Falcon-512 se mueve de 1,91 a 2,47 segundos entre corridas, casi 30% de diferencia.
Quedan tres incógnitas sin responder: no hay auditoría de seguridad del opcode, no hay datos de rendimiento con la red bajo carga real, y nadie sin relación contractual con Kii ha publicado una réplica con artefactos propios. La señal que cambiaría el cuadro es concreta: esa réplica externa, y el paso de testnet-10 a la red principal con un costo de prueba que alguien fuera de un centro de datos pueda pagar.
Lo que lees es análisis periodístico basado en datos verificados, no una predicción ni recomendación de inversión. CryptoArepa analiza, tú decides.
