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é allant du code à l'activation dans le réseau. Chaque étape est transparente et vérifiable.

Processus de mise à niveau :

1. Pull Request dans 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 est créée sur le réseau avec une description des changements.
5. Dépôt + Vote — les hôtes déposent un dépôt (seuil d'activation) et votent pendant la période de vote.
6. Cosmovisor — si approuvé, Cosmovisor met automatiquement à jour les nœuds à la hauteur de bloc spécifiée.

De janvier à mars 2026, le réseau a connu plus de 11 votes réussis — de la version v0.2.2 à la v0.2.11. Toutes les propositions ont été approuvées. Le dernier vote important — la proposition #31 (v0.2.11) — a recueilli 673 699 voix « pour » et 0 voix « contre ». Cette mise à jour a introduit l'inférence de sous-réseau — un mécanisme de calculs off-chain via des sous-réseaux, prometteur d'une augmentation de 100 fois du débit.

Options de vote :

• Oui — je soutiens la mise à jour.
• Non — je suis contre la mise à jour.
• 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 je participe au quorum.

Toute 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 des idées de développement du protocole Gonka, lancé le 24 février 2026 via des discussions GitHub (issue #795).

Format de chaque GiP :

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

Les GiP ne sont pas contraignantes — elles n'obligent pas l'équipe à les mettre en œuvre. Mais elles forment un consensus communautaire et définissent l'orientation des futures propositions on-chain. En fait, les GiP sont une « pré-gouvernance » : discussion avant le vote.

GiP clés :

• #800 Multi-Model PoC — prise en charge de plusieurs modèles d'IA simultanément. Actuellement, le réseau fonctionne avec Qwen3-235B ; ce GiP décrit l'architecture pour le fonctionnement parallèle de différents modèles avec Proof of Useful Work distinct.
• #801 Inference Scaling — architecture de sous-réseau pour la mise à l'échelle. Une partie de ce GiP est déjà implémentée dans la v0.2.11 (inférence de sous-réseau).
• #860 Quality Protocol — routage des requêtes en fonction de la qualité des réponses. Les nœuds qui donnent les meilleurs résultats obtiennent plus de trafic et de récompenses.

Tout participant peut créer un GiP via GitHub Discussions. Le seuil d'entrée est minime — seuls un compte GitHub et une compréhension du problème sont nécessaires. Des discussions actives avec l'équipe Gonka et les hôtes montrent que le système fonctionne : les propositions reçoivent des commentaires, 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 principales directions de développement pour 2026-2027.

Multi-Model PoC (GiP #800) — prise en charge de plusieurs modèles simultanément. Le premier candidat est les modèles d'embedding pour RAG. Cela ouvrira Gonka à une toute 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 le meilleur matériel et un fonctionnement plus stable bénéficieront d'une priorité.

Migration de la gouvernance on-chain (2026–2027) — transition vers un module x/gov complet du Cosmos SDK. Cela permettra : des types de propositions formalisés, l'exécution automatique des changements approuvés, 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 participer sur gonka.gg/network/proposals.