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 de Gonka o colaboradores) crean un PR en el repositorio gonka-ai/gonka.
2. Revisión por la comunidad: el código se revisa, discute y prueba. Auditoría de CertiK para cambios críticos.
3. Lanzamiento: se construye una nueva versión del binario gonkad.
4. Propuesta en cadena: se crea una propuesta de actualización en la red con una descripción de los cambios.
5. Depósito + Voto: los anfitriones 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 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 principales actualizaciones:

• v0.2.11 (marzo de 2026, propuesta #31): 673,699 votos «a favor» frente a 0 «en contra». Se introdujo la inferencia de subredes, un mecanismo de cómputo fuera de cadena a través de subredes que promete un aumento de 100 veces en el rendimiento.
• v0.2.13 (mayo de 2026, propuesta #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. Se añadió MiniMax-M2.7 como tercer modelo en la red, se activó el cableado del puente de Ethereum y se redujo el quórum al 0,25.

Opciones de voto:

• Sí: apoyo la actualización.
• No: estoy en contra de la actualización.
• No con veto: me opongo categóricamente; si supera el 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; puedes 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:

• 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 sin resolver para la discusión de la comunidad.

Los GiP no son vinculantes — no obligan al equipo a implementarlos. Pero forman el consenso de la comunidad y marcan la dirección para futuras propuestas on-chain. De hecho, GiP es una «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 funciona con Qwen3-235B y Kimi K2.6 (a través de DevShards desde mayo de 2026). MiniMax-M2.7 se está agregando en v0.2.13. GiP describe la arquitectura para la operación paralela 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 (inferenced de subred).
• #860 Quality Protocol — enrutamiento de solicitudes basado en la calidad de las respuestas. Los nodos que proporcionan mejores resultados reciben más tráfico y recompensas.

Cualquier participante puede crear un GiP a través de GitHub Discussions. La barrera de entrada es mínima — solo se necesita una cuenta de GitHub y comprensión del problema. Las discusiones activas con la participación del equipo de Gonka y los hosts demuestran que el sistema funciona: las propuestas reciben comentarios, se refinan 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. Aquí están las direcciones clave de desarrollo para 2026–2027.

Multi-Model PoC (GiP #800) — implementado: Kimi K2.6 ya está funcionando en DevShards desde mayo de 2026, MiniMax-M2.7 se está agregando en v0.2.13 (propuesta #54). Los próximos 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 en función de la disponibilidad de los nodos; en el futuro, en función de la calidad de las respuestas. Los nodos con mejor hardware y un funcionamiento más estable recibirán prioridad.

On-chain governance migration (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.

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