Kaspa llega a SSP, y la biblioteca que lo hace posible es de código abierto

El soporte de Kaspa está en camino a SSP. Será el mismo multifirma 2 de 2 que ya usas para Bitcoin, Ethereum y Solana: una clave en SSP Wallet, otra en SSP Key, y nada se mueve si ambas no están de acuerdo. Las bóvedas empresariales también tendrán Kaspa.

Llegar hasta aquí nos obligó a construir algo que no existía. Hoy podemos compartir la parte que ya es pública: @runonflux/kaspa-core, una biblioteca TypeScript de código abierto para transacciones y multifirma en Kaspa, publicada bajo licencia MIT.

Por qué construimos primero una biblioteca

Cuando nos planteamos añadir Kaspa, revisamos todos los paquetes JavaScript de Kaspa que pudimos encontrar. Ninguno era capaz de construir y firmar de principio a fin una transacción multifirma de Kaspa, que es justo lo que SSP necesita por encima de todo.

La vía oficial es el código Rust de Kaspa compilado a WebAssembly. Es un software excelente, pero no encaja bien con SSP. SSP Key funciona sobre React Native, donde WebAssembly no está disponible, y la extensión del navegador tiene que mantenerse ligera: solo el paquete de WebAssembly ocupa más de 11 MB.

Así que escribimos desde cero las reglas de transacción de Kaspa en TypeScript puro: direcciones, scripts, multifirma M de N, hashes de firma, firma Schnorr, cálculo de comisiones y de «masa», y selección de entradas. Tiene dos dependencias en tiempo de ejecución, las bibliotecas criptográficas @noble, ampliamente usadas y auditadas, y funciona sin cambios en navegadores, extensiones, Node y React Native.

Cómo lo comprobamos

En el código de una billetera, «parece que funciona» no es un estándar. La biblioteca está diseñada para ser demostrablemente idéntica al propio nodo de Kaspa:

• Contrastada con el propio código de Kaspa. El conjunto de pruebas ejecuta cada función crítica para el consenso contra rusty-kaspa, la implementación de referencia del nodo, y procesa transacciones firmadas por la biblioteca a través de su motor de scripts real, incluidas todas las combinaciones M de N desde 1 de 1 hasta 15 de 15.
• Datos reales de mainnet. Se reproducen exactamente identificadores de transacción y firmas ya existentes en mainnet.
• Transacciones financiadas en mainnet. Quince transacciones reales, entre ellas gastos 2 de 2 al estilo de SSP, un 2 de 3 y multifirmas de tipo empresarial 4 de 7, 6 de 10 y 10 de 15, se construyeron y firmaron con la biblioteca y fueron aceptadas por la red. En cada una de ellas, el cálculo de la masa de la transacción hecho por el nodo coincidió exactamente con el nuestro.
• Revisión adversarial. Varias rondas de revisión de seguridad buscaron específicamente formas de engañar a un firmante o de inflar una comisión. No se encontraron problemas críticos, y cada hallazgo se corrigió con una prueba de regresión. El informe se publica junto al código.

El código abierto forma parte del mismo principio que las compilaciones reproducibles: no deberías tener que fiarte de nuestra palabra sobre lo que firma tus transacciones.

Cómo será Kaspa en SSP

Tu bóveda de Kaspa será una dirección multifirma de Kaspa (empieza por kaspa:p), derivada de tus dos dispositivos en la ruta de derivación habitual de SSP. Enviar funcionará igual que en otras cadenas: SSP Wallet prepara y firma su mitad, SSP Key te muestra los destinatarios, el importe y la comisión, y solo después de que lo apruebes allí llega la transacción a la red. Es el mismo modelo 2 de 2, en una cadena nueva.

Algunos detalles propios de Kaspa dieron forma al diseño:

• Cada dispositivo comprueba los importes por sí mismo. Una firma de Kaspa solo se compromete con el importe de la entrada que firma, así que un dispositivo que confiara en los importes que le entregan podría ser engañado sobre la comisión. En SSP, cada dispositivo consulta por su cuenta las monedas que se gastan antes de firmar, y solo firma para su propia bóveda.
• El identificador de la transacción se conoce antes de firmar. El identificador de transacción de Kaspa no incluye las firmas, así que SSP puede fijar una transacción a su identificador definitivo antes de que ninguna de las claves la haya firmado.
• Los límites de comisión vienen incorporados. Las comisiones tienen un tope, de modo que una mala estimación no puede convertirse en un error caro.

Para las empresas, las bóvedas de SSP Enterprise admitirán Kaspa con aprobación M de N, hasta el límite estándar de Kaspa de 15 claves por bóveda.

Qué no incluye la primera versión

Preferimos lanzar algo pequeño bien hecho que algo grande a medias. La primera versión cubre KAS en sí en mainnet. Los tokens KRC-20, la testnet de Kaspa, la firma de mensajes de Kaspa y WalletConnect para Kaspa no estarán incluidos en el lanzamiento.

Cuándo

El soporte de Kaspa ya está implementado en SSP Wallet, SSP Key y SSP Enterprise, y ahora mismo está pasando las pruebas finales. Lo anunciaremos aquí, con notas de la versión, cuando esté disponible. Hasta entonces no hay nada que activar ni nada que descargar, y quien te diga lo contrario no somos nosotros.

Mientras tanto, los desarrolladores ya pueden usar la biblioteca hoy: está en npm como @runonflux/kaspa-core y en GitHub en RunOnFlux/kaspa-core.