Governança em Gonka: como uma rede descentralizada é gerenciada

A governança em Gonka opera em dois níveis, cada um com sua própria velocidade e escala de decisões.

Votação Operacional (minutos) — decisões operacionais dentro da rede. Quando surge uma disputa sobre a validade de uma solicitação de inferência ou um resultado de PoC, os hosts votam através do módulo x/group do Cosmos SDK. O peso do voto é determinado pelo peso do PoC — quanto mais computação um nó realiza, maior sua influência. Essas votações duram minutos e resolvem conflitos específicos: se a inferência foi correta, se o nó fez seu trabalho.

Votação de Governança (dias) — decisões estratégicas sobre o desenvolvimento do protocolo. Atualizações de software, alteração de parâmetros da rede, ativação de novos modelos, alocação de fundos do Community Pool — tudo isso é submetido à votação de todos os hosts. O período de votação é de alguns dias a uma semana, para que todos os participantes tenham tempo de se familiarizarem com a proposta.

A principal diferença da maioria dos projetos de cripto: o peso do voto é determinado por Proof of Compute, não por staking. Em Gonka, não se pode “comprar um voto” simplesmente acumulando tokens numa carteira. A influência é proporcional à contribuição computacional real — GPUs que processam solicitações de IA e geram provas de trabalho. Isso vincula a governança àqueles que realmente suportam a arquitetura da rede, e não ao capital especulativo.

Na prática, isso significa: um operador de fazenda de 10 H100 tem 10 vezes mais votos do que um operador com uma única placa — porque ele processa 10 vezes mais solicitações de inferência. O sistema se autoequilibra: aqueles que mais contribuem para o trabalho da rede, mais influenciam seu desenvolvimento.

A atualização do protocolo Gonka é um processo formalizado do código à ativação na rede. Cada etapa é transparente e verificável.

Processo de atualização:

1. Pull Request no GitHub — desenvolvedores (equipe Gonka ou contribuidores) criam um PR no repositório gonka-ai/gonka.
2. Revisão da comunidade — o código é revisado, discutido, testado. Auditoria CertiK para mudanças críticas.
3. Release — uma nova versão do binário gonkad é compilada.
4. Proposta on-chain — uma proposta de atualização na rede é criada com uma descrição das mudanças.
5. Depósito + Voto — os hosts depositam (limiar de ativação) e votam durante o período de votação.
6. Cosmovisor — se aprovado, o Cosmovisor atualiza automaticamente os nós na altura de bloco especificada.

De janeiro a março de 2026, a rede passou por mais de 11 votações bem-sucedidas — da versão v0.2.2 à v0.2.11. Todas as propostas foram aprovadas. A última votação importante — proposta #31 (v0.2.11) — obteve 673.699 votos “a favor” com 0 votos “contra”. Essa atualização introduziu a inferência de sub-rede — um mecanismo de computação off-chain através de sub-redes, prometendo um crescimento de 100 vezes na capacidade de processamento.

Opções de voto:

• Sim — apoio a atualização.
• Não — sou contra a atualização.
• Não com Veto — categoricamente contra; se mais de 33% dos votos — a proposta é rejeitada e o depósito é queimado.
• Abster-se — abstenho-me, mas participo do quórum.

Todo o histórico de votações está disponível em gonka.gg/network/proposals — é possível ver cada proposta, os resultados e a lista de votantes.

GiP é um sistema para formalizar ideias para o desenvolvimento do protocolo Gonka, lançado em 24 de fevereiro de 2026 através do GitHub Discussions (issue #795).

Formato de cada GiP:

• Motivação — qual problema a proposta resolve.
• Solução — descrição técnica da solução.
• Roteiro — plano de implementação por etapas.
• Perguntas Abertas — questões não resolvidas para discussão da comunidade.

Os GiPs não são vinculativos — eles não obrigam a equipe à implementação. Mas eles formam um consenso da comunidade e definem a direção para futuras propostas on-chain. Na verdade, os GiPs são “pré-governança”: discussão antes da votação.

GiPs chave:

• #800 Multi-Model PoC — suporte para múltiplos modelos de IA simultaneamente. Atualmente, a rede trabalha com Qwen3-235B; este GiP descreve a arquitetura para o trabalho paralelo de diferentes modelos com Proof of Useful Work separado.
• #801 Inference Scaling — arquitetura de sub-rede para escalabilidade. Parte deste GiP já foi implementada na v0.2.11 (inferência de sub-rede).
• #860 Quality Protocol — roteamento de requisições levando em conta a qualidade das respostas. Nós que dão melhores resultados recebem mais tráfego e recompensas.

Qualquer participante pode criar um GiP através do GitHub Discussions. O limiar de entrada é mínimo — você só precisa de uma conta GitHub e compreensão do problema. As discussões ativas com a participação da equipe Gonka e dos hosts mostram que o sistema funciona: as propostas recebem feedback, são aprimoradas e caminham para a implementação.

Community Pool é o fundo para o desenvolvimento do ecossistema Gonka. Cerca de 20% da emissão gênese (~200 milhões de GNK) foram alocados para subsídios, recompensas e financiamento de iniciativas da comunidade.

Recompensas por contribuições de código — o principal mecanismo para distribuir fundos do Community Pool. Os desenvolvedores recebem uma recompensa por PR no repositório gonka-ai/gonka: desde a correção de bugs até a implementação de novos recursos. O tamanho da recompensa depende da complexidade e importância da contribuição:

Mecanismo de aprovação: as recompensas são incluídas no README das propostas de atualização. Quando os hosts votam na atualização do protocolo, eles aprovam simultaneamente a lista de pagamentos pelos PRs que fazem parte dessa versão. A transparência é total — qualquer um pode verificar o que foi pago e quanto.

Além das recompensas, o Community Pool pode financiar: o desenvolvimento de ferramentas do ecossistema, marketing, iniciativas educacionais e subsídios para pesquisa. Mais detalhes sobre como ganhar através do GitHub — em um artigo separado.

Uma rede jovem é vulnerável: poucos nós, pouco staking, um ataque de 51% é teoricamente possível. Gonka resolve isso com vários mecanismos.

Sistema de Guardiões — três nós confiáveis, controlados pela equipe Gonka, com um total de 34% do poder de consenso. Os Guardiões não podem impor decisões (34% < 67% para aprovação), mas podem bloquear uma proposta maliciosa (34% > 33% limiar de veto). Fundamental: Os Guardiões são desativados automaticamente quando o poder total da rede (total_network_power) atinge 10 milhões de unidades. Isso não é um interruptor manual — a desativação é programada no protocolo.

Sistema Colateral — os hosts devem depositar uma garantia em GNK para obter o peso total:

• Peso Base (20%) — peso incondicional, atribuído pelo simples fato de o nó estar funcionando.
• Elegível para Colateral (80%) — peso adicional, disponível apenas com garantia em GNK. O tamanho da garantia é proporcional ao poder computacional.

Slashing — punição por violações:

• 20% da garantia — por inferência INVÁLIDA (o nó forneceu um resultado incorreto).
• 10% da garantia — por tempo de inatividade (o nó está indisponível além do limite permitido).

Período de Carência — 180 épocas (~6 meses), durante as quais novos hosts podem operar sem garantia. Isso reduz a barreira de entrada: é possível começar a minerar, ganhar GNK através de recompensas e só então depositar o colateral. Após o término do Período de Carência, um nó sem garantia recebe apenas 20% do peso potencial.

Todos esses mecanismos são descritos na tokenomics GNK e visam um único objetivo: proteger a rede na fase inicial, sem sacrificar a descentralização a longo prazo.

A governança em Gonka não é um sistema estático, mas um processo em evolução. Estas são as direções chave de desenvolvimento para 2026-2027.

PoC Multi-Modelo (GiP #800) — suporte para múltiplos modelos simultaneamente. O primeiro candidato são os modelos de incorporação para RAG. Isso abrirá Gonka para uma classe completamente nova de aplicações: motores de busca, bases de conhecimento corporativas, chatbots com memória.

Protocolo de Qualidade de Inferência (GiP #860) — roteamento por qualidade. Atualmente, as solicitações são distribuídas pela disponibilidade dos nós; no futuro, pela qualidade das respostas. Os nós com melhor hardware e operação mais estável receberão prioridade.

Migração de governança on-chain (2026–2027) — transição para um módulo x/gov completo do Cosmos SDK. Isso fornecerá: tipos de propostas formalizados, execução automática de mudanças aprovadas, integração com IBC (Inter-Blockchain Communication) e a capacidade de criar propostas de governança através de qualquer carteira compatível com Cosmos.

As votações podem ser acompanhadas e participadas em gonka.gg/network/proposals.