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 disputa sulla validità di una richiesta di inference o di un risultato PoC, gli host votano tramite il modulo x/group di Cosmos SDK. Il peso del voto è determinato dal PoC weight — più calcolo esegue un nodo, maggiore è la sua influenza. Queste votazioni durano minuti e risolvono conflitti specifici: se l'inference era corretto, se il nodo ha svolto il proprio lavoro.

Governance Voting (giorni) — decisioni strategiche sullo sviluppo del protocollo. Aggiornamenti software, modifiche ai parametri di rete, attivazione di nuovi modelli, distribuzione dei fondi del Community Pool — tutto questo viene sottoposto al voto di tutti gli host. Il periodo di voto va da diversi giorni a una settimana, così che tutti i partecipanti abbiano il tempo di esaminare la proposta.

La differenza chiave rispetto alla maggior parte dei progetti crypto: il peso del voto è determinato dal Proof of Compute, non dallo staking. In Gonka non si può «comprare un voto» semplicemente accumulando token nel wallet. L'influenza è proporzionale al contributo computazionale reale — le GPU che elaborano le richieste AI e generano le prove di lavoro. Dall'aggiornamento v0.2.16 viene conteggiata la potenza confermata nell'epoca precedente: un nuovo host vota con peso zero nella prima epoca, e la crescita di potenza aggiunge voti dall'epoca successiva. Questo lega la governance a chi supporta davvero l'architettura della rete, non al capitale speculativo.

In pratica questo significa: un operatore con due server da 8× H100 ha circa il doppio dei voti di un operatore con un solo server dello stesso tipo — perché elabora circa il doppio delle richieste di inference. Il sistema si autobilancia: chi investe di più nel funzionamento della rete ha più influenza sul suo sviluppo.

L'aggiornamento del protocollo Gonka è un processo formalizzato dal codice all'attivazione sulla 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. Review della community — il codice viene esaminato, discusso e testato. Audit CertiK per le modifiche critiche.
3. Release — viene compilata una nuova versione del binario inferenced.
4. On-chain proposal — viene creata una proposta di aggiornamento sulla rete con la descrizione delle modifiche.
5. Deposit + Vote — gli host versano il deposito (soglia di attivazione) e votano durante il voting period.
6. Cosmovisor — in caso di approvazione, Cosmovisor aggiorna automaticamente i nodi all'altezza di blocco indicata.

Da gennaio a maggio 2026 la rete ha attraversato oltre 13 votazioni andate a buon fine — 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 «favorevoli» contro 0 «contrari». Introdotto il subnet inference — un meccanismo di calcolo off-chain tramite subnet, che promette un aumento della capacità elaborativa di 100 volte.
• v0.2.13 (maggio 2026, proposal #54) — approvato il 21 maggio 2026 (62,8% «favorevoli», affluenza 39,9% con quorum al 33,4%), attivato al blocco 4267300. Ha aggiunto MiniMax-M2.7 come terzo modello della rete, attivato l'Ethereum bridge wiring e ridotto il quorum a 0.25.

Opzioni di voto:

• Yes — sostengo l'aggiornamento.
• No — contrario all'aggiornamento.
• No with Veto — fermamente contrario; se oltre il 33% dei voti è contrario, la proposta viene respinta e il deposito viene bruciato.
• Abstain — mi astengo, ma partecipo al quorum.

L'intera cronologia delle votazioni è disponibile su gonka.gg/network/proposals — puoi consultare 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 per la discussione da parte della comunità.

Le GiP non sono vincolanti: non obbligano il team all'implementazione. Tuttavia, formano il consenso della comunità e definiscono la direzione per le future on-chain proposals. Di fatto, le GiP sono una «pre-governance»: una discussione che precede la votazione.

Principali GiP:

• #800 Multi-Model PoC — supporto per più modelli AI contemporaneamente. Attualmente la rete lavora con MiniMax M2.7 (aggiunto nella v0.2.13), DeepSeek V4 Flash (proposal #94) e GLM-5.3 Flash (proposal #101). La GiP descrive l'architettura per il funzionamento parallelo di diversi modelli con un Proof of Useful Work separato.
• #801 Inference Scaling — subnet architecture per la scalabilità. Parte di questa GiP è già implementata nella v0.2.11 (subnet inference).
• #860 Quality Protocol — routing delle richieste basato sulla qualità delle risposte. I nodi che forniscono risultati migliori ottengono più traffico e ricompense.

Qualsiasi 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 di 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 direzioni chiave di sviluppo per il 2026–2027.

Multi-Model PoC (GiP #800) — implementato: la prima a maggio 2026 tramite DevShards è stata Kimi K2.6 (poi rimossa dalla rete), MiniMax-M2.7 è stata aggiunta nella v0.2.13 (proposal #54), DeepSeek V4 Flash è stata collegata ad agosto 2026 (proposal #94), GLM-5.3 Flash a settembre 2026 (proposal #101). I prossimi candidati sono i 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) — routing basato sulla 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 prestazioni più stabili riceveranno priorità.

On-chain governance migration (2026–2027) — passaggio a un modulo x/gov completo dal Cosmos SDK. Questo offrirà: tipologie di proposta formalizzate, esecuzione automatica delle modifiche approvate, integrazione con l'IBC (Inter-Blockchain Communication) e la possibilità di creare governance proposals tramite qualsiasi wallet compatibile con Cosmos.

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