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 nella rete. Ogni passo è trasparente e verificabile.

Processo di aggiornamento:

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

Da gennaio a maggio 2026 la rete ha superato oltre 13 votazioni di successo – dalla versione v0.2.2 alla v0.2.13. Tutte le proposte sono state approvate. Cronologia degli aggiornamenti chiave:

• v0.2.11 (marzo 2026, proposta #31) – 673.699 voti a favore contro 0 contrari. Introdotta l'inferenza subnet – un meccanismo di calcolo off-chain tramite sottoreti, che promette una crescita di 100 volte della capacità.
• v0.2.13 (maggio 2026, proposta #54) – approvata il 21 maggio 2026 (62,8% a favore, affluenza del 39,9% con un quorum del 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 allo 0,25.

Opzioni di voto:

• Yes – supporto l'aggiornamento.
• No – contro l'aggiornamento.
• No with Veto – categoricamente contro; se oltre il 33% dei voti – la proposta viene respinta e il deposito viene bruciato.
• Abstain – 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 di formalizzazione delle idee per lo sviluppo del protocollo Gonka, lanciato il 24 febbraio 2026 tramite GitHub Discussions (issue #795).

Formato di ogni GiP:

• Motivation — quale problema risolve la proposta.
• Solution — descrizione tecnica della soluzione.
• Roadmap — piano di implementazione per fasi.
• Open Questions — questioni irrisolte da discutere con la community.

Le GiP non sono vincolanti: non obbligano il team all'implementazione. Tuttavia, formano il consenso della community e definiscono la direzione per le future on-chain proposals. Di fatto, le GiP sono una fase di "pre-governance": discussione prima del voto.

GiP chiave:

• #800 Multi-Model PoC — supporto per più modelli AI contemporaneamente. Attualmente la rete lavora con Kimi K2.6 e MiniMax M2.7. MiniMax-M2.7 viene aggiunto nella v0.2.13. La GiP descrive l'architettura per il funzionamento parallelo di diversi modelli con Proof of Useful Work separata.
• #801 Inference Scaling — architettura subnet per la scalabilità. Parte di questa GiP è già stata implementata nella v0.2.11 (subnet inference).
• #860 Quality Protocol — instradamento delle richieste basato sulla qualità delle risposte. I nodi che forniscono i risultati migliori ricevono più traffico e ricompense.

Ogni partecipante può creare una GiP tramite GitHub Discussions. La soglia di ingresso è minima: servono 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 procedono verso l'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.