Gouvernance chez Gonka : comment le réseau décentralisé est géré

La gouvernance chez Gonka fonctionne à deux niveaux, chacun avec sa propre vitesse et son échelle de décision.

Operational Voting (minutes) — décisions opérationnelles au sein du réseau. Lorsqu'un litige survient concernant la validité d'une requête d'inférence ou d'un résultat PoC, les hôtes votent via le module x/group du Cosmos SDK. Le poids du vote est déterminé par le poids du PoC — plus un nœud effectue de calculs, plus son influence est grande. Ces votes durent des minutes et résolvent des conflits spécifiques : l'inférence était-elle correcte, le nœud a-t-il fait son travail ?

Governance Voting (jours) — décisions stratégiques concernant le développement du protocole. Les mises à jour logicielles, la modification des paramètres du réseau, l'activation de nouveaux modèles, la distribution des fonds du Community Pool — tout cela est soumis au vote de tous les hôtes. La période de vote est de quelques jours à une semaine, afin que tous les participants aient le temps de prendre connaissance de la proposition.

La différence clé avec la plupart des projets crypto : le poids du vote est déterminé par la preuve de calcul (Proof of Compute), et non par le staking. Chez Gonka, vous ne pouvez pas « acheter une voix » en accumulant simplement des jetons dans un portefeuille. L'influence est proportionnelle à la contribution de calcul réelle — les GPU qui traitent les requêtes d'IA et génèrent des preuves de travail. Cela lie la gouvernance à ceux qui soutiennent réellement l'architecture du réseau, et non au capital spéculatif.

En pratique, cela signifie : un opérateur de ferme de 10 H100 a 10 fois plus de voix qu'un opérateur avec une seule carte — parce qu'il traite 10 fois plus de requêtes d'inférence. Le système est auto-équilibré : ceux qui investissent le plus dans le fonctionnement du réseau influencent le plus son développement.

La mise à jour du protocole Gonka est un processus formalisé, du code à l'activation sur le réseau. Chaque étape est transparente et vérifiable.

Processus de mise à jour :

1. Pull Request sur GitHub — les développeurs (équipe Gonka ou contributeurs) créent une PR dans le dépôt gonka-ai/gonka.
2. Examen par la communauté — le code est examiné, discuté, testé. Audit CertiK pour les changements critiques.
3. Release — une nouvelle version du binaire gonkad est compilée.
4. Proposition on-chain — une proposition de mise à jour du réseau est créée avec la description des changements.
5. Dépôt + Vote — les hôtes déposent une caution (seuil d'activation) et votent pendant la période de vote.
6. Cosmovisor — en cas d'approbation, Cosmovisor met automatiquement à jour les nœuds à la hauteur de bloc spécifiée.

De janvier à mai 2026, le réseau a passé plus de 13 votes positifs — de la version v0.2.2 à la v0.2.13. Toutes les propositions ont été approuvées. Chronologie des mises à niveau clés :

• v0.2.11 (mars 2026, proposition #31) — 673 699 voix « pour » contre 0 « contre ». Introduction de l'inférence de sous-réseau — un mécanisme de calculs hors-chaîne via des sous-réseaux, promettant une augmentation 100 fois du débit.
• v0.2.13 (mai 2026, proposition #54) — acceptée le 21 mai 2026 (62,8 % « pour », participation de 39,9 % avec un quorum de 33,4 %), activée au bloc 4267300. A ajouté MiniMax-M2.7 comme troisième modèle au réseau, activé le câblage du pont Ethereum et réduit le quorum à 0,25.

Options de vote :

• Oui — je soutiens l'accord.
• Non — je suis contre l'accord.
• Non avec Veto — catégoriquement contre ; si plus de 33 % des voix — la proposition est rejetée et le dépôt est brûlé.
• Abstention — je m'abstiens, mais participe au quorum.

L'historique complet des votes est disponible sur gonka.gg/network/proposals — vous pouvez consulter chaque proposition, les résultats et la liste des votants.

GiP est un système de formalisation des idées pour le développement du protocole Gonka, lancé le 24 février 2026 via GitHub Discussions (numéro #795).

Format de chaque GiP:

• Motivation — le problème que la proposition résout.
• Solution — description technique de la solution.
• Roadmap — plan de mise en œuvre par étapes.
• Open Questions — questions non résolues pour discussion par la communauté.

Les GiP ne sont pas contraignantes — elles n'obligent pas l'équipe à la mise en œuvre. Mais elles forment le consensus de la communauté et donnent la direction aux futures propositions on-chain. En fait, GiP est une « pré-gouvernance » : une discussion avant le vote.

Principaux GiP:

• #800 Multi-Model PoC — prise en charge de plusieurs modèles d'IA simultanément. Actuellement, le réseau fonctionne avec Qwen3-235B et Kimi K2.6 (via DevShards à partir de mai 2026). MiniMax-M2.7 est ajouté dans la v0.2.13. Le GiP décrit l'architecture pour le fonctionnement parallèle de différents modèles avec Proof of Useful Work distincte.
• #801 Inference Scaling — architecture de sous-réseau pour l'évolutivité. Une partie de ce GiP est déjà implémentée dans la v0.2.11 (inférence du sous-réseau).
• #860 Quality Protocol — routage des requêtes en tenant compte de la qualité des réponses. Les nœuds qui donnent les meilleurs résultats reçoivent plus de trafic et de récompenses.

Tout participant peut créer un GiP via GitHub Discussions. Le seuil d'entrée est minime — il suffit d'un compte GitHub et d'une compréhension du problème. Les discussions actives avec la participation de l'équipe Gonka et des hôtes montrent que le système fonctionne : les propositions reçoivent des retours, sont affinées et progressent vers la mise en œuvre.

Le Community Pool — fonds de développement de l'écosystème Gonka. Environ 20% de l'émission de genèse (~200 millions de GNK) est alloué aux subventions, aux primes et au financement des initiatives communautaires.

Primes pour les contributions au code — le principal mécanisme de distribution des fonds du Community Pool. Les développeurs reçoivent une récompense pour les PR dans le dépôt gonka-ai/gonka : de la correction de bogues à l'implémentation de nouvelles fonctionnalités. Le montant de la prime dépend de la complexité et de l'importance de la contribution :

Mécanisme d'approbation : les primes sont incluses dans le README des propositions de mise à niveau. Lorsque les hôtes votent pour une mise à jour du protocole, ils approuvent simultanément la liste des paiements pour les PR inclus dans cette version. La transparence est totale — chacun peut vérifier pourquoi et combien a été payé.

Outre les primes, le Community Pool peut financer : le développement d'outils d'écosystème, le marketing, les initiatives éducatives et les subventions de recherche. Plus d'informations sur la manière de gagner via GitHub — dans un article séparé.

Un jeune réseau est vulnérable : peu de nœuds, peu de staking, une attaque à 51% est théoriquement possible. Gonka résout ce problème avec plusieurs mécanismes.

Guardian System — trois nœuds de confiance, contrôlés par l'équipe Gonka, avec un total de 34% de puissance de consensus. Les Gardiens ne peuvent pas imposer de décisions (34% < 67% pour l'approbation), mais ils peuvent bloquer une proposition malveillante (34% > 33% seuil de veto). Point clé : les Gardiens sont automatiquement désactivés lorsque la puissance totale du réseau (total_network_power) atteint 10 millions d'unités. Ce n'est pas un interrupteur manuel — la désactivation est programmée dans le protocole.

Système collatéral — les hôtes doivent déposer une garantie en GNK pour obtenir leur poids total :

• Poids de base (20%) — poids inconditionnel, attribué pour le simple fait que le nœud fonctionne.
• Éligible au collatéral (80%) — poids supplémentaire, disponible uniquement si une garantie en GNK est fournie. Le montant de la garantie est proportionnel à la puissance de calcul.

Slashing — pénalité pour les infractions :

• 20% de la garantie — pour une inférence INVALIDE (le nœud a donné un résultat incorrect).
• 10% de la garantie — pour les temps d'arrêt (le nœud est indisponible au-delà du seuil autorisé).

Période de grâce — 180 époques (~6 mois), pendant lesquelles les nouveaux hôtes peuvent travailler sans garantie. Cela réduit la barrière d'entrée : on peut commencer à miner, gagner du GNK grâce aux récompenses et seulement ensuite fournir la garantie. Après la fin de la période de grâce, un nœud sans garantie ne reçoit que 20% du poids potentiel.

Tous ces mécanismes sont décrits dans la Tokenomics de GNK et visent un seul objectif : protéger le réseau à un stade précoce, sans sacrifier la décentralisation à long terme.

La gouvernance dans Gonka n'est pas un système statique, mais un processus en évolution. Voici les principales directions de développement pour 2026-2027.

Multi-Model PoC (GiP #800) — implémenté : Kimi K2.6 fonctionne déjà dans DevShards depuis mai 2026, MiniMax-M2.7 est ajouté dans la v0.2.13 (proposition #54). Les prochains candidats sont les modèles d'intégration pour RAG : cela ouvrira Gonka à une nouvelle classe d'applications (moteurs de recherche, bases de connaissances d'entreprise, chatbots avec mémoire).

Inference Quality Protocol (GiP #860) — routage par qualité. Actuellement, les requêtes sont distribuées en fonction de la disponibilité des nœuds ; à l'avenir — en fonction de la qualité des réponses. Les nœuds avec un meilleur matériel et un fonctionnement plus stable bénéficieront d'une priorité.

On-chain governance migration (2026–2027) — transition vers le module complet x/gov du Cosmos SDK. Cela offrira : des types de propositions formalisés, l'exécution automatique des modifications approuvées, l'intégration avec IBC (Inter-Blockchain Communication) et la possibilité de créer des propositions de gouvernance via n'importe quel portefeuille compatible Cosmos.

Vous pouvez suivre les votes et y participer sur gonka.gg/network/proposals.