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

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

Votación Operacional (minutos) — decisiones operativas dentro de la red. Cuando surge una disputa sobre la validez de una solicitud de inferencia o un resultado de PoC, los hosts votan a través del módulo x/group del Cosmos SDK. El peso del voto se determina por el peso de PoC: cuanta más computación realiza un nodo, mayor es su influencia. Estas votaciones duran minutos y resuelven conflictos específicos: si la inferencia fue correcta, si el nodo hizo su trabajo.

Votación de Gobernanza (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, asignación de fondos del Community Pool, todo esto se somete a votación de todos los hosts. El período de votación es de varios días a una semana, para que todos los participantes tengan tiempo de familiarizarse con la propuesta.

La diferencia clave con la mayoría de los proyectos cripto: el peso del voto se determina por Proof of Compute, no por el staking. En Gonka, no se puede “comprar un voto” simplemente acumulando tokens en una billetera. La influencia es proporcional a la contribución computacional real: las GPU que procesan solicitudes de IA y generan pruebas de trabajo. Esto vincula la gobernanza con quienes realmente apoyan la arquitectura de la red, y no con el capital especulativo.

En la práctica, esto significa: un operador de granja de 10 H100 tiene 10 veces más votos que un operador con una sola tarjeta, porque procesa 10 veces más solicitudes de inferencia. El sistema se autoequilibra: quienes más invierten en el trabajo de la red, más influyen en su desarrollo.

La actualización del 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 Gonka o colaboradores) crean un PR en el repositorio gonka-ai/gonka.
2. Revisión de la comunidad — el código es revisado, discutido, probado. Auditoría CertiK para cambios críticos.
3. Release — se construye una nueva versión del binario gonkad.
4. Propuesta on-chain — se crea una propuesta de actualización en la red con una descripción de los cambios.
5. Depósito + Voto — los hosts depositan (umbral de activación) y votan durante el período de votación.
6. Cosmovisor — si se aprueba, Cosmovisor actualiza automáticamente los nodos a la altura de bloque especificada.

De enero a marzo de 2026, la red pasó por más de 11 votaciones exitosas, desde la versión v0.2.2 hasta la v0.2.11. Todas las propuestas fueron aprobadas. La última votación importante — propuesta #31 (v0.2.11) — obtuvo 673,699 votos “a favor” con 0 votos “en contra”. Esta actualización introdujo la inferencia de subredes, un mecanismo de cómputo off-chain a través de subredes, que promete un crecimiento de 100 veces en el rendimiento.

Opciones de voto:

• Sí — apoyo la actualización.
• No — estoy en contra de la actualización.
• No con Veto — categóricamente en contra; si más del 33% de los votos, la propuesta se rechaza y el depósito se quema.
• Abstenerse — me abstengo, pero participo en el quórum.

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

GiP es un sistema para formalizar 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:

• Motivación — qué problema resuelve la propuesta.
• Solución — descripción técnica de la solución.
• Hoja de ruta — plan de implementación por etapas.
• Preguntas abiertas — preguntas no resueltas para discusión de la comunidad.

Los GiP no son vinculantes, no obligan al equipo a implementarlos. Pero forman un consenso comunitario y establecen la dirección para futuras propuestas on-chain. De hecho, los GiP son “pre-gobernanza”: 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 trabaja con Qwen3-235B; este GiP describe la arquitectura para el trabajo paralelo de diferentes modelos con Proof of Useful Work separada.
• #801 Inference Scaling — arquitectura de subred para escalado. Parte de este GiP ya se ha implementado en v0.2.11 (inferencia de subred).
• #860 Quality Protocol — enrutamiento de solicitudes teniendo en cuenta la calidad de las respuestas. Los nodos que dan 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 muestran que el sistema funciona: las propuestas reciben retroalimentación, se mejoran y avanzan hacia la 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 direcciones clave de desarrollo para 2026-2027.

PoC Multi-Modelo (GiP #800) — soporte para múltiples modelos simultáneamente. El primer candidato son los modelos de incrustación para RAG. Esto abrirá Gonka a una clase completamente nueva de aplicaciones: motores de búsqueda, bases de conocimiento corporativas, chatbots con memoria.

Protocolo de Calidad de Inferencia (GiP #860) — enrutamiento por calidad. Actualmente, las solicitudes se distribuyen por la disponibilidad de los nodos; en el futuro, por la calidad de las respuestas. Los nodos con mejor hardware y un funcionamiento más estable recibirán prioridad.

Migración de gobernanza on-chain (2026–2027) — transición a un módulo x/gov completo del Cosmos SDK. Esto proporcionará: tipos de propuestas formalizados, ejecución automática de cambios aprobados, integración con IBC (Inter-Blockchain Communication) y la capacidad de crear propuestas de gobernanza a través de cualquier billetera compatible con Cosmos.

Las votaciones se pueden seguir y participar en gonka.gg/network/proposals.