"Hilar secuencias. Combinar. Mejorar. Nunca perfecto. Perfeccion meta que cambia."
— Abathur, StarCraft II: Heart of the Swarm
Kerrigan es una criptomoneda de prueba de trabajo multi-algoritmo que combina diversidad de hardware, privacidad de conocimiento cero y una novedosa capa de consenso basada en sellos llamada Hivemind Protocol. Cuatro algoritmos de mineria (X11, KawPoW, Equihash 200,9 y Equihash 192,7) funcionan simultaneamente desde el genesis, cada uno con ajuste de dificultad independiente derivado del enfoque multi-algoritmo de DigiByte. Las transacciones protegidas con zk-SNARK Sapling otorgan a los usuarios la opcion de privacidad transaccional completa. El Hivemind Protocol agrega una segunda dimension de consenso sobre PoW, donde los mineros sellan colectivamente los bloques mediante atestaciones firmadas con BLS y seleccion de comite aleatorio verificable. V1 se lanza como una cadena enfocada en la mineria con masternodes y gobernanza en cadena. V2 extiende la red hacia la computacion GPU para inferencia de IA, redirigiendo las recompensas de bloque para incentivar a los proveedores de inferencia junto con los mineros.
La mayoria de las cadenas de bloques de prueba de trabajo dependen de un unico algoritmo de mineria. Esto crea una red fragil donde un fabricante de hardware o un diseno ASIC puede dominar la tasa de hash, y una sola vulnerabilidad algoritmica puede comprometer toda la cadena. El SHA-256 de Bitcoin se mina casi exclusivamente con ASICs especializados. El Ethash de Ethereum Classic sufrio ataques repetidos del 51% despues de que los mineros GPU migraran al Ethereum de prueba de participacion. Las cadenas de un solo algoritmo concentran el riesgo.
La privacidad es la otra brecha. Las cadenas PoW transparentes exponen cada transaccion al analisis publico. Las empresas de analisis de cadena pueden rastrear fondos a traves de saltos, vincular direcciones a identidades y construir perfiles financieros completos. Algunas cadenas agregan privacidad opcional como una ocurrencia tardia; otras sacrifican la transparencia por completo. Ninguno de los dos extremos sirve bien a los usuarios.
Kerrigan aborda ambos problemas. Cuatro algoritmos de mineria aseguran que ninguna clase de hardware pueda monopolizar la produccion de bloques. Los mineros ASIC compiten en X11 mientras que los mineros GPU se distribuyen entre KawPoW, Equihash 200,9 y Equihash 192,7. Cada algoritmo tiene su propio ajuste de dificultad, por lo que los cambios de tasa de hash entre algoritmos no desestabilizan la red. Las transacciones protegidas con zk-SNARK Sapling proporcionan privacidad criptografica para los usuarios que la deseen, sin eliminar la capa de transacciones transparentes.
La cadena esta construida sobre un fork de Dash, heredando la lista determinista de masternodes (DIP3), servicios basados en quorum (LLMQ) y el sistema de sporks para la activacion segura de funcionalidades. Eliminamos lo que no necesitabamos, reemplazamos lo que no encajaba y construimos nuevos sistemas donde el codigo heredado se quedaba corto. El motor PoW multi-algoritmo, la integracion de Sapling y el Hivemind Protocol son todos originales de Kerrigan.
Kerrigan ejecuta cuatro algoritmos de mineria en paralelo, todos activos desde el bloque genesis. Cada bloque es minado por exactamente un algoritmo, y el algoritmo se codifica directamente en el campo de version del bloque.
X11 es la funcion hash nativa de Dash: once funciones criptograficas encadenadas (BLAKE, BMW, Groestl, JH, Keccak, Skein, Luffa, CubeHash, SHAvite, SIMD, ECHO). Es minable con ASIC, lo que significa que la tasa de hash de X11 probablemente sera dominada por hardware especializado. Esto es intencional. Los ASICs proporcionan un hashing consistente y de alto rendimiento que estabiliza la capa base.
KawPoW es la variante ProgPoW de Ravencoin, un algoritmo optimizado para GPU que resiste el desarrollo de ASICs mediante la generacion aleatoria de programas. La implementacion de KawPoW de Kerrigan es compatible a nivel de protocolo con Ravencoin, lo que significa que los mineros RVN existentes pueden apuntar sus equipos a los pools de Kerrigan con una configuracion minima. Los bloques KawPoW llevan campos de encabezado adicionales: nHeight, nNonce64 (nonce de 8 bytes) y mix_hash (32 bytes).
Equihash 200,9 es el algoritmo de Zcash con uso intensivo de memoria. Los parametros (200,9) requieren aproximadamente 700 MB de memoria de trabajo por intento de solucion. Existen ASICs para Equihash 200,9 (notablemente la serie Bitmain Z9), por lo que este carril no es estrictamente solo GPU. Kerrigan utiliza un formato de encabezado compatible con Zcash de 140 bytes: 108 bytes de CEquihashInput (version, hash previo, raiz merkle, hash reservado, tiempo, bits) mas un nNonce256 de 32 bytes. Las soluciones se serializan con un limite de 1400 bytes.
Equihash 192,7 utiliza parametros diferentes que reducen los requisitos de memoria comparados con (200,9) mientras mantienen la resistencia a ASICs. El conjunto de parametros (192,7) fue popularizado por ZClassic y otros forks de Equihash. Mismo formato de encabezado que Equihash 200,9 pero con su propio espacio de solucion y curva de dificultad.
El algoritmo de mineria se codifica en los bits 8 a 11 del campo nVersion del bloque, utilizando una mascara de 0x0F00:
| Algoritmo | Enum Interno | Bits de Version | Hex |
|---|---|---|---|
| X11 | ALGO_X11 = 0 | 0 << 8 | 0x0000 |
| KawPoW | ALGO_KAWPOW = 1 | 2 << 8 | 0x0200 |
| Equihash 200,9 | ALGO_EQUIHASH_200 = 2 | 4 << 8 | 0x0400 |
| Equihash 192,7 | ALGO_EQUIHASH_192 = 3 | 6 << 8 | 0x0600 |
Los valores enum internos (0-3) se usan en el codigo para indexacion de arreglos. Los bits de version usan un espaciado par (0, 2, 4, 6) para dejar espacio a futuros algoritmos. El mapeo entre ellos es una tabla de busqueda, no un desplazamiento directo de bits del valor enum.
Cualquier codigo que inspeccione nVersion para la senalizacion de soft-fork BIP9 debe eliminar primero los bits 8-11. El WarningBitsConditionChecker omite estos bits para evitar alertas falsas.
Kerrigan utiliza dos hashes distintos por bloque: un hash de identidad para la indexacion y un hash de prueba de trabajo para la validacion de mineria.
El hash de identidad es X11 calculado sobre el encabezado base del bloque. Para bloques X11 y KawPoW, este es el encabezado estandar de 80 bytes (version, hash previo, raiz merkle, tiempo, bits, nonce). Para bloques Equihash, son 140 bytes (version, hash previo, raiz merkle, hashReserved, tiempo, bits, nNonce256). Esto es lo que referencia hashPrevBlock, lo que devuelven los RPCs y lo que usa el indice de la cadena. X11 se usa para el hashing de identidad en todos los algoritmos para que cada nodo pueda indexar cada bloque de la misma manera.
El hash de prueba de trabajo es especifico del algoritmo y compromete todos los campos criticos de consenso para ese algoritmo:
Este diseno de doble hash significa: el hash de identidad proporciona un ID de bloque estable y uniforme a traves de todos los algoritmos, mientras que el hash PoW asegura que los campos especificos del algoritmo (soluciones, mix hashes, nonces extendidos) estan completamente comprometidos y son a prueba de manipulacion. Ver Apendice A para los disenos exactos de bytes serializados por algoritmo.
Cada algoritmo tiene su propia dificultad independiente, ajustada usando un esquema derivado de la dificultad multi-algoritmo de DigiByte (DigiShield v4). Los parametros:
Esta dificultad por algoritmo significa que una afluencia repentina de mineros GPU en KawPoW no afectara la dificultad de X11 ni la de Equihash. Cada algoritmo encuentra su propio equilibrio de forma independiente.
El suministro sigue un calendario estandar de halving: 25 KRGN para los primeros 1.051.200 bloques, luego 12,5, luego 6,25, y asi sucesivamente. La serie geometrica converge a 52.560.000 KRGN en total.
La transaccion coinbase de cada bloque divide la recompensa de 25 KRGN en cinco partes:
| Destinatario | Porcentaje | KRGN/Bloque | Custodia | Proposito |
|---|---|---|---|---|
| Fondo de Crecimiento | 40% | 10,00 | Deposito bloqueado por consenso | Listados en exchanges, alianzas, desarrollo del ecosistema |
| Mineros | 20% | 5,00 | Liberado inmediatamente | Recompensa de bloque PoW |
| Masternodes | 20% | 5,00 | Liberado inmediatamente | Servicios de red (pasa al minero si no hay MNs registrados) |
| Tesoreria | 15% | 3,75 | Multisig 2-de-3 | Costos operativos, marketing, comunidad, salarios del equipo |
| Dev / Fundadores | 5% | 1,25 | Liberado inmediatamente | Compensacion de fundadores y compromiso continuo con el proyecto |
El fondo de crecimiento no es una tesoreria. Es un deposito bloqueado por consenso que el equipo no puede gastar sin la aprobacion de los masternodes (ver Seccion 3.4). Las asignaciones de Tesoreria y Dev/Fundadores (20% combinado) son el presupuesto operativo del proyecto, comparable al historico fondo de desarrollo del 20% de Zcash. La diferencia: la direccion de Tesoreria es un multisig P2SH 2-de-3 que requiere dos de tres titulares de claves para autorizar cualquier gasto. Si no hay masternodes registrados en la red, el 20% de masternodes se queda con el minero como mecanismo de degradacion elegante.
Kerrigan no tiene respaldo de capital de riesgo, ni ICO, ni preminado, ni venta de tokens. El hardware se paga de bolsillo. El codigo es escrito por el equipo. No hay un fondo de guerra de $5M en un multisig de una ronda de financiacion semilla.
Eso significa que la red tiene que financiar su propio crecimiento. Los listados en exchanges, la provision de liquidez, los despliegues de puentes y los acuerdos de alianzas cuestan dinero real, y sin financiacion externa, la cadena misma es la unica fuente. El deposito de crecimiento es el mecanismo que convierte las monedas minadas en un activo negociable. Sin listado en exchange no hay liquidez. Sin liquidez, las monedas que ganan los mineros no valen nada.
El deposito de crecimiento acumula 10 KRGN por bloque:
Asi es como se ve a diferentes precios de KRGN, asumiendo un listado tipico en exchange de nivel 2 a $150.000 y un listado de nivel 3 a $30.000:
| Precio KRGN | Deposito / Mes | Tiempo para Listado Nivel 3 ($30K) | Tiempo para Listado Nivel 2 ($150K) |
|---|---|---|---|
| $0,01 | $2.160 | ~14 meses | ~69 meses |
| $0,05 | $10.800 | ~3 meses | ~14 meses |
| $0,10 | $21.600 | ~6 semanas | ~7 meses |
| $0,50 | $108.000 | ~8 dias | ~6 semanas |
| $1,00 | $216.000 | ~4 dias | ~3 semanas |
Incluso a $0,05 por KRGN, el deposito puede financiar un listado en exchange de nivel 3 en un solo trimestre. A $0,10, un listado de nivel 2 se vuelve alcanzable dentro del primer ano.
El deposito es temporal. Tiene un techo fijo en el bloque 262.800 (~12 meses). Cada moneda en el esta bloqueada desde el momento en que se acuna. Ninguna moneda sale del deposito sin una votacion de masternodes aprobando un gasto especifico.
La asignacion del 40% del fondo de crecimiento se acuna en cada bloque y se envia a una direccion de deposito bloqueada por consenso. Las monedas existen en la cadena, cuentan para el suministro total y son completamente auditables, pero no se pueden gastar. Ningun firmante multisig, ningun miembro del equipo, ninguna entidad individual puede moverlas. El gasto requiere que la red de masternodes apruebe una propuesta especifica.
Votacion de continuacion: Cada ciclo de superbloque (16.616 bloques, aproximadamente 23 dias), la acumulacion continua del deposito tambien debe ser renovada por votacion de masternodes. Si la votacion de continuacion falla, la salida coinbase del 40% se quema durante el siguiente ciclo en lugar de entrar al deposito. Sin voto no hay acumulacion. La apatia mata al fondo, no la accion.
Que sucede al vencimiento: Cuando el deposito de crecimiento termina (por votacion de continuacion fallida o techo fijo en el bloque 262.800), las monedas bloqueadas restantes se queman via OP_RETURN. La asignacion coinbase del 40% se quema para todos los bloques subsiguientes. Esto no se redirige a mineros, masternodes ni a ninguna otra parte. Las monedas quemadas reducen el suministro circulante, beneficiando a todos los poseedores por igual. La reestructuracion de recompensa de bloque V2 (Seccion 3.6) es una actualizacion de consenso separada que redirige el 40% a los proveedores de inferencia de IA.
El 20% restante de las recompensas de bloque (Tesoreria 15% + Dev/Fundadores 5%) es el presupuesto operativo del proyecto. Estas monedas se liberan normalmente, no estan bloqueadas en deposito.
Tesoreria (15% / 3,75 KRGN por bloque): Costos operativos que mantienen el proyecto en funcionamiento. Marketing, gestion comunitaria, compensacion de moderadores, costos de servidores, airdrops, sorteos y gastos de alianzas. La direccion de Tesoreria es un monedero multisig P2SH 2-de-3 que requiere dos de tres titulares de claves para autorizar cualquier gasto.
Dev / Fundadores (5% / 1,25 KRGN por bloque): Compensacion por construir Kerrigan desde cero y compromiso continuo con el mantenimiento y desarrollo del protocolo. Se libera directamente sin bloqueo.
Este presupuesto operativo del 20% es comparable al historico fondo de desarrollo del 20% de Zcash. La diferencia: el capital de crecimiento de Kerrigan (el otro 40%) esta en un deposito bloqueado por consenso al que el equipo no puede acceder sin aprobacion de la red. Solo el 20% es de libre disposicion.
V2 reestructura la recompensa de bloque en torno a la red de inferencia de IA. Los operadores de GPU obtienen ingresos de pago por inferencia ademas de su parte de recompensa de bloque, haciendo que el hardware de mineria de Kerrigan sea productivo entre bloques:
| Destinatario | Porcentaje V1 | Porcentaje V2 | Notas |
|---|---|---|---|
| Inferencia IA GPU | 0% | 40% | Ademas de las ganancias de pago por inferencia |
| Mineria | 20% | 20% | Sin cambios |
| Masternodes | 20% | 20% | Sin cambios |
| Tesoreria | 15% | 15% | Sin cambios |
| Dev / Fundadores | 5% | 5% | Sin cambios |
| Fondo de Crecimiento | 40% | 0% | Cumplio su proposito |
El fondo de crecimiento cae a cero una vez que el ecosistema esta establecido. El 40% que impulso los primeros listados en exchanges y alianzas se redirige a los participantes de inferencia IA GPU, convirtiendo a Kerrigan en una cadena de doble proposito: la mineria asegura la red mientras la computacion GPU sirve cargas de trabajo de IA. La asignacion del 40% para inferencia se suma a las tarifas directas de pago por inferencia, dando a los operadores de GPU dos fuentes de ingresos con el mismo hardware.
Kerrigan integra el protocolo Sapling de Zcash para transacciones protegidas de conocimiento cero. Los usuarios pueden mover fondos entre direcciones transparentes (que comienzan con 'K') y direcciones protegidas usando pruebas Groth16 zk-SNARK que no revelan nada sobre el remitente, receptor o monto.
Las transacciones protegidas usan nType = 10 (TRANSACTION_SAPLING). El payload adicional contiene:
El maximo es 500 descripciones de gasto y 500 descripciones de salida por transaccion. El constructor Sapling en Rust rellena los paquetes de salida a un minimo de 2 salidas (agregando salidas ficticias si es necesario) para prevenir el analisis del grafo de transacciones basado en el conteo de salidas.
El circuito Sapling se ejecuta sobre la curva eliptica Jubjub embebida dentro de BLS12-381. Las pruebas se generan y verifican a traves de un puente FFI en Rust usando los crates bellman, jubjub y group, compilados via CXX en el nodo C++.
Primitivas clave:
La frontera del arbol Merkle (los datos minimos necesarios para agregar nuevas hojas) se almacena por bloque en LevelDB. Los testigos del lado del monedero rastrean la ruta de autenticacion de cada nota para las pruebas de gasto.
Configuracion de confianza: Kerrigan reutiliza los parametros Sapling de Zcash (las claves de prueba y verificacion generadas por la ceremonia Powers of Tau de Zcash y el MPC de Sapling). Los circuitos son identicos a Zcash Sapling. No se requiere una nueva ceremonia de configuracion de confianza para las transacciones protegidas.
La firma de transacciones sigue un esquema sighash estilo ZIP 243. La preimagen del sighash incluye hashPrevouts, hashSequence y hashOutputs cubriendo tanto los componentes transparentes como los protegidos. Esto previene la maleabilidad de firmas y asegura que las porciones transparente y protegida de una transaccion esten vinculadas criptograficamente.
Las transacciones protegidas usan un modelo de tarifas basado en acciones:
Sapling se activa en el bloque 500 de mainnet, aproximadamente 16 horas despues del genesis. Nueve RPCs proporcionan funcionalidad completa del monedero:
| RPC | Funcion |
|---|---|
| z_getnewaddress | Generar una nueva direccion protegida |
| z_listaddresses | Listar todas las direcciones protegidas en el monedero |
| z_getbalance | Obtener el saldo protegido de una direccion |
| z_listunspent | Listar notas protegidas no gastadas |
| z_sendmany | Enviar a/desde direcciones protegidas (t-a-z, z-a-z, z-a-t) |
| z_exportkey | Exportar una clave de gasto protegida |
| z_importkey | Importar una clave de gasto protegida |
| z_exportviewingkey | Exportar una clave de visualizacion completa Sapling |
| z_importviewingkey | Importar una clave de visualizacion completa Sapling |
Kerrigan soporta dos niveles de masternodes heredados del framework de evolucion de Dash:
| Tipo | Colateral | Peso de Voto |
|---|---|---|
| Regular | 10.000 KRGN | 1x |
| Evo (HPMN) | 40.000 KRGN | 4x |
Los masternodes se registran en la cadena usando transacciones de registro determinista DIP3:
La lista determinista de masternodes se deriva completamente de las transacciones en cadena. Cada nodo calcula la misma lista a partir del mismo estado de la cadena, eliminando los desacuerdos de consenso que plagaban los sistemas de masternodes no deterministas.
Los Quorums de Masternodes de Larga Duracion (LLMQs) habilitan dos servicios clave:
InstantSend bloquea las entradas de transacciones en segundos, previniendo intentos de doble gasto. Un quorum de masternodes firma un mensaje de bloqueo, y cualquier transaccion conflictiva es rechazada por la red.
ChainLocks finaliza bloques haciendo que un quorum firme el primer bloque visto en cada altura. Una vez que la firma ChainLock se propaga, el bloque no puede ser reorganizado, incluso por un atacante del 51%.
Ambos servicios estan controlados por sporks y desactivados en el genesis. LLMQ requiere un numero minimo de masternodes registrados para formar quorums, por lo que estas funcionalidades se activan via spork una vez que el conjunto de masternodes alcanza la masa critica:
Los operadores de masternodes pueden enviar propuestas de presupuesto y votar sobre ellas. Las propuestas pasan si SI - NO >= max(10, conteo_ponderado_masternodes / 10). El sistema de gobernanza maneja propuestas comunitarias, iniciativas de marketing y financiamiento de infraestructura. Tambien controla la votacion de continuacion del fondo de crecimiento (Seccion 3.4): la asignacion del 40% del fondo de crecimiento debe ser renovada activamente por votacion de masternodes cada ciclo de superbloque (~23 dias) o se quema automaticamente.
En una colonia de abejas real, cada miembro lleva marcadores quimicos que lo identifican como parte de la colmena. Ninguna abeja individual produce el olor de la colonia. Este emerge del colectivo. El Hivemind Protocol funciona de la misma manera: los pools de mineria producen colectivamente una "feromona" criptografica que se teje en cada bloque. Como mezclar colores de pintura, entran azul, amarillo y rojo, y obtienes un tono especifico de marron. Puedes verificar que el marron es correcto. No puedes desmezclarlo para extraer los colores individuales. Pero si alguien intenta hacer ese marron sin el azul, es el tono incorrecto. Inmediatamente detectable.
HMP se situa sobre la prueba de trabajo. PoW determina quien mina un bloque. HMP determina si los mineros activos de la red avalan ese bloque. Un atacante que bifurca la cadena en secreto no puede traer la feromona de la colonia consigo, porque los mineros honestos nunca participaron en la bifurcacion. La cadena de ataque huele mal.
Un requisito critico de diseno: sin cambios en el software de mineria. HMP opera completamente dentro del daemon. El software de pool (s-nomp, Miningcore o cualquier stack compatible con Stratum) se comunica con el daemon a traves de los RPCs estandar getblocktemplate y submitblock. El daemon maneja internamente la gestion de identidad, la firma de sellos, el ensamblaje de sellos, la difusion de compromisos y la retransmision P2P. Las plantillas de bloque ya incluyen datos de sello HMP embebidos en la transaccion coinbase, el mismo patron usado por BIP34 (altura en coinbase), SegWit (raiz witness en coinbase) y mineria fusionada (AuxPoW en coinbase). Los mineros hashean la plantilla a ciegas. El protocolo Stratum no cambia.
Cada daemon genera un par de claves BLS persistente en la primera ejecucion (almacenado como hmp_identity.dat). Esta identidad se carga automaticamente al inicio. A medida que el daemon mina bloques y participa en el sellado, construye un registro de privilegio:
| Nivel | Requisitos | Capacidades |
|---|---|---|
| UNKNOWN | Sin historial, o en calentamiento de 10 bloques | No puede sellar |
| NEW | Calentamiento completado, participando | Puede sellar con peso estandar |
| ELDER | Resolvio 10+ bloques Y participacion en sellado dentro de ventana de 100 bloques | Peso completo, elegible para bonus cross-algo |
La ventana de privilegio es de 100 bloques. Un minero que deja de participar regresa a UNKNOWN despues de caer fuera de la ventana. El privilegio requiere trabajo real: no puedes convertirte en ELDER sin resolver bloques realmente, lo que convierte cualquier ataque Sybil en una costosa operacion de mineria honesta.
Antes de sellar, un daemon debe comprometer su clave publica BLS en la cadena. Piensa en esto como la lista de asistencia. Cada daemon que quiere participar difunde su clave publica. Estas claves llegan a la cadena de dos maneras: implicitamente (minando un bloque, que embebe la clave publica del minero en el campo minerIdentity del CCbTx v4) o explicitamente (hasta 16 compromisos adicionales de clave publica por bloque en el campo vCommitments del CCbTx v5).
Una clave comprometida debe madurar durante 10 bloques antes de que el firmante sea elegible. Esta es la penalidad de calentamiento. Si un servicio de cambio de rentabilidad como NiceHash cicla en rafagas mas cortas que el calentamiento (~20 minutos), esos mineros nunca contribuyen a la feromona. Minan, ganan recompensas, se van. Impacto cero en la identidad de la colonia.
Si una clave comprometida permanece lo suficiente para ganar privilegio, se convierte en una voz igual en la colonia. Cuando se va, una voz desaparece. El aroma de la colonia apenas cambia.
Cuando llega un nuevo bloque, el daemon automaticamente verifica la elegibilidad, calcula una prueba VRF, firma el hash del bloque con su clave BLS y difunde la participacion de sello a la red. Esto ocurre en ConnectBlock sin participacion del pool.
Cada participacion de sello contiene:
El firmante tenia conocimiento del estado publico de la cadena en una altura reciente, el compromiso fue generado despues de observar ese estado (previene la pre-computacion), y el material de clave es fresco para esta ronda (previene la repeticion).
La tasa de hash especifica del firmante, el momento exacto de sus observaciones y el material de clave privada usado en el compromiso. Nota que las participaciones de sello incluyen la clave publica del firmante (la identidad seudonima es visible para el seguimiento de privilegios), pero la prueba zk asegura que los detalles operativos y el material de clave permanezcan privados.
Un atacante minando una bifurcacion secreta no puede producir pruebas validas porque no estaba observando la cadena publica en los momentos requeridos. Las entradas de la prueba referencian entropia derivada del estado de la cadena publica que solo existe en la cadena honesta. Las pruebas estan vinculadas a hashes de bloques especificos, por lo que no pueden ser trasplantadas entre cadenas.
Las participaciones de sello se propagan via mensajes P2P SEALSHARE. Despues de una ventana de firma de 5 segundos, el daemon ensambla las participaciones recolectadas en un CAssembledSeal con una firma BLS agregada. El sello para el bloque N se embebe en el coinbase del bloque N+2, dando a la red tiempo para recolectar participaciones sin detener la produccion de bloques. La mineria nunca espera por firmas.
Configuracion para pruebas HMP: el circuito de compromiso MiMC usa Groth16 sobre BLS12-381. El circuito es intencionalmente pequeno (tiempo del probador <2s en hardware basico, tiempo del verificador <50ms, tamano de prueba <256 bytes). Las claves de prueba y verificacion se generan via una ceremonia de computacion multipartita. La suposicion de seguridad es estandar para Groth16: la configuracion es segura si al menos un participante de la ceremonia fue honesto y destruyo su residuo toxico. Las transcripciones de la ceremonia y los hashes de parametros se publican para verificacion.
HMP modifica la seleccion de cadena agregando un bonus de sello por bloque al PoW acumulativo estandar:
Para cada bloque, el multiplicador de sello se calcula como un valor en puntos basicos aplicado a block_pow_work:
El multiplicador de sello usa un sistema de niveles graduado. Solo las firmas de nivel ELDER cuyo algoId coincide con el algoritmo de mineria del bloque cuentan para la completitud del mismo algoritmo. Dentro de cada nivel, el multiplicador se interpola linealmente basado en la proporcion de Elders presentes respecto al total de Elders para el algoritmo. El bonus cross-algo agrega un valor fijo de +500 puntos basicos por dominio de algoritmo ELDER adicional (mas alla del propio bloque), con un tope de +1500 bps (los 4 algos representados). Un bloque completamente sellado con los 4 dominios de algoritmo alcanza 1,95x su trabajo PoW. Un bloque sin sello vale 1,0x. A lo largo de cientos de bloques, una cadena con feromonas consistentemente completas acumula significativamente mas peso que una cadena con feromonas debiles o ausentes, incluso si el PoW bruto es equivalente.
El acuerdo requerido de firmantes escala con el conteo de ELDERs por algoritmo:
| Elders (por algo) | Acuerdo Requerido | Justificacion |
|---|---|---|
| 6+ | 80% | Seguridad completa, absorbe fallos individuales |
| 4-5 | 75% | Fuerte, ligeramente mas tolerante |
| 3 | 66% (2 de 3) | Degradado pero funcional |
| 2 | 100% (ambos) | Maxima precaucion |
| 0-1 | N/A, modo PoW puro | Colonia aun no establecida |
Esto significa que la red comienza en modo PoW puro y transiciona hacia un consenso asegurado por HMP organicamente a medida que la colonia de mineria crece. La seguridad emerge de la participacion, no de un dia senalado.
No todos los firmantes registrados participan en cada sello. BLS-VRF (Funcion Aleatoria Verificable) controla que participaciones de firmantes se retransmiten a traves de la red P2P. El hash del bloque anterior alimenta el VRF. Cada daemon elegible ejecuta el VRF con su clave de largo plazo. La seleccion es determinista (todos los nodos pueden verificar quien era elegible) pero impredecible (depende de hashes de bloques que nadie puede predecir de antemano).
En V1, VRF es un filtro de la capa de retransmision, no una regla de consenso. Los nodos descartan participaciones de sello de firmantes que no pasan la elegibilidad VRF, reduciendo el ancho de banda de la red y dificultando que un atacante sature o inunde el pool de participaciones. La puntuacion de seleccion de cadena cuenta todas las firmas BLS validas en el sello ensamblado independientemente del estado VRF (ver Apendice A.4). Futuras actualizaciones del protocolo pueden promover la elegibilidad VRF a una verificacion de validez de sello a nivel de consenso.
Un pool tiene privilegio si resolvio un bloque en los ultimos 100 bloques, O si es uno de los ultimos 6 pools unicos en resolver un bloque en ese algoritmo, lo que sea que la retrospectiva alcance mas lejos. Esto significa que el conjunto privilegiado en cualquier algoritmo nunca puede reducirse por debajo de 6 (asumiendo que 6 pools distintos han minado alguna vez ese algoritmo).
Si un gran pool de cambio de rentabilidad mina 100 bloques KawPoW consecutivos, los otros 5 pools que mas recientemente resolvieron bloques KawPoW antes de esa racha aun se consideran privilegiados. Sus voces permanecen en la colonia. La retrospectiva extendida tiene un tope de 1.000 bloques (~33 horas). Mas alla de eso, la participacion es demasiado obsoleta para contar.
Kerrigan hereda el sistema ChainLock de Dash (finalizacion de bloques basada en LLMQ por masternodes), y se activara via spork una vez que se registren suficientes masternodes. Pero ChainLocks requiere un quorum de masternodes funcional, lo que toma tiempo para construir despues del genesis. HMP llena el vacio: proporciona resistencia a reorganizaciones desde el primer dia usando los mineros que ya estan en la red. A medida que el conjunto de masternodes crece, ChainLocks se superpone a HMP para finalidad adicional. Se complementan mutuamente.
Estas en un cine. Sales a mitad de pelicula a comprar palomitas. Al salir, notas a un tipo con camisa roja junto a la puerta, una pareja de ancianos en la tercera fila, un grupo de adolescentes cerca del frente. Compras tus palomitas, vuelves a entrar, e inmediatamente algo esta mal. La camisa roja desaparecio. La pareja de ancianos se movio. Los adolescentes desaparecieron. Ninguna de las caras es correcta. Estas en la sala equivocada. No necesitaste que nadie te lo dijera — simplemente notaste que la gente que esperabas no esta aqui.
Asi es como HMP detecta una cadena de ataque. La red sabe que mineros han estado apareciendo — resolviendo bloques, participando en sellos, ganando estatus ELDER. Cuando aparece una cadena competidora, el protocolo verifica si esas caras familiares estan presentes. Si los habituales faltan, la cadena huele mal. No se necesita comparacion entre cadenas. Simplemente entraste a la sala equivocada.
Ahora escalalo a cuatro salas. Kerrigan no opera una sola proyeccion — opera un multiplex de cuatro pantallas. X11, KawPoW, Equihash 200,9 y Equihash 192,7 cada uno tiene su propia sala con sus propios habituales. Un pool de X11 gana su reputacion en la sala X11. Un pool de KawPoW gana su reputacion en la sala KawPoW. Son comunidades completamente independientes con hardware completamente diferente.
Un bloque es mas fuerte cuando habituales de multiples salas lo avalan. Un bloque KawPoW respaldado solo por habituales de KawPoW obtiene un bonus parcial. Agrega firmas de habituales de X11, habituales de Equihash 200,9 y habituales de Equihash 192,7, y el bloque gana un bonus cross-algo (Seccion 6.6), hasta 1,95x su peso PoW bruto. Un atacante necesita llenar las cuatro salas con caras convincentes simultaneamente — cuatro multitudes independientes, cuatro ecosistemas de hardware independientes, cuatro historiales independientes de mineria honesta, todos falsificados a la vez.
Considera al atacante mas sofisticado posible: presupuesto ilimitado, experiencia tecnica, paciencia.
Las capas no son obstaculos independientes. Se refuerzan mutuamente. No puedes ganar privilegio sin minar honestamente, lo que fortalece la cadena que estas intentando atacar. No puedes producir feromona valida en una bifurcacion secreta porque los pools honestos nunca contribuyeron su pintura. El atacante no enfrenta siete problemas. Enfrenta un problema imposible visto desde siete angulos: puedes ser aislado y colaborativo al mismo tiempo?
HMP es un mecanismo de coordinacion, y los mecanismos de coordinacion pueden ser abusados. Un cartel de firmantes ELDER que controle suficiente privilegio para llenar expected_signers podria retener selectivamente sellos de bloques minados por pools objetivos. Los bloques del pool objetivo acumularian menos peso en la cadena (menor proporcion de completitud), haciendolos mas propensos a perder carreras de reorganizacion contra bloques sellados.
Varios factores limitan esta superficie de ataque:
La evaluacion honesta: HMP aumenta el costo de los ataques del 51% por un margen significativo, pero introduce una superficie de coordinacion que el PoW puro no tiene. Un cartel suficientemente grande de daemons modificados podria usar la retencion de sellos como una herramienta de censura suave. Las mitigaciones anteriores hacen esto costoso y detectable, pero no imposible. Este compromiso es intencional. La alternativa (PoW puro sin HMP) es estrictamente mas vulnerable al ataque mas simple y barato de alquiler de tasa de hash.
HMP se activa en etapas en mainnet:
| Etapa | Altura | Descripcion |
|---|---|---|
| Etapa 2 | Bloque 100 | Se abren los compromisos de clave publica |
| Etapa 3 | Bloque 300 | Comienza el sellado suave (solo pesos positivos) |
| Etapa 4 | Bloque 500 | HMP completo con pruebas negativas |
Pruebas positivas vs negativas: En la Etapa 3, los bloques sellados reciben peso adicional en la cadena (prueba positiva: "este bloque tiene soporte de la colonia"). En la Etapa 4, la ausencia de firmantes esperados tambien se convierte en senal (prueba negativa: "esta cadena carece de mineros que sabemos que deberian estar aqui").
Las pruebas negativas se calculan deterministamente solo a partir de la cadena candidata, sin comparacion entre cadenas. Cada cadena lleva su propio estado de privilegio: el conjunto de firmantes ELDER se deriva del historial de bloques de esa cadena (quien resolvio bloques, quien participo en sellos, dentro de la ventana de retrospectiva). Si el rastreador de privilegios de una cadena muestra 6 firmantes ELDER para KawPoW, pero los sellos en bloques recientes solo contienen 2 de ellos, la proporcion de completitud es baja y el bonus de sello es fraccional. No se necesita referencia a ninguna otra cadena. Los nodos evaluan cada cadena candidata independientemente usando el propio estado de esa cadena.
Esta es la prueba del cine de la Seccion 6.10: entraste a la sala equivocada y los habituales no estan en sus asientos. No se necesita comparacion — simplemente notas quien falta.
En V1, las pruebas negativas afectan solo la puntuacion de peso de la cadena. Son una heuristica de seleccion, no una regla de validez estricta. Una cadena con firmantes faltantes no es invalida; simplemente acumula menos peso que una cadena donde los firmantes esperados estan presentes. Este enfoque conservador evita penalizaciones falsas bajo particiones de red o problemas de conectividad transitorios. Futuras actualizaciones del protocolo pueden endurecer la aplicacion de pruebas negativas a medida que la red madure.
Un interruptor de desactivacion en tiempo de ejecucion (SPORK_25_HMP_ENABLED) permite la desactivacion de emergencia si surgen problemas despues del lanzamiento.
| Parametro | Valor |
|---|---|
| Prefijo de direccion pubkey | K (byte 45) |
| Prefijo de direccion script | 7 (byte 16) |
| HRP bech32m Sapling | ks |
| Tipo de moneda BIP44 | 99888 (no registrado; registro formal SLIP-0044 pendiente) |
| Magic de red | 0x4B 0x52 0x47 0x4E ("KRGN") |
| Red | Puerto P2P | Puerto RPC |
|---|---|---|
| Mainnet | 7120 | 7121 |
| Testnet | 17120 | 17121 |
| Devnet | 37120 | 19798 |
| Regtest | 27120 | 19898 |
Cuatro nodos semilla distribuidos geograficamente manejan el descubrimiento inicial de pares:
| Semilla | Region |
|---|---|
| seed1.kerrigan.network | Estados Unidos |
| seed2.kerrigan.network | India |
| seed3.kerrigan.network | Japon |
| seed4.kerrigan.network | Alemania |
Kerrigan define encabezados de bloque comprimidos basados en DIP25 con extensiones para campos multi-algoritmo. Los encabezados comprimidos estan actualmente deshabilitados pendiente la resolucion de casos limite de deserializacion multi-algoritmo; la descarga inicial de bloques usa encabezados completos. Un campo de bits de un byte controla que campos se incluyen:
Esto reduce significativamente el ancho de banda de encabezados durante la descarga inicial de bloques, donde solo una fraccion de los bloques necesita que se transmitan las soluciones completas de Equihash o los datos de KawPoW.
| Parametro | Valor |
|---|---|
| Marca de tiempo | 1.773.446.400 (11 Mar, 2026 12:00 UTC) |
| Nonce | 1.338.121 |
| Bits | 0x1e0ffff0 |
| Subsidio | 25 KRGN |
| Hash | 0x00000444f8dbee14c599ac723b35cc8021b12d48d092c7ac67d45f6d8a0b9c32 |
El beneficio de seguridad mas directo de cuatro algoritmos de mineria es la resistencia a ataques de vector unico. Un atacante que controla el 51% de la tasa de hash de X11 controla aproximadamente el 25% de la produccion total de bloques de la red. Para ejecutar un ataque sostenido del 51%, necesitaria dominar al menos dos algoritmos simultaneamente, o abrumar un algoritmo mientras supera a los mineros honestos en los demas. El Hivemind Protocol hace esto aun mas dificil: el poder de hash por si solo es insuficiente cuando la seleccion de cadena tambien pondera las atestaciones de sello de firmantes registrados y comprometidos.
El conjunto de anuladores de Sapling previene dobles gastos de notas protegidas. Cada nota tiene un anulador unico derivado de su posicion en el arbol Merkle y la clave de gasto. Una vez que un anulador aparece en la cadena, cualquier transaccion que intente gastar la misma nota es rechazada a nivel de consenso. Las pruebas Groth16 son computacionalmente solidas bajo la suposicion de logaritmo discreto sobre BLS12-381; falsificar una prueba sin conocer el testigo es inviable.
Todos los datos deserializados de la red P2P se verifican en limites antes de que impulsen la asignacion de memoria, la iteracion de bucles o la indexacion de arreglos. Las soluciones de Equihash estan limitadas a 1.400 bytes. Las listas de firmantes de sello estan limitadas a 200 entradas. Las pruebas ZK estan limitadas a 256 bytes. Las listas de compromisos de clave publica estan limitadas a 16 por bloque. Ningun campo de datos de red puede provocar una asignacion ilimitada.
El sistema de sporks permite al equipo de desarrollo deshabilitar funcionalidades en produccion sin un hard fork. Los sporks criticos incluyen:
Las claves de spork usan un umbral de 2-de-3, requiriendo dos de tres titulares de claves para autorizar cualquier cambio de spork.
V1 es un lanzamiento enfocado en la mineria con todos los sistemas centrales activos:
V2 extiende Kerrigan de una cadena de mineria pura a una red de computacion GPU para inferencia de IA. La estimacion de desarrollo central es de aproximadamente 12 semanas, con una linea de tiempo total de 48 semanas que incluye pruebas, auditoria y preparacion del ecosistema. La arquitectura es modular, por lo que V2 puede enviarse tan pronto como este lista; la estimacion de 12 meses es conservadora, no un compromiso.
Componentes de V2:
Registro de Proveedores de Inferencia: Los operadores de GPU se registran en la cadena con requisitos de staking, atestacion de hardware y endpoints de servicio. Las transacciones de registro siguen el mismo patron de lista determinista que los masternodes DIP3, asegurando que cada nodo calcule el mismo conjunto de proveedores.
Distribucion de Trabajos P2P: Las solicitudes de inferencia se distribuyen a los proveedores a traves de un protocolo gossip. Las asignaciones de trabajos usan seleccion basada en VRF ponderada por stake del proveedor e historial de rendimiento. Los resultados se comprometen en la cadena con pruebas de hash para la resolucion de disputas.
Computo Verificable: Los proveedores envian atestaciones de computo que pueden ser verificadas al azar por otros proveedores. Los resultados incorrectos activan el slashing del stake del proveedor. El esquema de verificacion equilibra el rendimiento (no todos los resultados se verifican) con la seguridad (el engano se detecta estadisticamente y se castiga).
Reestructuracion de Recompensa de Bloque: La division coinbase cambia para dirigir el 40% de las recompensas de bloque a los participantes de inferencia IA GPU, ademas de sus ganancias de pago por inferencia. La mineria se mantiene en 20%, masternodes en 20%, tesoreria en 15% y dev/fundadores en 5%. El fondo de crecimiento cae a cero, habiendo cumplido su proposito durante la fase de lanzamiento V1.
Con V1 y V2 completados, el enfoque cambia a la madurez del ecosistema:
Kerrigan resuelve el problema de la centralizacion de hardware haciendo que cuatro algoritmos de mineria compitan en paralelo, cada uno en su propia curva de dificultad. Las transacciones protegidas Sapling brindan a los usuarios privacidad real respaldada por pruebas de conocimiento cero Groth16. El Hivemind Protocol agrega una segunda dimension de consenso que hace que los ataques del 51% sean sustancialmente mas dificiles al requerir atestaciones de sello de mineros comprometidos y comprobados.
El fondo de crecimiento del 40% asegura que el proyecto tenga los recursos financieros para construir presencia en exchanges e infraestructura del ecosistema a cualquier precio del token. V1 se lanza como una cadena de bloques completa enfocada en la mineria. V2 extiende la misma infraestructura GPU hacia la inferencia de IA, convirtiendo el hardware de mineria en recursos de computacion de proposito general.
El codigo es de codigo abierto. Los parametros de la cadena estan fijados. La mineria comienza en el genesis.
| Componente | Archivos Fuente |
|---|---|
| PoW Multi-algoritmo | src/primitives/block.h, src/primitives/block.cpp, src/pow.cpp |
| Tokenomics | src/chainparams.cpp, src/masternode/payments.cpp |
| Sapling | src/sapling/, src/rust/src/bridge.rs, src/sapling/sapling_tx_payload.h |
| Masternodes | src/evo/dmn_types.h, src/evo/deterministicmns.h |
| HMP | src/hmp/, src/rust/src/hmp/ |
| Parametros de red | src/chainparams.cpp, src/chainparamsbase.cpp |
| Encabezados comprimidos | src/primitives/block.h (CompressibleBlockHeader) |
Hash de identidad: X11(arriba). Hash PoW: el mismo.
Hash de identidad: X11(primeros 80 bytes). Hash PoW: ProgPoW(sha256d(primeros 80 bytes), nHeight, nNonce64) verificado contra mix_hash. El hash semilla de ProgPoW es sha256d (no X11), coincidiendo con el estandar de Ravencoin que usan todos los mineros KawPoW. Orden de bytes: ethash usa big-endian (bytes[0] = MSB), Bitcoin usa little-endian (begin() = LSB). Los bytes se invierten en cada limite de conversion.
Hash de identidad: X11(version + prevHash + merkleRoot + hashReserved + time + bits + nNonce256, diseno de 140 bytes). Hash PoW: validar la solucion Equihash contra la misma entrada de 140 bytes. La solucion esta comprometida en la serializacion completa del bloque.
Entrada de hash de identidad de Equihash: Los bloques Equihash usan la entrada de 140 bytes (incluyendo hashReserved y nNonce256) para el hashing de identidad, no el encabezado estandar de 80 bytes. El campo nNonce de 4 bytes no se usa para bloques Equihash. Dado que el hash de identidad compromete directamente nNonce256, no hay maleabilidad entre el nonce de mineria y el ID del bloque.
El ID del bloque (referenciado por hashPrevBlock en el siguiente bloque) es el hash de identidad: X11 sobre el encabezado base del bloque (80 bytes para X11/KawPoW, 140 bytes para variantes de Equihash). X11 se usa para el hashing de identidad en todos los algoritmos.
Garantia de unicidad: El encabezado de 80 bytes incluye la raiz merkle, que compromete la transaccion coinbase completa. El coinbase contiene: la altura del bloque mandada por BIP34, la direccion de pago del minero, datos de identidad HMP (CCbTx v4+ incluye la clave publica BLS del minero), datos de sello embebidos y un extranonce especifico del pool. Dos bloques minados independientemente a la misma altura siempre produciran transacciones coinbase diferentes (diferentes mineros, diferentes extranonces, diferentes identidades HMP), y por lo tanto diferentes raices merkle, y por lo tanto diferentes hashes de identidad.
Para hacer esta garantia explicita a nivel de protocolo: Kerrigan requiere que la transaccion coinbase incluya la clave publica HMP del daemon de mineria en el campo minerIdentity del CCbTx (v4 HMP_SEAL y v5 HMP_COMMITMENT, despues de la activacion de HMP Etapa 3 en el bloque 300). Dado que cada daemon tiene un par de claves BLS unico, el coinbase esta garantizado como unico por daemon por altura. Pre-activacion (bloques 0-299), la unicidad depende del mecanismo estandar de altura BIP34 + extranonce, que es suficiente para la baja competencia de la cadena temprana. Durante la Etapa 2 (bloques 100-299), los mineros registran identidades via compromisos implicitos y explicitos pero la aplicacion se aplaza para dar tiempo al ecosistema para adoptarlo.
Aplicacion de consenso: Los nodos rechazan cualquier bloque en o por encima de la altura de activacion de HMP Etapa 3 cuyo CCbTx carezca de un campo minerIdentity valido. Esta es una regla de consenso, no una suposicion sobre el comportamiento del minero. Un bloque sin identidad de minero despues de la activacion de Etapa 3 es invalido, punto.
Compromiso de campos especificos del algoritmo: Las soluciones de Equihash, los mix hashes de KawPoW y los nonces extendidos estan comprometidos por la verificacion de validacion PoW, no por el ID del bloque. Alterar cualquier campo especifico del algoritmo invalida la prueba PoW. El encadenamiento de la cadena (prevHash) es uniforme e independiente del algoritmo.
Multiples testigos validos: En el evento astronomicamente improbable de que un solo minero encuentre dos soluciones PoW validas para el mismo encabezado de 80 bytes (mismo hash de identidad, diferente testigo especifico del algoritmo), el protocolo los trata como el mismo bloque. El primer testigo valido recibido es aceptado; los testigos subsiguientes para un hash de identidad ya conocido se ignoran. Esto es seguro porque el hash de identidad compromete la raiz merkle (y por lo tanto todas las transacciones), por lo que ambos testigos representan el mismo contenido de bloque con el mismo efecto economico.
Mitigacion de envenenamiento de bloques invalidos: Debido a que el hash de identidad no compromete los campos especificos del algoritmo, un retransmisor malicioso podria teoricamente mutar la solucion Equihash o el mix_hash de KawPoW de un bloque valido para producir un bloque invalido con el mismo hash de identidad. Si un nodo cachea "este hash es invalido" y luego recibe el bloque real, podria rechazarlo. Kerrigan mitiga esto validando la prueba PoW especifica del algoritmo antes de comprometer el encabezado del bloque al indice. Un bloque cuya verificacion PoW falla se descarta en la capa de red sin envenenar el indice de bloques. Este es el mismo enfoque usado por DigiByte y otras cadenas multi-algoritmo que separan el hashing de identidad de la validacion PoW.
elders_present, elder_count y block_pow_work se definen en la Seccion A.4. Al comparar dos cadenas competidoras a la misma altura, la cadena con mayor total_chain_weight gana.
| Elders (por algo) | Acuerdo Requerido | required_count (ejemplo) |
|---|---|---|
| 6 | 80% | ceil(0.80 * 6) = 5 |
| 5 | 75% | ceil(0.75 * 5) = 4 |
| 4 | 75% | ceil(0.75 * 4) = 3 |
| 3 | 66% | ceil(0.66 * 3) = 2 |
| 2 | 100% | ceil(1.00 * 2) = 2 |
| 0-1 | N/A | Modo PoW puro (seal_multiplier = 10000 para todos los bloques) |
La seleccion de comite VRF y las pruebas zk Groth16 se transportan en las participaciones de sello en la capa P2P y sirven como protecciones anti-DoS y anti-grinding. En V1, no son criticas para el consenso: la validez de un sello depende unicamente de las firmas BLS, la madurez de los compromisos y las verificaciones de privilegio listadas arriba. Los nodos validan VRF y pruebas zk antes de retransmitir participaciones de sello (las pruebas invalidas se descartan en la capa de red), pero los sellos ensamblados en el coinbase se puntuan puramente por sus firmas BLS. Este enfoque conservador mantiene las reglas de consenso minimas en el lanzamiento. Futuras actualizaciones del protocolo pueden promover la elegibilidad VRF y la verificacion de pruebas zk a reglas de consenso una vez que el sistema de pruebas haya sido probado en batalla en mainnet.
El sello para el bloque N se embebe en el coinbase del bloque N+2 (nHMPSealTrailingDepth = 2). Esto significa:
Los nodos siguen estas reglas al procesar bloques con campos PoW especificos del algoritmo:
| Componente | Parametros | Fuente |
|---|---|---|
| Sapling (tx protegidas) | Claves de prueba/verificacion Groth16 sobre BLS12-381 | Powers of Tau de Zcash + MPC de Sapling (reutilizados, circuitos identicos) |
| Circuito MiMC de HMP | Claves de prueba/verificacion Groth16 sobre BLS12-381 | Ceremonia multipartita; seguro si al menos un participante fue honesto; transcripciones publicadas |