Gobernanza en Gonka: cómo se gestiona una red descentralizada

La gobernanza en Gonka funciona en dos niveles, cada uno con su propia velocidad y alcance de decisiones.

Operational Voting (minutos) — decisiones operativas dentro de la red. Cuando surge una disputa sobre la validez de una solicitud de inference o de un resultado PoC, los hosts votan a través del módulo x/group del Cosmos SDK. El peso del voto lo determina el PoC weight: cuanto más cómputo realiza un nodo, mayor es su influencia. Estas votaciones duran minutos y resuelven conflictos concretos: si el inference fue correcto, si el nodo hizo su trabajo.

Governance Voting (días) — decisiones estratégicas sobre el desarrollo del protocolo. Actualizaciones de software, cambios en los parámetros de la red, activación de nuevos modelos, distribución de fondos del Community Pool — todo esto se somete a votación de todos los hosts. El periodo de votación va de varios días a una semana, para que todos los participantes tengan tiempo de revisar la propuesta.

La diferencia clave respecto a la mayoría de los proyectos cripto: el peso del voto lo determina el Proof of Compute, no el staking. En Gonka no se puede «comprar un voto» simplemente acumulando tokens en la cartera. La influencia es proporcional a la contribución de cómputo real — las GPU que procesan solicitudes de IA y generan pruebas de trabajo. Desde la actualización v0.2.16 cuenta la potencia confirmada en la época anterior: un host nuevo vota con peso cero durante su primera época, y el aumento de potencia añade votos a partir de la época siguiente. Esto vincula la gobernanza a quienes realmente sostienen la arquitectura de la red, y no al capital especulativo.

En la práctica, esto significa que un operador con dos servidores de 8× H100 tiene aproximadamente el doble de votos que un operador con un solo servidor así — porque procesa aproximadamente el doble de solicitudes de inference. El sistema se autoequilibra: quienes más invierten en el funcionamiento de la red, más influyen en su desarrollo.

Actualizar el protocolo Gonka es un proceso formalizado, desde el código hasta la activación en la red. Cada paso es transparente y verificable.

Proceso de actualización:

1. Pull Request en GitHub — los desarrolladores (equipo de Gonka o contribuidores) crean un PR en el repositorio gonka-ai/gonka.
2. Review de la comunidad — el código se revisa, se debate, se prueba. Auditoría CertiK para cambios críticos.
3. Release — se compila una nueva versión del binario inferenced.
4. On-chain proposal — se crea una propuesta de actualización en la red con la descripción de los cambios.
5. Deposit + Vote — los hosts depositan (umbral de activación) y votan durante el voting period.
6. Cosmovisor — tras la aprobación, Cosmovisor actualiza automáticamente los nodos en la altura de bloque indicada.

De enero a mayo de 2026, la red pasó por más de 13 votaciones exitosas, desde la versión v0.2.2 hasta la v0.2.13. Todas las propuestas fueron aprobadas. Cronología de las actualizaciones clave:

• v0.2.11 (marzo de 2026, proposal #31) — 673.699 votos «a favor» con 0 «en contra». Se introdujo subnet inference, un mecanismo de cómputo off-chain a través de subredes que promete un aumento del rendimiento de 100 veces.
• v0.2.13 (mayo de 2026, proposal #54) — aprobada el 21 de mayo de 2026 (62,8% «a favor», participación del 39,9% con un quórum del 33,4%), activada en el bloque 4267300. Añadió MiniMax-M2.7 como tercera modelo de la red, activó el Ethereum bridge wiring y redujo el quórum a 0.25.

Opciones de voto:

• Yes — apoyo la actualización.
• No — en contra de la actualización.
• No with Veto — totalmente en contra; si supera el 33% de los votos, la propuesta se rechaza y el depósito se quema.
• Abstain — me abstengo, pero cuento para el quórum.

Todo el historial de votaciones está disponible en gonka.gg/network/proposals — puedes consultar cada propuesta, los resultados y la lista de votantes.

GiP es un sistema de formalización de ideas para el desarrollo del protocolo Gonka, lanzado el 24 de febrero de 2026 a través de GitHub Discussions (issue #795).

Formato de cada GiP:

• Motivation — qué problema resuelve la propuesta.
• Solution — descripción técnica de la solución.
• Roadmap — plan de implementación por etapas.
• Open Questions — preguntas pendientes para discusión con la comunidad.

Los GiP no son binding — no obligan al equipo a su implementación. Sin embargo, forman el consenso de la comunidad y establecen la dirección para futuras on-chain proposals. De hecho, los GiP son «pre-governance»: discusión antes de la votación.

GiP clave:

• #800 Multi-Model PoC — soporte para múltiples modelos de IA simultáneamente. Actualmente, la red opera con MiniMax M2.7 (añadido en v0.2.13), DeepSeek V4 Flash (proposal #94) y GLM-5.3 Flash (proposal #101). El GiP describe la arquitectura para la operación paralela de diferentes modelos con Proof of Useful Work separado.
• #801 Inference Scaling — subnet architecture para escalabilidad. Parte de este GiP ya está implementado en v0.2.11 (subnet inference).
• #860 Quality Protocol — enrutamiento de solicitudes considerando la calidad de las respuestas. Los nodos que ofrecen mejores resultados reciben más tráfico y recompensas.

Cualquier participante puede crear un GiP a través de GitHub Discussions. El umbral de entrada es mínimo: solo se necesita una cuenta de GitHub y comprensión del problema. Las discusiones activas con la participación del equipo Gonka y los hosts demuestran que el sistema funciona: las propuestas reciben retroalimentación, se perfeccionan y avanzan hacia su implementación.

Community Pool es el fondo para el desarrollo del ecosistema Gonka. Alrededor del 20% de la emisión génesis (~200 millones de GNK) se ha asignado a subvenciones, recompensas y financiación de iniciativas comunitarias.

Recompensas por contribuciones de código — el mecanismo principal para distribuir fondos del Community Pool. Los desarrolladores reciben una recompensa por PR en el repositorio gonka-ai/gonka: desde la corrección de errores hasta la implementación de nuevas características. El tamaño de la recompensa depende de la complejidad y la importancia de la contribución:

Mecanismo de aprobación: las recompensas se incluyen en el README de las propuestas de actualización. Cuando los hosts votan por la actualización del protocolo, simultáneamente aprueban la lista de pagos por los PR incluidos en esa versión. La transparencia es total: cualquiera puede verificar por qué y cuánto se pagó.

Además de las recompensas, el Community Pool puede financiar: el desarrollo de herramientas del ecosistema, marketing, iniciativas educativas y subvenciones para investigación. Más información sobre cómo ganar a través de GitHub, en un artículo aparte.

Una red joven es vulnerable: pocos nodos, poco staking, un ataque del 51% es teóricamente posible. Gonka lo resuelve con varios mecanismos.

Sistema de Guardianes — tres nodos de confianza, controlados por el equipo de Gonka, con un total del 34% del poder de consenso. Los Guardianes no pueden imponer decisiones (34% < 67% para la aprobación), pero pueden bloquear una propuesta maliciosa (34% > 33% umbral de veto). Clave: Los Guardianes se desactivan automáticamente cuando el poder total de la red (total_network_power) alcanza los 10 millones de unidades. Esto no es un interruptor manual: la desactivación está programada en el protocolo.

Sistema Colateral — los hosts deben depositar una garantía en GNK para obtener el peso total:

• Peso Base (20%) — peso incondicional, se asigna por el mero hecho de que el nodo funcione.
• Eligible para Colateral (80%) — peso adicional, disponible solo si hay una garantía en GNK. El tamaño de la garantía es proporcional a la potencia computacional.

Reducción — penalización por infracciones:

• 20% de la garantía — por inferencia INVÁLIDA (el nodo arrojó un resultado incorrecto).
• 10% de la garantía — por tiempo de inactividad (el nodo no está disponible más allá del umbral permitido).

Período de Gracia — 180 épocas (~6 meses), durante las cuales los nuevos hosts pueden operar sin garantía. Esto reduce la barrera de entrada: se puede comenzar a minar, ganar GNK a través de recompensas y solo entonces depositar el colateral. Una vez finalizado el Período de Gracia, un nodo sin garantía recibe solo el 20% del peso potencial.

Todos estos mecanismos se describen en la tokenómica de GNK y tienen un objetivo: proteger la red en las primeras etapas, sin sacrificar la descentralización a largo plazo.

La gobernanza en Gonka no es un sistema estático, sino un proceso en evolución. Estas son las áreas clave de desarrollo para 2026–2027.

Multi-Model PoC (GiP #800) — implementado: el primero en mayo de 2026 a través de DevShards fue Kimi K2.6 (posteriormente retirado de la red), MiniMax-M2.7 se añadió en v0.2.13 (proposal #54), DeepSeek V4 Flash se conectó en agosto de 2026 (proposal #94), GLM-5.3 Flash — en septiembre de 2026 (proposal #101). Los siguientes candidatos son modelos de embedding para RAG: esto abrirá Gonka a una nueva clase de aplicaciones (motores de búsqueda, bases de conocimiento corporativas, chatbots con memoria).

Inference Quality Protocol (GiP #860) — enrutamiento por calidad. Actualmente, las solicitudes se distribuyen según la disponibilidad de los nodos; en el futuro, se basará en la calidad de las respuestas. Los nodos con mejor hardware y mayor estabilidad recibirán prioridad.

On-chain governance migration (2026–2027) — transición al módulo completo x/gov de Cosmos SDK. Esto brindará: tipos de proposal formalizados, ejecución automática de cambios aprobados, integración con IBC (Inter-Blockchain Communication) y la posibilidad de crear governance proposals a través de cualquier billetera compatible con Cosmos.

Puedes seguir las votaciones y participar en gonka.gg/network/proposals.