Governance in Gonka: come viene gestita una rete decentralizzata

La governance in Gonka opera su due livelli, ciascuno con la propria velocità e portata decisionale.

Operational Voting (minuti) — decisioni operative all'interno della rete. Quando sorge una controversia sulla validità di una richiesta di inferenza o del risultato di PoC, i host votano tramite il modulo x/group di Cosmos SDK. Il peso del voto è determinato dal peso PoC: più calcoli esegue un nodo, maggiore è la sua influenza. Tali votazioni durano minuti e risolvono conflitti specifici: l'inferenza era corretta, il nodo ha svolto il suo lavoro?

Governance Voting (giorni) — decisioni strategiche sullo sviluppo del protocollo. Aggiornamenti software, modifica dei parametri di rete, attivazione di nuovi modelli, allocazione di fondi dal Community Pool: tutto ciò viene sottoposto al voto di tutti i host. Il periodo di votazione va da pochi giorni a una settimana, in modo che tutti i partecipanti abbiano il tempo di familiarizzare con la proposta.

La differenza chiave rispetto alla maggior parte dei progetti crypto: il peso del voto è determinato da Proof of Compute, non dallo staking. In Gonka non si può "comprare un voto" semplicemente accumulando token in un portafoglio. L'influenza è proporzionale al contributo computazionale reale: le GPU che elaborano richieste AI e generano prove di lavoro. Ciò lega la governance a coloro che supportano veramente l'architettura di rete, e non al capitale speculativo.

In pratica, ciò significa: un operatore di una farm di 10 H100 ha 10 volte più voti di un operatore con una singola scheda, perché elabora 10 volte più richieste di inferenza. Il sistema è autobilanciante: chi investe di più nel funzionamento della rete, influenza di più il suo sviluppo.

L'aggiornamento del protocollo Gonka è un processo formalizzato dal codice all'attivazione in rete. Ogni passaggio è trasparente e verificabile.

Processo di aggiornamento:

1. Pull Request su GitHub — gli sviluppatori (il team Gonka o i contributori) creano una PR nel repository gonka-ai/gonka.
2. Revisione della comunità — il codice viene esaminato, discusso, testato. Audit CertiK per modifiche critiche.
3. Release — viene creata una nuova versione binaria di gonkad.
4. On-chain proposal — viene creata una proposta di aggiornamento nella rete con una descrizione delle modifiche.
5. Deposito + Voto — gli host depositano (soglia di attivazione) e votano durante il periodo di votazione.
6. Cosmovisor — se approvato, Cosmovisor aggiorna automaticamente i nodi all'altezza del blocco specificata.

Da gennaio a maggio 2026 la rete ha superato 13+ votazioni riuscite — dalla versione v0.2.2 alla v0.2.13. Tutte le proposte sono state approvate. Cronologia degli upgrade chiave:

• v0.2.11 (marzo 2026, proposal #31) — 673.699 voti “a favore” contro 0 “contrari”. Introdotta l'inferenza di sottorete — un meccanismo di calcolo off-chain tramite sottoreti, che promette una crescita di 100 volte della capacità.
• v0.2.13 (maggio 2026, proposal #54) — accettata il 21 maggio 2026 (62,8% “a favore”, affluenza 39,9% con quorum 33,4%), attivata al blocco 4267300. Ha aggiunto MiniMax-M2.7 come terzo modello nella rete, attivato il cablaggio del bridge Ethereum e ridotto il quorum a 0.25.

Opzioni di voto:

• Sì — supporta l'aggiornamento.
• No — contro l'aggiornamento.
• No con veto — categoricamente contro; se più del 33% dei voti — la proposta viene respinta e il deposito brucia.
• Astensione — mi astengo, ma partecipo al quorum.

Tutta la cronologia delle votazioni è disponibile su gonka.gg/network/proposals — è possibile visualizzare ogni proposta, i risultati e l'elenco dei votanti.

GiP è un sistema per formalizzare le idee per lo sviluppo del protocollo Gonka, lanciato il 24 febbraio 2026 tramite GitHub Discussions (issue #795).

Formato di ciascun GiP:

• Motivation — quale problema risolve la proposta.
• Solution — descrizione tecnica della soluzione.
• Roadmap — piano di implementazione per fasi.
• Open Questions — quesiti irrisolti per la discussione della comunità.

I GiP non sono vincolanti – non obbligano il team all'implementazione. Ma formano il consenso della comunità e definiscono la direzione per future proposte on-chain. Di fatto, GiP è una «pre-governance»: una discussione prima del voto.

GiP chiave:

• #800 Multi-Model PoC — supporto per più modelli AI contemporaneamente. Attualmente la rete opera con Qwen3-235B e Kimi K2.6 (tramite DevShards da maggio 2026). MiniMax-M2.7 viene aggiunto in v0.2.13. GiP descrive l'architettura per il lavoro parallelo di diversi modelli con un Proof of Useful Work separato.
• #801 Inference Scaling — architettura di sottorete per la scalabilità. Parte di questo GiP è già implementata in v0.2.11 (subnet inferenced).
• #860 Quality Protocol — instradamento delle richieste tenendo conto della qualità delle risposte. I nodi che forniscono risultati migliori ricevono più traffico e ricompense.

Qualsiasi partecipante può creare un GiP tramite GitHub Discussions. La soglia d'ingresso è minima – è necessario solo un account GitHub e la comprensione del problema. Le discussioni attive con la partecipazione del team Gonka e degli host dimostrano che il sistema funziona: le proposte ricevono feedback, vengono perfezionate e si avvicinano all'implementazione.

Community Pool — un fondo per lo sviluppo dell'ecosistema Gonka. Circa il 20% dell'emissione di genesi (~200 milioni di GNK) è stato assegnato a sovvenzioni, bounty e finanziamento di iniziative della comunità.

Bounty per il contributo al codice — il meccanismo principale di distribuzione dei fondi del Community Pool. Gli sviluppatori ricevono una ricompensa per le PR nel repository gonka-ai/gonka: dalla correzione di bug all'implementazione di nuove funzionalità. L'importo del bounty dipende dalla complessità e dall'importanza del contributo:

Meccanismo di approvazione: i bounty sono inclusi nel README delle proposte di aggiornamento. Quando i host votano per l'aggiornamento del protocollo, approvano contemporaneamente l'elenco dei pagamenti per le PR incluse in quella release. La trasparenza è totale: chiunque può verificare per cosa e quanto è stato pagato.

Oltre ai bounty, il Community Pool può finanziare: lo sviluppo di strumenti per l'ecosistema, il marketing, le iniziative educative e le sovvenzioni per la ricerca. Maggiori informazioni su come guadagnare tramite GitHub — in un articolo separato.

Una rete giovane è vulnerabile: pochi nodi, pochi stake, un attacco del 51% è teoricamente possibile. Gonka risolve questo problema con diversi meccanismi.

Guardian System — tre nodi fidati, controllati dal team Gonka, con un totale del 34% di potenza di consenso. I Guardian non possono imporre decisioni (34% < 67% per l'accettazione), ma possono bloccare una proposta dannosa (34% > 33% soglia di veto). Il punto chiave: i Guardian si disattivano automaticamente quando la potenza totale della rete (total_network_power) raggiunge i 10 milioni di unità. Non è un interruttore manuale — la disattivazione è programmata nel protocollo.

Sistema collaterale — i host devono depositare una garanzia in GNK per ottenere il peso completo:

• Base Weight (20%) — peso incondizionato, accreditato per il semplice fatto che il nodo funziona.
• Collateral-Eligible (80%) — peso aggiuntivo, disponibile solo con una garanzia in GNK. La dimensione della garanzia è proporzionale alla potenza di calcolo.

Slashing — penalità per le violazioni:

• 20% della garanzia — per inferenza INVALIDA (il nodo ha fornito un risultato errato).
• 10% della garanzia — per downtime (il nodo è indisponibile oltre la soglia consentita).

Grace Period — 180 epoche (~6 mesi), durante le quali i nuovi host possono lavorare senza garanzia. Questo riduce la barriera di ingresso: si può iniziare a minare, guadagnare GNK tramite ricompense e solo dopo depositare il collaterale. Dopo la fine del Grace Period, un nodo senza garanzia riceve solo il 20% del peso potenziale.

Tutti questi meccanismi sono descritti nella tokenomics di GNK e mirano a un unico obiettivo: proteggere la rete nella fase iniziale, senza sacrificare la decentralizzazione a lungo termine.

La governance in Gonka non è un sistema statico, ma un processo in evoluzione. Ecco le principali direzioni di sviluppo per il 2026-2027.

Multi-Model PoC (GiP #800) — implementato: Kimi K2.6 è già operativo in DevShards da maggio 2026, MiniMax-M2.7 viene aggiunto in v0.2.13 (proposal #54). I prossimi candidati sono modelli di embedding per RAG: questo aprirà Gonka a una nuova classe di applicazioni (motori di ricerca, basi di conoscenza aziendali, chatbot con memoria).

Inference Quality Protocol (GiP #860) — instradamento in base alla qualità. Attualmente le richieste vengono distribuite in base alla disponibilità dei nodi; in futuro, in base alla qualità delle risposte. I nodi con hardware migliore e un funzionamento più stabile avranno la priorità.

On-chain governance migration (2026–2027) — transizione a un modulo x/gov completo dal Cosmos SDK. Questo fornirà: tipi di proposte formalizzati, esecuzione automatica delle modifiche approvate, integrazione con IBC (Inter-Blockchain Communication) e la possibilità di creare proposte di governance tramite qualsiasi wallet compatibile con Cosmos.

Puoi seguire e partecipare alle votazioni su gonka.gg/network/proposals.