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

La gouvernance chez Gonka fonctionne à deux niveaux, chacun avec sa propre cadence et sa propre portée décisionnelle.

Operational Voting (minutes) — les décisions opérationnelles au sein du réseau. En cas de litige sur 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 de vote est déterminé par le PoC weight — plus une node effectue de calculs, plus son influence est grande. Ces votes durent quelques minutes et tranchent des conflits concrets : l'inférence était-elle correcte, la node a-t-elle fait son travail.

Governance Voting (jours) — les décisions stratégiques sur l'évolution du protocole. Mises à jour logicielles, modification des paramètres du réseau, activation de nouveaux modèles, allocation des fonds du Community Pool — tout cela est soumis au vote de tous les hôtes. La période de vote va de quelques jours à une semaine, afin que chaque participant ait le temps de prendre connaissance de la proposition.

La différence clé avec la plupart des projets crypto : le poids de vote est déterminé par le Proof of Compute, et non par le staking. Chez Gonka, on ne peut pas « acheter une voix » en accumulant simplement des tokens dans un wallet. 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. Depuis la mise à jour v0.2.16, c'est la puissance confirmée lors de l'époque précédente qui est prise en compte : un nouvel hôte vote avec un poids nul lors de sa première époque, et l'augmentation de puissance ajoute des voix à partir de l'époque suivante. Cela lie la gouvernance à ceux qui soutiennent réellement l'architecture du réseau, et non au capital spéculatif.

En pratique, cela signifie qu'un opérateur disposant de deux serveurs de 8× H100 chacun a environ deux fois plus de voix qu'un opérateur avec un seul de ces serveurs — parce qu'il traite environ deux fois plus de requêtes d'inférence. Le système s'auto-équilibre : ceux qui investissent le plus dans le fonctionnement du réseau influencent davantage 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. Revue par la communauté — le code est vérifié, discuté, testé. Audit CertiK pour les changements critiques.
3. Release — une nouvelle version du binaire inferenced est compilée.
4. On-chain proposal — une proposition de mise à jour est créée sur le réseau avec la description des changements.
5. Deposit + Vote — les hôtes déposent un dépôt (seuil d'activation) et votent pendant la voting period.
6. Cosmovisor — en cas d'approbation, Cosmovisor met automatiquement à jour les nœuds à la hauteur de bloc indiquée.

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

• v0.2.11 (mars 2026, proposal #31) — 673 699 votes « pour » contre 0 « contre ». Introduction du subnet inference — un mécanisme de calcul off-chain via des sous-réseaux, promettant une multiplication par 100 du débit.
• v0.2.13 (mai 2026, proposal #54) — adoptée le 21 mai 2026 (62,8 % « pour », participation 39,9 % pour un quorum de 33,4 %), activée au bloc 4267300. Ajout de MiniMax-M2.7 comme troisième modèle du réseau, activation de l'Ethereum bridge wiring et réduction du quorum à 0.25.

Options de vote :

• Yes — je soutiens la mise à jour.
• No — contre la mise à jour.
• No with Veto — catégoriquement contre ; si plus de 33 % des votes — la proposition est rejetée et le dépôt est brûlé.
• Abstain — je m'abstiens, mais je participe au quorum.

Tout l'historique 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 d'idées pour le développement du protocole Gonka, lancé le 24 février 2026 via GitHub Discussions (issue #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 à discuter par la communauté.

Les GiP ne sont pas contraignants (« binding ») — ils n'obligent pas l'équipe à les mettre en œuvre. Mais ils forment un consensus au sein de la communauté et définissent la direction des futurs on-chain proposals. En fait, les GiP sont du « pre-governance » : une discussion avant le vote.

GiP clés :

• #800 Multi-Model PoC — prise en charge de plusieurs modèles AI simultanément. Actuellement, le réseau fonctionne avec MiniMax M2.7 (ajouté dans v0.2.13), DeepSeek V4 Flash (proposal #94) et GLM-5.3 Flash (proposal #101). Le GiP décrit l'architecture pour le fonctionnement parallèle de différents modèles avec un Proof of Useful Work séparé.
• #801 Inference Scaling — architecture de sous-réseaux pour la mise à l'échelle. Une partie de ce GiP est déjà implémentée dans v0.2.11 (subnet inference).
• #860 Quality Protocol — routage des requêtes en tenant compte de la qualité des réponses. Les nœuds qui fournissent 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 minimal — il suffit d'un compte GitHub et de comprendre le problème. Les discussions actives impliquant l'équipe Gonka et les 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 chez Gonka n'est pas un système statique, mais un processus en évolution. Voici les axes de développement clés pour 2026–2027.

Multi-Model PoC (GiP #800) — mis en œuvre : le premier, en mai 2026 via DevShards, a été Kimi K2.6 (retiré du réseau plus tard), MiniMax-M2.7 ajouté dans v0.2.13 (proposal #54), DeepSeek V4 Flash connecté en août 2026 (proposal #94), GLM-5.3 Flash — en septembre 2026 (proposal #101). Les prochains candidats sont des modèles d'embedding 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, elles le seront selon la qualité des réponses. Les nœuds équipés du meilleur matériel et offrant une meilleure stabilité seront prioritaires.

On-chain governance migration (2026–2027) — passage au module complet x/gov du Cosmos SDK. Cela permettra : 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 governance proposals via n'importe quel portefeuille compatible Cosmos.

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