Gouvernance de Solana : une analyse complète

Enseignements exploitables

• Les votes de gouvernance sur Solana sont non contraignants et consultatifs : ils servent d’indicateurs du sentiment de la communauté. Permettre aux validateurs d’exprimer leur position avant la mise en œuvre complète contribue à orienter le développement et à limiter les désaccords. La décision finale intervient lorsque les validateurs choisissent le logiciel qu’ils exécutent. Les propositions peuvent encore évoluer après un vote et, en définitive, la gouvernance reflète le consensus plutôt qu’elle ne l’impose.
• Les détenteurs de tokens SOL participent indirectement en déléguant leurs SOL stakés à des validateurs dont les choix de vote correspondent à leurs valeurs ou préférences. Il s’agit d’un système de représentation proportionnelle dans lequel les validateurs peuvent être considérés comme des représentants élus. Les stakers de Solana délèguent leur stake aux validateurs, le pouvoir de vote de chacun étant déterminé par le stake qui lui est délégué.
• Les votes de gouvernance de Solana sont effectués à l’aide de tokens SPL. Des tokens sont attribués aux validateurs proportionnellement à leur stake actif, puis ceux-ci les envoient à des adresses désignées représentant les différentes options de vote. Les validateurs peuvent répartir librement leurs votes entre plusieurs options. Une fois soumis, les votes sont définitifs et ne peuvent plus être modifiés.
• Toutes les mises à jour du protocole qui rompent le consensus sont activées au moyen de feature gates, qui constituent des hard forks non rétrocompatibles. Contrairement à Bitcoin ou Ethereum, où un désaccord lors d’un hard fork peut entraîner une scission permanente de la chaîne, l’approche de Solana garantit l’activation des feature gates sur l’ensemble du cluster à un slot précis. Les validateurs effectuent la mise à niveau au préalable, ce qui évite les scissions de chaîne.
• Plusieurs changements économiques intervenus au début du développement de Solana — notamment l’introduction de frais de priorité avec un burn de 50 % — ont été mis en œuvre sans vote de gouvernance formel, car le système de gouvernance était encore peu mature à cette époque.
• Le modèle actuel de vote de gouvernance — réservé aux validateurs — a été établi à la suite d’un vote consultatif en octobre 2023. Plus de 170 validateurs y ont participé, représentant 14,3 % du stake total, et plus de 70 % de ce stake ont soutenu le vote réservé aux validateurs comme point de départ le plus pratique et le plus efficace.
• Le récent vote sur SIMD-228 a atteint un taux de participation record de 74,3 %, devenant le plus grand événement de gouvernance blockchain de l’histoire en nombre de participants et en capitalisation boursière, avec 281 millions de SOL (~35 Md$) et plus de 900 validateurs ayant exprimé plus de 1 000 votes. Il a marqué la première participation active de validateurs issus de grandes plateformes d’échange comme Coinbase, Kraken et Bybit, soulignant l’engagement institutionnel croissant sur Solana.
• Le rôle limité des délégateurs dans la prise de décision constitue une préoccupation récurrente du processus de gouvernance de Solana. Il n’existe aujourd’hui aucun mécanisme formel permettant aux délégateurs d’exprimer leurs préférences ou de passer outre les décisions des validateurs, ce qui peut conduire à des situations où les votes des validateurs entrent en conflit avec les préférences de leurs délégateurs.
• Le rôle d’un quorum défini dans les votes de gouvernance de Solana a également suscité des inquiétudes. En pratique, les quorums peuvent créer des incitations perverses : les participants peuvent retenir stratégiquement leur vote pour empêcher une proposition d’atteindre le seuil requis. Ce phénomène a été observé dans les tendances de vote relatives à SIMD-228.
• Le Solana Foundation Delegation Program délègue 10 % du total des SOL stakés (41,01 millions) à 897 validateurs, amplifiant ainsi leur pouvoir de vote. L’analyse du récent vote SIMD-288 indique que le stake du SFDP a principalement servi à voter contre la proposition. Si ce stake avait voté OUI, la proposition aurait été adoptée. Si le stake délégué par le SFDP s’était abstenu, la proposition aurait tout de même été rejetée, mais avec une marge plus faible : 64,77 % contre 61,39 % dans les faits.
• Des incertitudes subsistent quant aux sujets qui justifient un vote de gouvernance. En mars 2025, un vote prévu sur SIMD-218 (IVC) a été retiré après l’émergence d’un consensus estimant qu’il ne nécessitait pas l’approbation de la gouvernance. De même, bien que SIMD-123 ait été adopté, il ne s’agissait pas clairement d’un changement économique et un vote formel n’était peut-être pas justifié.

Introduction

La gouvernance est une composante essentielle de la décentralisation. Elle influence aussi bien les mises à niveau du protocole et les politiques économiques que le comportement des validateurs et les normes de la communauté. Un système de gouvernance efficace améliore la transparence, l’équité et la confiance, tandis qu’une mauvaise gouvernance peut entraîner confusion, stagnation ou centralisation du pouvoir.

La gouvernance de Solana n’en est encore qu’aux premières étapes de son développement. Comme de nombreux réseaux blockchain, Solana n’a pas été lancé avec un cadre de gouvernance entièrement mature ou formalisé. Celui-ci a plutôt évolué progressivement, façonné par les pratiques de la communauté, les contraintes techniques et les enseignements tirés. L’amélioration de la gouvernance de Solana est un processus continu et itératif.

L’écosystème Solana réunit des groupes de parties prenantes variés et qui se recoupent : détenteurs de tokens, stakers, utilisateurs, validateurs, opérateurs RPC, développeurs d’applications et ingénieurs du protocole principal. Chaque groupe apporte des perspectives, des incitations et des objectifs différents. Si ces intérêts peuvent converger dans certains domaines, ils divergent souvent, en particulier concernant la répartition des ressources, le contrôle du protocole et la politique économique.

Dans les systèmes décentralisés, la gouvernance repose autant sur le consensus social que sur le code. Bien que les blockchains soient souvent décrites selon le principe « le code fait loi », l’histoire a montré que lorsque le consensus de la communauté l’exige, le code peut changer — et change effectivement. La conception des mécanismes de gouvernance et leur capacité à évoluer au fil du temps sont donc aussi importantes que l’architecture technique initiale.

Ce rapport vise à clarifier la structure, l’évolution et l’état actuel de la gouvernance sur Solana. Il offre une vue d’ensemble complète de la manière dont les décisions sont prises au sein du réseau et compare sa gouvernance à celle d’autres écosystèmes blockchain. Le rapport est structuré en quatre sections principales :

• Éléments de la gouvernance de Solana – Examine les composantes essentielles du processus de gouvernance de Solana, notamment les SIMDs, les activations de feature gates et les votes formels on-chain.
• Analyse des votes de gouvernance – Présente une vue d’ensemble détaillée de tous les votes de gouvernance formels organisés à ce jour, notamment leurs résultats, le comportement des votants et les indicateurs de participation.
• Défis et recommandations – Étudie les principaux problèmes auxquels le modèle de gouvernance actuel de Solana est confronté et formule, lorsque cela est pertinent, des recommandations concrètes.
• Comparaison avec d’autres réseaux – Examine le fonctionnement de la gouvernance dans les écosystèmes comparables de Cosmos et Ethereum, en soulignant les pratiques susceptibles d’améliorer Solana.

Bien que la lecture du rapport soit plus fluide dans l’ordre, chaque section est autonome et peut être consultée séparément.

Éléments de la gouvernance de Solana

Le tableau ci-dessous présente une vue d’ensemble du système de gouvernance de Solana, structurée à l’aide d’un cadre analytique adapté de l’article Analyse de la prise de décision dans la gouvernance blockchain de Schädler, Lustenberger et Spychiger (2023). Nous avons adapté ce cadre afin de refléter les mécanismes et dynamiques propres à l’écosystème Solana.

Les modifications du protocole Solana suivent un processus en plusieurs étapes qui varie selon la nature et l’impact du changement. Les principaux facteurs comprennent la rupture éventuelle du consensus, l’impact sur les parties prenantes ainsi que le niveau de désaccord ou de complexité. Un changement rompant le consensus désigne toute mise à jour du protocole qui amène des nœuds exécutant différentes versions du logiciel à ne plus s’accorder sur l’état de la blockchain. 

Le tableau suivant décrit les étapes généralement suivies pour des changements de différentes ampleurs. Les « changements majeurs » désignent ceux qui peuvent avoir un impact économique.

Nous décrivons ci-dessous en détail les processus d’activation des feature gates, des SIMDs et des votes de gouvernance.

Activations des feature gates

Les équipes de développement principales d’Anza et de Firedancer déploient fréquemment de nouvelles fonctionnalités, notamment des syscalls, des programmes natifs et des changements économiques qui rompent le consensus. Ces fonctionnalités sont créées, intégrées aux nouvelles versions des logiciels clients et désactivées par défaut derrière un feature flag. Le Feature Gate Program, récemment migré vers un programme Core BPF, suit chaque nouvelle fonctionnalité sous la forme d’un compte. Une clé privée propre à chaque feature gate est détenue par le contributeur principal associé à celle-ci. Une fois qu’un nombre suffisant de validateurs en termes de stake a effectué la mise à niveau vers la nouvelle version et que celle-ci est jugée stable, le commutateur de fonctionnalité du runtime est activé manuellement au moyen d’une instruction. La fonctionnalité est alors mise en service sur tous les nœuds du réseau au début de l’époque suivante. L’ordre et le calendrier précis des activations peuvent être suivis dans le calendrier des feature gates. L’activation des fonctionnalités est indépendante du cluster : elle a d’abord lieu sur Testnet, puis sur Devnet et enfin sur Mainnet, ce qui permet de renforcer la confiance dans les nouvelles versions avant leur activation finale sur Mainnet.

Le « plancher de version » correspond à la version logicielle minimale actuellement prise en charge par un cluster. À mesure que de nouvelles feature gates sont activées, ce plancher est relevé pour correspondre à la version logicielle dans laquelle la fonctionnalité a été intégrée. Les activations de nouvelles fonctionnalités sur Solana suivent un rythme régulier, généralement aux limites d’époque qui interviennent pendant les heures ouvrées en semaine. Elles sont suspendues pendant les transitions de version et reprennent environ deux époques après que 95 % du stake a migré vers une nouvelle version mineure (par exemple, de la version 2.2 à la version 2.3).

Les activations de feature gates sont des hard forks non rétrocompatibles qui nécessitent une adoption universelle pour prendre effet. Si un validateur ne passe pas à une version qui reconnaît une feature gate activée, il ne peut plus continuer à valider l’état global et diverge du réseau.

Contrairement à Bitcoin ou Ethereum, où un désaccord lors d’un hard fork peut entraîner une scission permanente de la chaîne, l’approche de Solana garantit que les feature gates sont activées sur l’ensemble du cluster à un slot précis. Les validateurs doivent effectuer la mise à niveau au préalable, ce qui évite les scissions de chaîne. Ainsi, même si les feature gates sont des hard forks puisqu’elles modifient les règles de consensus, elles ne peuvent pas donner naissance à des chaînes concurrentes.

Les nouvelles versions des clients comprennent également de nombreux changements qui ne rompent pas le consensus, comme des refactorisations du code et des optimisations d’efficacité, et qui ne nécessitent aucune feature gate.

Solana Improvement Documents (SIMDs)

Les propositions de Solana Improvement Document (SIMD) constituent la documentation formelle nécessaire à toute modification substantielle des composants principaux de Solana. Les changements « substantiels » sont définis comme ceux qui modifient généralement le protocole réseau, la validité des transactions ou l’interopérabilité. Les changements non substantiels, comme une refactorisation mineure du code ou des améliorations objectives des performances, ne nécessitent pas de proposition. Les propositions doivent documenter la justification de la fonctionnalité et fournir suffisamment d’informations pour en comprendre l’implémentation. 

Bien que la soumission de SIMDs soit sans permission, la plupart sont proposées par des développeurs d’équipes clientes qui travaillent à temps plein à l’amélioration du protocole principal.

Il existe deux types de propositions : 

• Propositions standard : concernent les fonctionnalités principales de Solana (par exemple, le consensus, le réseau et les interfaces API)
• Méta-propositions : concernent des processus ou des directives extérieurs à la base de code

Les SIMDs passent généralement par les étapes d’évaluation de l’idée, de rédaction, d’examen et d’acceptation. Un examen formel a lieu publiquement sur GitHub. L’auteur de la proposition doit recueillir les commentaires des contributeurs principaux concernés au sein des équipes clientes Agave et Firedancer. Ceux-ci déterminent si la proposition est acceptée, révisée ou retirée en tenant compte de la sécurité, des compromis et de la rétrocompatibilité.

Les auteurs ne sont pas tenus d’implémenter leurs propositions, mais il leur est généralement recommandé de le faire, car c’est le meilleur moyen d’en assurer l’aboutissement. Lorsqu’elles sont acceptées, les propositions incluent souvent une issue de suivi associée à l’implémentation de la fonctionnalité et nécessitent généralement une activation au moyen du mécanisme de feature gate de Solana. 

Bien que toutes les activations de feature gates ne nécessitent pas de SIMD, la majorité s’accompagnent d’un tel document afin de fournir le contexte, la justification et un enregistrement normalisé du changement proposé.

Votes de gouvernance

Les SIMDs qui modifient sensiblement le protocole, en particulier celles qui affectent les paramètres économiques, nécessitent des votes de gouvernance. Piloté par des membres expérimentés de la communauté des validateurs, le processus de gouvernance de Solana se concentre uniquement sur les questions critiques afin de maintenir l’engagement et d’éviter la lassitude liée à la gouvernance. Par conséquent, seuls quelques votes ont lieu chaque année.  

Les votes de gouvernance servent principalement à mesurer l’opinion à l’égard des changements proposés. Permettre aux validateurs d’indiquer leur position avant la mise en œuvre complète contribue à orienter le développement et à limiter les désaccords. La mise en œuvre d’un changement sans large consensus pourrait créer des frictions, notamment si plus d’un tiers du réseau refuse de l’adopter.

Le vote est effectué à l’aide de tokens SPL. Le compte d’identité de chaque validateur actif reçoit des tokens proportionnellement à son stake actif mesuré en lamports. Le validateur peut ensuite envoyer ces tokens à des adresses désignées représentant les différentes options de vote, y compris l’abstention. Les validateurs peuvent répartir librement leurs votes entre plusieurs options — par exemple, 80 % pour OUI et 20 % pour NON — ce qui leur permet de refléter les préférences variées de leurs stakers. Une fois soumis, les votes sont définitifs et ne peuvent plus être modifiés.

Dans cette structure, les détenteurs de tokens SOL participent indirectement en déléguant leurs SOL stakés à des validateurs dont les choix de vote correspondent à leurs valeurs ou préférences. Il s’agit d’un système de représentation proportionnelle dans lequel les validateurs peuvent être considérés comme des représentants élus. Les stakers de Solana délèguent leur stake aux validateurs, et le pouvoir de vote de chaque validateur dépend de son stake actif.

Les limites de la gouvernance on-chain

toly 🇺🇸

@toly

@garious14 There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

17 mars 2025, 3:56 PM

La gouvernance sur Solana est, en définitive, non contraignante et consultative. En pratique, le véritable vote intervient lorsque les validateurs choisissent la version du logiciel qu’ils exécutent. Les votes de gouvernance peuvent indiquer un large soutien ou une forte opposition de la communauté, mais ils n’obligent pas les validateurs à adopter un code particulier. Les propositions peuvent même évoluer après le vote, et les validateurs conservent un contrôle total sur ce qui s’exécute dans leur infrastructure. Cette dynamique signifie que la gouvernance vise davantage à signaler un consensus qu’à imposer des résultats.

Dans ce contexte, les contributeurs principaux comme Anza, Jump et Jito ainsi que les fournisseurs d’infrastructure comme Helius et Triton exercent une influence informelle considérable. Comme les validateurs sont peu susceptibles de s’opposer à ces groupes au risque de perdre du stake ou de se désynchroniser du réseau, ces entités peuvent effectivement influencer l’issue des mises à niveau, qu’elles disposent ou non d’un pouvoir décisionnel formel.

Un fork pourrait se produire dans un scénario extrême où les validateurs refuseraient une mise à niveau. Le DAO Fork d’Ethereum en 2016, qui a conduit à la création d’Ethereum Classic, reste un exemple édifiant. À mesure que le processus de gouvernance de Solana évolue, clarifier la relation entre les votes indicatifs, les versions logicielles et l’adoption réelle par les validateurs permettra d’assurer la transparence et d’éviter les risques extrêmes de scission de chaîne.

Analyse des votes de gouvernance

Les débuts de la gouvernance de Solana : 2020-2022

L’approche initiale de Solana en matière de gouvernance était très différente du cadre actuel. La gouvernance reposait alors sur le Feature Proposal Program, qui permettait aux validateurs de voter sur les modifications du protocole à l’aide de tokens SPL pondérés selon le stake. Lorsqu’une nouvelle version d’une fonctionnalité était prête à être activée, des tokens de vote étaient attribués aux validateurs proportionnellement à leur stake actif. En renvoyant ces tokens vers un compte désigné pendant une période de deux semaines, les validateurs pouvaient indiquer leur approbation de l’activation de la fonctionnalité proposée. Une fois le seuil de 67 % du stake atteint, le changement était directement activé on-chain à l’époque suivante.

Le Feature Proposal Program a servi à plusieurs reprises à organiser des votes de gouvernance des validateurs sur Testnet et Mainnet, notamment pour activer le calendrier d’inflation actuel.

Les archives en ligne de ces premiers votes de gouvernance sont rares, car les forums Solana d’origine ont été mis hors ligne et ne sont désormais accessibles que par l’intermédiaire de versions archivées sur la Wayback Machine.

Bien que ce mécanisme ait introduit une certaine coordination on-chain, il a fait l’objet de nombreuses critiques. Les validateurs ne pouvaient pas exprimer leur désaccord : seuls les votes OUI étaient comptabilisés, sans méthode formelle permettant de voter contre ou de s’abstenir. Ce système créait également une pression sociale en faveur de l’approbation des changements, surtout après que d’importants efforts d’ingénierie avaient déjà été consacrés à leur implémentation. 

Plus important encore, le système ne permettait pas d’émettre un signal en amont. Des fonctionnalités complexes pouvaient donc être développées sans savoir si elles seraient acceptées, entraînant inefficacité et perte de temps de développement.

Dans l’ensemble, bien que le Feature Proposal Program ait constitué une première étape importante dans le parcours de gouvernance de Solana, ses limites ont contribué à façonner les mécanismes de gouvernance plus flexibles utilisés aujourd’hui.

Il convient de noter que plusieurs changements économiques majeurs de cette première période — comme l’introduction de frais de priorité avec un burn de 50 % — ont été mis en œuvre sans vote de gouvernance formel, ce qui reflète une époque où le système de gouvernance n’en était encore qu’à ses débuts.

Gouvernance actuelle de Solana : depuis 2023

Après le recours au Feature Proposal Program, Solana a évolué vers son système actuel de vote de gouvernance. À ce jour, cinq votes de gouvernance officiels ont eu lieu :

• Vote consultatif initial d’octobre 2023
• SIMD-33 Crédits de vote ponctuels en avril 2024 par Bryan Ischo et Zantetsu, Shinobi Systems
• SIMD-96 Intégralité des frais de priorité aux validateurs en mai 2024 par Tao Zhu, Anza
• SIMD-123 Distribution des récompenses de bloc intégrée au protocole par Justin Starry, Anza
• SIMD-228 Mécanisme d’émissions fondé sur le marché par Tushar Jain et Vishal Kankani, Multicoin Capital, Max Resnick, Anza, en mars 2025

Vote consultatif initial

Une décision initiale déterminante pour façonner le cadre de gouvernance actuel de Solana consistait à établir qui devait participer au processus de vote. Trois options ont été présentées à la communauté :

1. Vote réservé aux validateurs, pondéré selon le stake
2. Validateurs et comptes de stake, permettant aux délégateurs de passer outre le vote de leur validateur
3. Validateurs, comptes de stake et autres parties prenantes, comme les opérateurs RPC et les développeurs

Plus de 170 validateurs ont participé au vote consultatif, représentant 14,3 % du stake total. Parmi le stake ayant voté, plus de 70 % ont soutenu un vote réservé aux validateurs, tandis que 24 % ont préféré un modèle associant validateurs et délégateurs. Aucun seuil minimal de participation n’a été appliqué à ce vote.

Le vote réservé aux validateurs a été privilégié comme point de départ le plus pratique et le plus efficace, car l’infrastructure existait déjà et avait été éprouvée en conditions réelles. Les systèmes plus complexes impliquant des délégateurs ou d’autres parties prenantes ont été jugés prématurés et potentiellement trop lourds pour un processus de gouvernance naissant. La communauté a reconnu que d’autres modèles de vote pourraient être introduits et affinés par de futures propositions à mesure que la gouvernance gagnerait en maturité.

Tendances des votes de gouvernance

Depuis le vote consultatif initial, quatre autres votes de gouvernance ont eu lieu, avec les trois mêmes options : OUI, NON et Abstention. Ces options indiquent l’accord ou le désaccord avec la SIMD proposée. Pour qu’un vote soit adopté, au moins deux tiers des votes OUI et NON combinés doivent être favorables (c’est-à-dire OUI). 

SIMD-33 : Crédits de vote ponctuels a été approuvée à une écrasante majorité, avec 98,4 % de votes OUI. Cette modification consensuelle et peu controversée a corrigé des incitations mal alignées en supprimant l’avantage que les validateurs tiraient auparavant de la soumission tardive de leurs votes, améliorant ainsi le comportement du réseau et son équité.

SIMD-96 : Intégralité des frais de priorité aux validateurs a été adoptée avec 77,7 % de votes OUI. Cette proposition économique visait à décourager le traitement des transactions par des canaux parallèles en attribuant 100 % des frais de priorité aux validateurs. Bien qu’efficace pour aligner les incitations, elle a suscité une certaine controverse en raison d’une légère hausse de l’inflation et d’un favoritisme perçu envers les validateurs au détriment des détenteurs de SOL.

SIMD-123 : Distribution des récompenses de bloc intégrée au protocole a été approuvée avec 74,91 % de votes OUI. La proposition a introduit un mécanisme facultatif et normalisé permettant aux validateurs de distribuer directement les récompenses de bloc aux stakers. Bien que plusieurs validateurs le fassent déjà au moyen de méthodes plus manuelles, son intégration au protocole a suscité un débat sur la pression concurrentielle et la crainte d’une « course vers zéro » des taux de commission sur les récompenses de bloc.

SIMD-228 : Mécanisme d’émissions fondé sur le marché n’a pas été adoptée, avec seulement 61,39 % de votes OUI. La proposition visait à rendre le taux d’inflation de Solana plus réactif à la participation au staking, en affirmant que les émissions actuelles sont trop élevées, qu’elles ne répondent pas à la demande de rendement et qu’elles conduisent le réseau à surpayer sa sécurité.

Les opposants ont exprimé leurs inquiétudes concernant la viabilité économique des petits validateurs et l’incertitude supplémentaire que la proposition pourrait introduire dans les rendements du staking. Le vote s’est révélé très controversé, suscitant un vaste débat et mettant en lumière des divergences de vues sur le modèle économique à long terme de Solana.

Pour une analyse détaillée du comportement des votants, les lecteurs sont invités à consulter les tableaux de bord de vote open source consacrés à SIMD-96, SIMD-123 et SIMD-228. Nous proposons également une feuille de calcul contenant les données de vote disponibles ici.

Des seuils de quorum fixés à 33 % de participation du stake — votes d’abstention compris — ont été appliqués à SIMD-228 et SIMD-123. À l’inverse, les propositions antérieures comme SIMD-96 et SIMD-33 n’imposaient aucune participation minimale, ce qui signifie qu’elles pouvaient être adoptées quelle que soit la part du stake total ayant voté.

Taux de participation

Les taux de participation aux votes ont augmenté au fil du temps. Le vote consultatif initial d’octobre 2023 a suscité un engagement minimal, avec seulement 14,3 % du stake participant. Depuis, la participation a progressé régulièrement jusqu’au vote de mars 2025 sur SIMD-228, le mécanisme d’émissions fondé sur le marché, qui a atteint un taux de 74,3 %. Les trois autres votes organisés à ce jour ont affiché des niveaux de participation relativement constants, compris entre 51,2 % et 57,1 %.

Le vote sur SIMD-228 a constitué le plus grand événement de gouvernance de l’histoire des cryptomonnaies, tant par le nombre de participants que par la capitalisation boursière totale représentée. Au moment du débat, la capitalisation de Solana était comparable à celle de Bitcoin pendant les guerres sur la taille des blocs de mi-2017, ce qui souligne l’importance de la décision. Au total, 281 millions de SOL, valorisés à 35 milliards de dollars, ont participé au vote, avec plus de 900 validateurs ayant soumis plus de 1 000 votes. Fait notable, il s’agissait de la première participation active de validateurs de grandes plateformes d’échange — notamment Coinbase, Kraken et Bybit — à la gouvernance on-chain de Solana, signe d’une présence institutionnelle croissante dans le processus décisionnel du réseau. Cette récente hausse de la participation, notamment de la part d’entités établies aux États-Unis, pourrait aussi s’expliquer en partie par un climat réglementaire plus favorable aux blockchains sous l’administration actuelle.

Problèmes et recommandations

Dans la section suivante, nous examinerons les principaux défis du processus de vote de gouvernance et, lorsque cela est pertinent, formulerons des recommandations afin d’en améliorer la transparence, la sécurité et l’efficacité.

Faible participation des stakers

Le rôle limité des délégateurs dans la prise de décision constitue une préoccupation récurrente du processus de gouvernance de Solana. Bien que les validateurs votent sur les propositions avec un pouvoir de gouvernance pondéré selon le stake, aucun mécanisme formel ne permet aux délégateurs d’exprimer leurs préférences ou de passer outre les décisions des validateurs. Il peut donc arriver que le vote d’un validateur entre en conflit avec les intérêts de ses délégateurs, sans que les stakers puissent influencer directement l’issue de la gouvernance.

Les validateurs qui comptent des milliers de délégateurs ont du mal à recueillir les préférences individuelles de chacun, et les taux d’engagement des stakers sont généralement faibles. Plusieurs validateurs répondent partiellement à ce problème en consultant leurs principaux délégateurs avant de voter et en répartissant leurs votes selon leurs préférences. D’autres ont expérimenté des outils personnalisés reproduisant le système existant de vote par tokens, en émettant de nouveaux tokens de gouvernance à destination de leurs stakers en fonction de leur stake proportionnel. Cette solution reste toutefois propre à chaque validateur et ne constitue pas une fonctionnalité normalisée à l’échelle du protocole.

Les opposants à la participation des stakers soulignent que la plupart des délégateurs ne sont pas techniciens, suivent rarement les décisions de gouvernance de près et ne disposent pas de la compréhension approfondie des mécanismes et compromis de la blockchain nécessaire pour prendre des décisions éclairées. Les partisans de cette participation estiment toutefois que s’en remettre uniquement aux validateurs crée un conflit d’intérêts : il est irréaliste d’attendre d’une majorité de validateurs qu’ils votent en faveur de propositions bénéfiques au réseau si celles-ci nuisent à leurs propres intérêts économiques.

Parmi les améliorations possibles figurent de meilleurs canaux de communication entre validateurs et délégateurs, comme des tableaux de bord de gouvernance, des outils de suivi du sentiment ou même des notifications de wallet pour les événements de gouvernance. Une section ultérieure de ce rapport reviendra sur ce sujet en examinant l’approche de l’écosystème Cosmos.

Difficultés du débat sur la gouvernance

Une gouvernance efficace dans les écosystèmes décentralisés repose sur une communication claire et pertinente. Toutefois, lors de la récente proposition SIMD-288, les débats houleux, les attaques personnelles et le factionnalisme ont créé un environnement de gouvernance malsain, entravant finalement les échanges productifs. Les discussions sur les principales propositions de Solana peuvent souffrir d’inefficacité et d’une dégradation de la qualité des échanges d’une plateforme à l’autre. Si les discussions techniques sur GitHub et les forums officiels de Solana offrent un débat structuré et réfléchi, les échanges sur Discord et Twitter dégénèrent parfois en guerres de commentaires et en attaques ad hominem, ce qui réduit la qualité globale de la prise de décision.

En outre, la plupart des participants n’interviennent que dans les derniers jours précédant le vote, au lieu de profiter de l’intégralité de la période de discussion. Encourager une participation plus précoce et mieux structurer le calendrier de gouvernance — en veillant par exemple à ce que les discussions essentielles aient lieu bien avant la période de vote finale — pourrait contribuer à atténuer ces problèmes.

Les appels consacrés à la gouvernance se sont révélés efficaces, car ils ont permis des échanges directs, des clarifications rapides et moins d’occasions de troller ou de détourner le débat. Renforcer la modération, favoriser des discussions structurées et privilégier les analyses factuelles plutôt que les échanges conflictuels sont essentiels au maintien d’un processus de gouvernance constructif.

Regroupement des propositions de gouvernance

Les décisions de gouvernance sont souvent plus efficaces lorsque chaque proposition fait l’objet d’un vote indépendant, ce qui permet aux votants d’évaluer chaque question selon ses propres mérites. Le biais inconscient constitue l’un des principaux problèmes du regroupement : les votants qui ont une opinion tranchée sur une question peuvent involontairement la laisser influencer leur position sur d’autres sujets, même sans rapport. Cela réduit la probabilité de décisions nuancées et pourrait empêcher la mise en œuvre de changements pourtant bénéfiques.

Le regroupement accroît également la complexité opérationnelle et donc le risque d’erreur. Cela a été observé pendant la période de vote conjointe sur SIMD-228 et SIMD-123, lorsqu’un petit nombre de tokens destinés à SIMD-123 ont été envoyés par erreur à l’adresse d’abstention de SIMD-228. Bien que rares, de telles erreurs faussent les résultats et sapent la confiance dans le processus de gouvernance.

À l’inverse, les partisans du regroupement soutiennent que réunir plusieurs décisions en un nombre réduit de périodes de vote peut limiter la lassitude des votants et favoriser une participation accrue. Si cette approche peut améliorer l’engagement, elle nuit à la clarté et à la précision de la prise de décision. En outre, lorsque les propositions regroupées sont complexes, elles nécessitent souvent des périodes de discussion et d’examen prolongées avant le début du vote, afin de laisser aux votants — notamment ceux qui interviennent habituellement à la dernière minute — suffisamment de temps pour comprendre et évaluer chaque composante en détail.

Une approche plus efficace pourrait consister à séparer les propositions de gouvernance chaque fois que possible, afin que chaque question soit évaluée indépendamment. Si un regroupement est nécessaire, il doit être clairement justifié.

Quorums de vote

Le rôle d’un quorum défini dans les votes de gouvernance de Solana a suscité des inquiétudes. En pratique, les quorums peuvent créer des incitations perverses, les participants retenant stratégiquement leur vote pour empêcher une proposition d’atteindre le seuil requis. Lors du récent vote sur SIMD-228, ce phénomène était particulièrement visible parmi les partisans du NON qui, pendant les deux premières époques du vote, ont jugé l’abstention plus efficace qu’un vote actif contre la proposition. 

La visibilité en temps réel du décompte influence la participation. Certains validateurs peuvent décider de ne pas voter si le résultat attendu correspond déjà à leur préférence. Pour éviter la manipulation du quorum, une amélioration possible consisterait à ne rendre les votes visibles qu’à la fin de la période de scrutin.

Compte tenu de ces difficultés, un soutien croissant se manifeste en faveur d’une réévaluation ou d’une suppression des exigences de quorum, afin de rendre la participation à la gouvernance plus directe et plus transparente.

Effets du SFDP

Au moment de la rédaction, le Solana Foundation Delegation Program délègue des SOL à 897 validateurs, qui représentent 66 % de tous les validateurs actifs du réseau. Le montant total délégué s’élève à 41,01 millions de SOL, soit 10 % de l’ensemble des SOL stakés. Les lecteurs peuvent consulter le précédent rapport du blog Helius sur le SFDP pour obtenir tous les détails sur le programme et ses stratégies de délégation.

Dans le modèle de gouvernance actuel, les validateurs du programme voient leur pouvoir de vote effectivement amplifié et votent au nom de la Solana Foundation. Notre analyse interne et notre tableau de bord public consacrés au récent vote de gouvernance SIMD-288 confirment que le stake du SFDP joue un rôle important dans les résultats. Lors de ce vote, le stake du SFDP a principalement été utilisé pour voter NON à la proposition. Si le stake contrôlé par le SFDP ayant voté NON ou s’étant abstenu avait plutôt voté OUI, la proposition aurait été adoptée. Si tout le stake contrôlé par le SFDP était resté neutre et s’était abstenu, la proposition aurait tout de même été rejetée, mais avec une marge plus étroite : 64,77 % contre 61,39 % dans les faits (66,6 % étant nécessaires pour l’adoption).

Clarté des critères de déclenchement des votes

Les votes de gouvernance de mars 2025 devaient initialement porter sur trois propositions : SIMD-228, SIMD-123 et SIMD-218 : Crédits de vote intermédiaires (IVC). IVC élimine le besoin de mods exécutés par les validateurs qui optimisent les crédits de vote de Tower BFT (la variante de Solana de l’algorithme de consensus pBFT), en complétant automatiquement les crédits de tous les blocs parents lorsque les validateurs votent sur un bloc enfant.

Au cours de la période de discussion, un consensus croissant s’est dégagé sur le fait que SIMD-218 ne devait pas nécessiter l’approbation de la gouvernance. Le changement était largement considéré comme une correction de bug plutôt que comme une modification substantielle du protocole, puisqu’il améliorait ou corrigeait simplement la mise à niveau Timely Vote Credits (TVC). TVC avait déjà été approuvée par un vote de gouvernance et bénéficiait d’un fort soutien de la communauté. Un sondage informel auprès des validateurs sur le Solana Tech Discord a conforté ce point de vue avec un accord presque unanime.

En outre, des ingénieurs d’Anza ont souligné que SIMD-123 : Distribution des récompenses de bloc intégrée au protocole ne constituait pas un changement économique, contrairement à ce que son nom pouvait laisser entendre. La proposition introduisait une méthode facultative intégrée au protocole pour distribuer les récompenses de bloc aux stakers. Elle formalisait ainsi une pratique déjà employée par plusieurs validateurs au moyen d’autres méthodes et normalisait une activité auparavant extérieure au protocole.

Cela soulève d’importantes questions de gouvernance :

• Qui décide si une proposition nécessite un vote ? Il n’existe actuellement aucun organe officiel ni processus structuré permettant de déterminer si une proposition doit passer par la gouvernance ou être directement mise en œuvre.
• La définition d’une « modification substantielle du protocole » reste ambiguë. La frontière entre une mise à niveau courante et un changement justifiant une intervention formelle de la gouvernance est floue, les définitions actuelles reposant largement sur la notion assez vague d’« impact économique ».

Problèmes de sécurité

Le processus actuel de vote sur les propositions de gouvernance repose sur un outil tiers, solgov-distributor, développé et hébergé par Laine, un membre de la communauté. Cet outil est un fork d’un distributeur de tokens fondé sur Merkle, développé à l’origine par Jito. Bien que Laine soit un membre très respecté de la communauté, le recours à un outil contrôlé de l’extérieur introduit des hypothèses de confiance et des risques de sécurité.

• Mutabilité – l’outil comme sa documentation sont modifiables, ce qui signifie qu’ils peuvent être changés unilatéralement à tout moment.
• Utilisation des paires de clés d’identité des validateurs – Les validateurs doivent compiler le CLI et réclamer les tokens à l’aide des paires de clés d’identité de leur validateur, qui sont extrêmement sensibles. Tout processus reposant sur un logiciel externe pour interagir avec des identifiants aussi critiques présente un risque de sécurité.
• Dépendance à l’égard d’un mainteneur individuel – Un processus de gouvernance officiel ne devrait pas dépendre de manière critique de tiers externes sans garanties de sécurité formelles ni audits indépendants.

Autres mécanismes de vote

Il existe déjà un outil SPL Feature Proposal (documentation ici), initialement conçu pour faciliter la gouvernance on-chain. Les processus de gouvernance récents n’ont toutefois pas suivi cette approche. solgov-distributor a été utilisé à la place, ce qui soulève la question de la nécessité de cet outil supplémentaire.

En principe, le système de tokens SPL fournit déjà une méthode native de distribution du pouvoir de vote de gouvernance. L’initiateur du processus pourrait simplement distribuer des tokens SPL à tous les validateurs, qui pourraient voter à l’aide du CLI spl-token standard plutôt que de dépendre d’un outil externe. Cela supprimerait les dépendances inutiles et renforcerait l’absence de confiance nécessaire au processus de vote.

Prochain outil de gouvernance on-chain : SIMD-133

La prochaine SIMD-133 : Get Epoch Stakes, dont l’activation sur Mainnet est prévue prochainement, introduit de nouveaux outils de gouvernance permettant aux programmes de récupérer les pondérations de stake on-chain. Actuellement, les programmes on-chain ne connaissent ni la répartition du stake de l’époque en cours ni le montant délégué à chaque compte de vote.

Grâce à SIMD-133, les programmes de gouvernance peuvent prendre des instantanés on-chain des montants de stake des validateurs par l’intermédiaire d’une nouvelle sysvar, ce qui élimine le besoin de processus manuels ou off-chain de vérification du stake. Cela simplifie considérablement le flux de gouvernance existant et supprime la nécessité d’un rapprochement manuel du stake.

Comparaison avec d’autres réseaux

Cosmos

Les chaînes Cosmos SDK proposent un modèle de gouvernance centré sur les délégateurs, dans lequel les stakers peuvent passer outre le vote de leur validateur directement depuis des wallets populaires comme Keplr et Leap. Ainsi, même si un validateur vote initialement avec le poids de l’intégralité de son stake, les délégateurs en désaccord peuvent réaffecter leur part du stake à une autre option de vote. Par exemple, si un validateur détient 2 % du stake total, mais qu’un délégateur disposant d’un poids de 1 % du stake n’est pas d’accord, celui-ci peut voter séparément, réduisant le vote effectif du validateur à 1 % et transférant son propre 1 % vers une autre option.

Ce système garantit que les délégateurs ont toujours le dernier mot, créant ainsi un processus de gouvernance transparent, convivial et efficace. La participation à la gouvernance de Cosmos est très visible, car le vote est directement intégré aux wallets et aux explorateurs de blocs, ce qui le rend facilement accessible à toutes les parties prenantes.

Un exemple pertinent de divergence de comportement entre stakers et validateurs est apparu lors du vote sur la réduction de moitié d’ATOM de Cosmos (proposition 848, nov. 2023), qui visait à ramener le taux d’inflation maximal à 10 % :

• 94,93 % des stakers ont voté OUI, soutenant le plafond d’inflation.
• Seuls 53,44 % des validateurs ont voté OUI, beaucoup souhaitant préserver des sources de revenus plus élevées.

Cette divergence souligne l’importance de la participation directe des stakers pour garantir que les décisions de gouvernance reflètent le sentiment général de la communauté plutôt que les seules préférences des validateurs.

Le module de gouvernance de Cosmos est intégré au niveau du protocole, ce qui renforce son rôle de fonctionnalité essentielle de la blockchain. Certaines décisions de gouvernance peuvent être exécutées automatiquement on-chain, améliorant ainsi la transparence et la responsabilité. 

Bien que ce modèle offre une structure de gouvernance démocratique, il dépend d’une participation active et suppose que les délégateurs disposent du temps et des connaissances nécessaires pour prendre des décisions éclairées. Cosmos propose un autre cadre de gouvernance convaincant que Solana pourrait étudier afin d’identifier des améliorations possibles.

Ethereum

La gouvernance d’Ethereum suit un processus social et off-chain plutôt qu’un vote direct fondé sur le stake. Le processus décisionnel repose principalement sur les Ethereum Improvement Proposals (EIPs), les développeurs principaux et le consensus de la communauté.

Les modifications d’Ethereum sont proposées par l’intermédiaire des EIPs, l’équivalent des SIMDs de Solana. Ces EIPs décrivent de nouvelles fonctionnalités, normes ou mises à niveau du protocole Ethereum. Les Ethereum Request for Comments (ERCs) définissent des normes pour les fonctionnalités de la couche applicative, comme les tokens ERC-20 et les NFTs ERC-721. Ces propositions sont discutées ouvertement sur les forums de recherche Ethereum (Ethereum Magicians), lors d’événements Ethereum populaires (par exemple Devcon, ETHDenver et ETHCC), sur GitHub et pendant les appels des développeurs principaux. La communauté au sens large participe à la gouvernance en débattant des propositions sur des plateformes comme Discord, Farcaster et X.

Contrairement à Cosmos ou Solana, Ethereum n’utilise pas de gouvernance fondée sur le stake ou sur le vote par tokens pour les décisions relatives au protocole. Depuis le passage d’Ethereum au Proof-of-Stake, les validateurs jouent un rôle plus actif dans le consensus, mais ne votent pas formellement. Un consensus approximatif est plutôt atteint par des débats techniques et un large soutien de la communauté. Les modifications du protocole Ethereum dépendent fortement des développeurs principaux chargés de maintenir les clients d’exécution et de consensus d’Ethereum (par exemple Geth, Nethermind et Prysm).

Les mises à niveau majeures sont activées par des hard forks, qui obligent les validateurs et les opérateurs de nœuds à mettre à niveau leur logiciel. Les validateurs appliquent les règles du réseau en choisissant d’adopter ou non les nouvelles mises à niveau. Bien que cela soit rare, une modification controversée et dépourvue de consensus pourrait entraîner une scission de la chaîne, comme lors de forks antérieurs tels que le DAO Fork (2016, Ethereum Classic) et, dans une moindre mesure, le passage d’Ethereum au Proof-of-Stake (2022, EthereumPoW).

Le modèle de gouvernance sociale d’Ethereum privilégie le consensus technique et les discussions communautaires aux mécanismes de vote formels. Si cette approche a permis à Ethereum de rester flexible et décentralisé, elle signifie également que les changements nécessitent de longues discussions et une coordination sociale complexe plutôt qu’une gouvernance directe fondée sur les tokens. De plus, les détenteurs d’ETH et les stakers ne disposent d’aucun moyen formel de voter sur les propositions, ce qui limite l’influence directe des utilisateurs.

Conclusion

Le système de gouvernance de Solana est encore en cours de développement et se façonne au gré des expérimentations concrètes et des contributions de la communauté. Ce rapport a examiné ses principales composantes — SIMDs, activations de fonctionnalités et votes on-chain — tout en passant en revue l’ensemble des votes formels organisés à ce jour, les principaux défis et les comparaisons avec des réseaux comparables comme Cosmos et Ethereum. 

L’écosystème Solana s’appuie sur une solide culture axée sur l’ingénierie, qui privilégie l’itération et l’exécution rapides aux débats prolongés. Si ce rythme élevé de mises à niveau distingue Solana de nombreux réseaux comparables, il crée également des tensions avec les modèles de gouvernance qui reposent sur de longues discussions communautaires et une vaste coordination sociale, ce qui pose des défis particuliers pour concilier rapidité et prise de décision inclusive.

La gouvernance de Solana est encore en train de prendre forme, mais une chose est claire : l’engagement de la communauté n’a jamais été aussi élevé. Alors qu’un nombre croissant de parties prenantes façonnent activement le réseau, Solana dispose d’une occasion unique de bâtir un modèle de gouvernance à la hauteur de son ambition, de sa rapidité et de son écosystème en pleine expansion.

Ressources supplémentaires

• Mesurer la décentralisation de Solana : faits et chiffres - Blog Helius
• Groupe de réflexion sur la gouvernance de Solana
• Gouvernance blockchain : programmer notre avenir - Fred Ehrsam