
Kaspa explicado: un blockDAG, diez bloques por segundo y cómo funciona la multifirma
La mayoría de las cadenas de prueba de trabajo producen los bloques de uno en uno: un minero encuentra un bloque, todos construyen sobre él y cualquier bloque rival encontrado en el mismo instante se descarta. Kaspa parte de otra pregunta: ¿y si los bloques paralelos no se desperdiciaran en absoluto?
La respuesta es un blockDAG, y es la razón por la que Kaspa puede producir diez bloques cada segundo sin dejar de ser de prueba de trabajo. Ahora que el soporte de Kaspa llega a SSP, veamos qué lo hace diferente y cómo funciona la multifirma en él.
De la cadena al DAG
En Bitcoin, si dos mineros encuentran bloques casi al mismo tiempo, la red se bifurca temporalmente. Al final uno de los bloques gana y el otro queda huérfano: el trabajo que hay detrás simplemente se pierde. Para que los huérfanos sean raros, Bitcoin apunta a un bloque cada diez minutos, tiempo suficiente para que cada bloque llegue a toda la red antes de que se encuentre el siguiente.
Kaspa elimina esa restricción. Cada bloque nuevo puede hacer referencia a varios bloques anteriores en lugar de a uno solo, de modo que todos los bloques creados en paralelo pasan a formar parte del registro. La estructura deja de ser una única cadena y se convierte en un grafo acíclico dirigido: un DAG.
Un DAG por sí solo tiene un problema: si dos bloques paralelos contienen transacciones en conflicto, ¿cuál cuenta? El protocolo de consenso de Kaspa, GHOSTDAG, lo resuelve ordenando todos los bloques de forma coherente. Identifica la mayoría bien conectada de bloques construidos por mineros honestos y clasifica todo en un único orden acordado, de modo que cada nodo llega al mismo veredicto sobre qué transacción fue primero.
El resultado es que Kaspa puede funcionar a diez bloques por segundo —el ritmo desde su actualización Crescendo de 2025— sin el desperdicio de huérfanos que paralizaría a una cadena a esa velocidad. Sigue usando la prueba de trabajo para proteger el registro.
Qué significa en la práctica
- Confirmaciones rápidas. Las transacciones se recogen en más o menos un segundo. Como en cualquier cadena, la profundidad de confirmación sigue importando para importes grandes —cada bloque construido encima hace que una transacción sea más difícil de deshacer—, pero esa profundidad se acumula rápido.
- Monedas, no cuentas. Kaspa usa el modelo UTXO, como Bitcoin: tu saldo es un conjunto de monedas individuales, y al gastar se combinan algunas de ellas y el cambio vuelve a ti.
- Poda. Los nodos de Kaspa no guardan todo el historial para siempre; los datos de bloques antiguos se podan pasado aproximadamente un día y medio. El estado actual siempre es verificable, pero el historial de transacciones a largo plazo queda en manos de indexadores y exploradores, no de cada nodo.
- Unidades pequeñas. Un KAS equivale a 100.000.000 sompi, la unidad más pequeña de Kaspa.
Las comisiones se miden en «masa»
Bitcoin pone precio al espacio de bloque en bytes. Kaspa lo hace en masa, que combina varios costes:
- Tamaño: cuántos bytes ocupa la transacción.
- Operaciones de firma: cada verificación de firma añade una cantidad fija, así que un gasto multifirma pesa más que uno de clave única.
- Almacenamiento: una regla conocida como KIP-9 encarece las transacciones que crean muchas salidas diminutas, para evitar que el registro se llene de polvo.
En los envíos cotidianos esto es invisible: las comisiones son pequeñas. Pero explica algunas peculiaridades de Kaspa, como por qué puede rechazarse devolverte a ti mismo un cambio muy pequeño, o por qué las carteras a veces necesitan consolidar muchas monedas pequeñas antes de un pago grande.
Cómo funciona la multifirma en Kaspa
Kaspa tiene deliberadamente pocos tipos de dirección. Una dirección kaspa:q está controlada por una sola clave. Una dirección kaspa:p es de pago a hash de script: se compromete con un script, y para gastar hay que revelar ese script y cumplirlo.
Un vault multifirma es una dirección kaspa:p cuyo script dice «M de estas N claves deben firmar». Kaspa usa firmas Schnorr, admite hasta 20 claves por script a nivel de consenso y retransmite transacciones estándar con hasta 15. Dos detalles hacen que sea agradable trabajar con él:
- El ID de la transacción no incluye las firmas. Conoces el ID definitivo de una transacción antes de que nadie la haya firmado, lo que simplifica la coordinación de firmas entre dispositivos.
- No hay capa SegWit ni Taproot. Kaspa tiene solo tres tipos de salida estándar —de clave única, su variante ECDSA y pago a hash de script—, así que solo hay un tipo de vault multifirma que hacer bien.
Hay una sutileza que importa para la seguridad. Una firma de Kaspa se compromete solo con el importe de la entrada concreta que firma, no con el importe de todas las entradas. Por eso, una cartera multifirma cuidadosa hace que cada firmante consulte por su cuenta las monedas que se gastan, en lugar de fiarse de importes proporcionados por otro dispositivo.
Kaspa en SSP
SSP está añadiendo Kaspa con el mismo modelo 2 de 2 que en todas las demás cadenas: tu vault es una dirección kaspa:p construida a partir de una clave en SSP Wallet y otra en SSP Key, y cada dispositivo comprueba de forma independiente lo que está firmando. SSP Enterprise admitirá vaults de Kaspa con aprobación M de N.
Todavía no está disponible: el soporte de Kaspa está en la fase final de pruebas y se anunciará con notas de versión cuando se publique. La biblioteca que hay detrás, @runonflux/kaspa-core, ya es de código abierto para quien quiera leerla o reutilizarla.
El resumen honesto
Kaspa toma una idea conocida —la prueba de trabajo protegiendo un registro UTXO— y elimina el cuello de botella de un bloque cada vez permitiendo que los bloques formen un DAG. El resultado son bloques rápidos, comisiones basadas en la masa en lugar de en los bytes y un diseño multifirma limpio construido en torno a un único tipo de script.
Como en cualquier cadena, lo que mantiene tus monedas a salvo no es el ritmo de bloques. Es quién controla las claves y, con multifirma, cuántas de ellas tienen que estar de acuerdo.


