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 (team Gonka o contributori) creano una PR nel repository gonka-ai/gonka.
2. Revisione della comunità — il codice viene esaminato, discusso, testato. Audit di CertiK per modifiche critiche.
3. Release — viene compilata una nuova versione del binario gonkad.
4. Proposta on-chain — viene creata una proposta di aggiornamento in rete con la descrizione delle modifiche.
5. Deposito + Voto — i host depositano (soglia di attivazione) e votano durante il periodo di votazione.
6. Cosmovisor — in caso di approvazione, Cosmovisor aggiorna automaticamente i nodi all'altezza del blocco specificata.

Da gennaio a marzo 2026 la rete ha superato oltre 11 votazioni riuscite — dalla versione v0.2.2 alla v0.2.11. Tutte le proposte sono state approvate. L'ultima votazione importante — proposta #31 (v0.2.11) — ha ottenuto 673.699 voti "sì" contro 0 voti "no". Questo aggiornamento ha introdotto l'inferenza subnet — un meccanismo di calcolo off-chain tramite sottoreti, che promette un aumento di 100 volte della capacità di elaborazione.

Opzioni di voto:

• Sì — supporto l'aggiornamento.
• No — contro l'aggiornamento.
• No con Veto — categoricamente contro; se più del 33% dei voti — la proposta viene respinta e il deposito viene bruciato.
• Astengo — 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 idee per lo sviluppo del protocollo Gonka, lanciato il 24 febbraio 2026 tramite GitHub Discussions (issue #795).

Formato di ogni GiP:

• Motivazione — il problema che la proposta risolve.
• Soluzione — una descrizione tecnica della soluzione.
• Roadmap — un piano di implementazione per fasi.
• Domande aperte — questioni irrisolte per la discussione della comunità.

I GiP non sono vincolanti — non obbligano il team all'implementazione. Ma formano il consenso della comunità e danno una direzione per le future proposte on-chain. In effetti, i GiP sono una "pre-governance": una discussione prima della votazione.

GiP chiave:

• #800 Multi-Model PoC — supporto per più modelli AI contemporaneamente. Attualmente la rete funziona con Qwen3-235B; questo GiP descrive l'architettura per il funzionamento parallelo di diversi modelli con Proof of Useful Work separata.
• #801 Inference Scaling — architettura subnet per lo scaling. Parte di questo GiP è già stata implementata in v0.2.11 (subnet inference).
• #860 Quality Protocol — routing delle richieste tenendo conto della qualità delle risposte. I nodi che forniscono i migliori risultati ottengono più traffico e ricompense.

Qualsiasi partecipante può creare un GiP tramite GitHub Discussions. La soglia di ingresso è minima — è necessario solo un account GitHub e la comprensione del problema. Le discussioni attive con la partecipazione del team Gonka e dei host mostrano che il sistema funziona: le proposte ricevono feedback, vengono perfezionate e si muovono 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 direzioni chiave di sviluppo per il 2026–2027.

Multi-Model PoC (GiP #800) — supporto a più modelli contemporaneamente. Il primo candidato sono i modelli di embedding per RAG. Questo aprirà Gonka a una classe completamente nuova di applicazioni: motori di ricerca, basi di conoscenza aziendali, chatbot con memoria.

Inference Quality Protocol (GiP #860) — routing in base alla qualità. Attualmente le richieste sono 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 otterranno la priorità.

Migrazione della governance on-chain (2026–2027) — passaggio al modulo completo x/gov di 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 portafoglio compatibile con Cosmos.

È possibile seguire le votazioni e partecipare su gonka.gg/network/proposals.