Introduction du slashing sur Solana

Introduction

Le slashing est un mécanisme visant à garantir la sécurité du réseau en sanctionnant les comportements malveillants ou négligents des validateurs. Une fois la faute vérifiée, une partie du stake délégué associé au ou aux validateurs fautifs est brûlée.

Il s’agit d’une caractéristique propre aux réseaux de preuve d’enjeu (Proof of Stake, PoS) comme Solana, sans équivalent dans la preuve de travail (Proof of Work, PoW), car elle repose sur la capacité du protocole à appliquer directement des sanctions financières en détruisant les actifs stakés. Dans la PoW, aucun mécanisme analogue n’existe, puisque la blockchain ne peut ni confisquer ni détruire le matériel de minage physique des acteurs malhonnêtes.

Le slashing présente plusieurs avantages clés :

• Il constitue un frein économique direct aux activités malveillantes
• Il incite les stakers à répartir leur stake entre des validateurs réputés, ce qui améliore la décentralisation
• Il incite les grands opérateurs à mettre en place des infrastructures hétérogènes qui réduisent le risque de défaillances communes (par exemple, en répartissant leur stake entre les clients Firedancer et Agave).
• Il fournit aux validateurs une autre mesure pour se différencier et renforcer leur réputation en évitant les infractions passibles de slashing et en détectant les activités malveillantes des autres participants.

Tout au long de son histoire, Solana s’est appuyée sur une approche manuelle du consensus pilotée par la communauté, appelée « social slashing ». Dans ce modèle, si un validateur agit de manière malveillante, par exemple en compromettant la disponibilité ou la sécurité du réseau, les participants honnêtes peuvent se coordonner hors chaîne pour lancer un hard fork, redémarrer le réseau et appliquer un slashing au stake du fautif. Bien que cette méthode permette une appréciation flexible au cas par cas, elle entraîne une importante charge de coordination et reste intrinsèquement réactive.

À ce jour, aucun validateur sur Solana n’a subi de slashing. L’événement qui s’en est le plus approché remonte à mai 2020, deux mois après le lancement du mainnet, lorsque la Solana Foundation a volontairement brûlé 11,36 millions de SOL de sa propre allocation en réponse aux inquiétudes de la communauté concernant des prêts de tokens non divulgués à des teneurs de marché. Cette opération a réduit l’offre totale de tokens de 2,3 %, la faisant passer de 500 millions à 488,64 millions de SOL. Sans constituer un événement de slashing formel, cette destruction a servi de sanction auto-imposée visant à restaurer la confiance et à répondre aux problèmes de transparence soulevés par la communauté des débuts.

Depuis plusieurs années, certains appellent Solana à adopter un mécanisme de slashing plus formel, souvent appelé slashing programmatique, directement appliqué on-chain par un programme natif. Dans ce système, si un validateur enfreint des règles précises du protocole, une preuve cryptographique de l’infraction peut être générée et transmise à un programme dédié, qui déclenche alors automatiquement le slashing. Ce modèle réduit la dépendance à la coordination humaine et permet de sanctionner les infractions mineures sans perturber le fonctionnement du réseau, ouvrant la voie à une responsabilisation décentralisée et évolutive.

L’activation prochaine de la feature gate de SIMD-0204 : vérification des événements passibles de slashing marque la première grande avancée concrète de Solana vers la mise en œuvre d’un slashing programmatique formel sur le mainnet. Comme nous le verrons plus loin dans ce rapport, les événements de slashing programmatique sont heureusement rares sur les réseaux blockchain, et les sanctions sont généralement mineures. Toutefois, la simple possibilité que le stake d’un validateur soit automatiquement détruit par le protocole introduit de nouveaux risques que toutes les parties prenantes doivent soigneusement évaluer. De nombreuses questions restent ouvertes quant à la meilleure façon pour Solana d’appliquer le slashing programmatique. Comme pour toute évolution économique, les paramètres et sanctions associés au slashing nécessiteront de vastes discussions au sein de la communauté et devront, à terme, être approuvés par un vote de gouvernance formel.

SIMD liés au slashing

Plusieurs SIMD concernent le déploiement du slashing programmatique sur Solana. Les deux premiers, SIMD-180 et SIMD-204, doivent être mis en service sur le mainnet dans les prochains mois.

Le premier prérequis est SIMD-0180 : utiliser l’adresse du compte de vote comme clé du calendrier des leaders. Ce SIMD remplace, dans le calendrier des leaders, l’adresse d’identité du validateur par l’adresse de son compte de vote. Ce changement est essentiel pour attribuer précisément le slashing, car il établit un lien direct et sans ambiguïté entre les obligations de production de blocs d’un validateur et son stake délégué.

SIMD-0204 : vérification des événements passibles de slashing décrit un nouveau programme de slashing. Celui-ci introduit un mécanisme on-chain qui permet à quiconque de soumettre et d’enregistrer des preuves de comportements passibles de slashing, créant ainsi un registre vérifiable et immuable des fautes commises par les validateurs.

Enfin, SIMD-0212 : slashing décrit la mise en œuvre du slashing dans le protocole Solana. Il s’appuie sur les fondations posées par SIMD-0204 pour appliquer des sanctions aux infractions vérifiées. Cette proposition reste ouverte et fait toujours l’objet de discussions actives.

Détection et attribution des fautes

Le programme de slashing est conçu comme une couche purement observationnelle. Il ne modifie ni les stakes ni les récompenses ; sa seule fonction est de vérifier et d’enregistrer les infractions. Un premier prototype est déjà disponible sur Testnet, avec des soumissions d’exemple (notamment des transactions DuplicateBlockProof) qui montrent comment enregistrer les infractions.

Production de blocs en double

Lors de son déploiement initial, le programme se concentrera sur un seul type de comportement malveillant : la détection des cas de production de blocs en double. Cela se produit lorsqu’un leader soumet au moins deux versions différentes d’un bloc pour le même slot, ce qui constitue une violation claire et objective du consensus. 

En septembre 2022, une panne du réseau avait été provoquée par un validateur ayant produit par erreur des blocs en double à la même hauteur. Le nœud principal du validateur et son nœud de secours s’étaient activés simultanément, utilisant la même identité de nœud tout en proposant des blocs différents.

Ce problème a depuis été corrigé. Aujourd’hui, même lorsqu’un opérateur utilise un nœud de secours actif, le client du validateur intègre des protections qui provoquent son arrêt si plusieurs instances sont détectées. La production de blocs en double serait donc extrêmement improbable sans modification délibérée et malveillante du logiciel du validateur.

La production de blocs en double est un exemple de violation du protocole difficile à détecter en temps réel, mais facile à vérifier a posteriori. Tenter de coordonner une réponse synchrone, où le réseau s’arrêterait afin de confirmer l’observation collective du doublon, introduirait une grande complexité. Il est bien plus pratique de gérer la détection et le slashing rétroactivement.

Les preuves soumises pour les blocs en double comprennent deux shreds contradictoires pour le même slot, tous deux signés par le même validateur. Le programme de slashing vérifie la preuve en s’assurant que les shreds constituent une preuve valide de bloc en double, qu’ils appartiennent au même slot et qu’ils sont correctement signés par le validateur fautif. Cette logique reprend l’approche utilisée par le protocole gossip de Solana pour traiter les preuves de blocs en double lors du processus de sélection de fork.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

Le rapporteur construit une preuve et la stocke dans un compte tampon on-chain, puis soumet au programme de slashing, à l’adresse `S1ashing11111111111111111111111111111111111`, une transaction faisant référence à son compte tampon. Une fois la preuve vérifiée, les résultats sont stockés dans une adresse dérivée de programme (PDA) `report_account` appartenant au programme de slashing afin de pouvoir être consultés ultérieurement. Il devient ainsi facile de créer des tableaux de bord présentant les données liées au slashing, simplement en exécutant un appel getProgramAccounts sur le programme de slashing. Les validateurs peuvent les utiliser pour vérifier si des infractions ont été signalées à leur encontre et prendre les mesures correctives nécessaires.

Anza devrait publier des outils permettant d’observer ces événements, de créer des preuves et de les soumettre on-chain. Il y aura probablement plusieurs implémentations, dont une version intégrée au logiciel du validateur. Il suffit qu’un seul participant honnête signale une infraction au cours d’une époque, car chaque combinaison unique de contrevenant et de slot ne peut être signalée qu’une fois. Le programme vérifie si un signalement existe déjà pour le même slot et le même contrevenant. Si un signalement correspondant est trouvé, la nouvelle soumission est rejetée. Les signalements peuvent être soumis jusqu’à une époque après l’infraction, en fonction du slot où elle s’est produite (soit jusqu’à 432 000 slots plus tard, selon le suivi effectué par la sysvar `Clock`).

Récompenses des lanceurs d’alerte

Une question fréquente dans la conception du slashing consiste à déterminer si les personnes qui signalent des infractions, c’est-à-dire les lanceurs d’alerte, doivent être récompensées. Bien que leur accorder une récompense puisse sembler être un mécanisme d’incitation évident, cette approche présente des difficultés notables.

Sur Solana, où les leaders contrôlent l’inclusion des transactions, une récompense destinée aux lanceurs d’alerte crée un risque de frontrunning. Supposons qu’un validateur soumette une preuve de slashing valide au leader actuel du bloc. Le leader peut simplement copier la preuve, la soumettre lui-même et censurer la transaction d’origine afin de réclamer la récompense sans avoir effectué le travail. Cela compromet le modèle d’incitation et ouvre la voie aux abus.

Ethereum offre une petite récompense aux lanceurs d’alerte : 1/512 du solde effectif du validateur sanctionné. Pour un validateur disposant des 32 ETH complets, cela représente 0,0625 ETH. La récompense est créée sous forme de nouveaux ETH, mais elle est compensée par le montant supérieur brûlé dans le stake du validateur sanctionné. Ce faible montant est intentionnel : il vise à promouvoir l’intégrité et une participation honnête plutôt qu’un comportement opportuniste motivé par le profit.

Infractions de vote

Les futures versions du programme de slashing devraient prendre en charge différents types d’infractions de vote, notamment les infractions de lockout et celles liées aux preuves de changement de fork.

Une infraction de lockout se produit lorsqu’un validateur vote sur deux forks distincts sans attendre suffisamment longtemps l’expiration du lockout de sa tower. Dans TowerBFT, l’algorithme de consensus actuel de Solana, lorsqu’un validateur vote pour un fork donné à un slot précis, il se voit interdire de voter sur des forks concurrents pendant une certaine durée. Si ce validateur vote ensuite pour un autre fork avant l’expiration de sa période de lockout, il enfreint la règle de lockout.

Le bot Votalizer, développé par Michael Vines, cofondateur de Solana, fonctionne actuellement dans le Discord Solana Tech et suit les infractions de lockout à mesure qu’elles se produisent sur le réseau. En pratique, les validateurs commettent rarement de telles infractions involontairement, car cela nécessiterait généralement une modification délibérée du client du validateur. Des protections intégrées garantissent que le client récupère son vote on-chain le plus récent et empêchent les actions qui entraîneraient une infraction de lockout.

Bien que les infractions de lockout soient explicitement citées dans le SIMD sur le slashing et dans la documentation initiale comme exemple d’infraction de vote susceptible d’être traitée par le programme de slashing, la future mise à jour du consensus Alpenglow supprimera Tower BFT, éliminant ainsi le concept de lockout. C’est pourquoi les infractions de vote ne devraient être introduites qu’après le lancement d’Alpenglow.

Les nouvelles infractions de vote propres à Alpenglow, que le programme de slashing pourrait être conçu pour détecter, pourraient inclure des actions telles que la soumission de votes contradictoires pour le même slot, par exemple l’émission simultanée d’un `NotarVote` et d’un `SkipVote`.

Futurs types d’infractions

Le slashing programmatique doit être associé à des cas de comportement fautif vérifiables et sans ambiguïté. Malheureusement, cela complique considérablement l’application de sanctions à des problèmes plus subjectifs ou systémiques, comme le ralentissement délibéré de la production de blocs ou les formes nuisibles d’extraction de MEV.

Sur les réseaux blockchain comparables, les types de comportements entraînant généralement un slashing varient selon le protocole. Voici quelques exemples courants :

• Double signature : production de deux blocs contradictoires à la même hauteur ou au même slot.
• Temps d’arrêt : mise hors ligne et absence de participation au consensus.
• Vote englobant : émission de votes qui contredisent des votes antérieurs afin de manipuler ou de déstabiliser le réseau.

Une nouvelle proposition de slashing, présentée l’an dernier par 0xIchigo de Helius, suggérait de sanctionner les validateurs de la supermajorité qui ne participent pas aux votes de gouvernance formels, afin d’encourager une plus grande implication. Bien que cette approche réponde à l’exigence d’une vérification objective, plusieurs commentateurs ont exprimé leurs inquiétudes. Certains ont souligné que des contraintes juridiques pouvaient empêcher certains validateurs de voter. D’autres ont estimé que le slashing devait être strictement limité aux comportements menaçant directement la sécurité ou l’intégrité du réseau.

Application des sanctions

Une fois que Solana disposera d’un mécanisme on-chain fiable pour signaler et vérifier les infractions passibles de slashing, la priorité suivante sera l’application économique du slashing, avec la définition précise des paramètres et des formules de sanction propres aux différents types d’infractions.

Les règles font toujours l’objet de discussions actives. Le contenu présenté dans cette section reflète les propositions actuelles, destinées à informer, à encourager le dialogue et à évoluer en fonction des retours de la communauté. Ces décisions affectant directement l’économie de l’exploitation d’un validateur Solana, toute modification fera l’objet d’un débat public au sein de la communauté et devra être approuvée par un processus de gouvernance formel.

Lors de la détermination des sanctions de slashing, un principe essentiel consiste à éviter de punir trop sévèrement les erreurs rares et isolées des opérateurs. Dans l’idéal, le système de sanctions devrait, grâce à des protections appropriées, prévoir une marge de tolérance pour les incidents mineurs qui n’affectent pas le consensus, plutôt que d’imposer de lourdes sanctions en cas d’erreur honnête.

La marge actuellement envisagée correspond à la ligne du coefficient de Nakamoto (NC), fixée au niveau de stake du plus petit validateur de la superminorité, soit environ 1 % du stake. 

Selon la fonction proposée, qui détermine la part de chaque délégation soumise au slashing par compte de vote, aucun stake n’est sanctionné si le stake total ayant commis une infraction se situe sous la ligne NC. À l’inverse, si le consensus est menacé, c’est-à-dire si plus d’un tiers du stake total est impliqué dans des infractions, le protocole doit réagir de manière décisive en appliquant un slashing à 100 % du stake fautif.

Pour les cas situés entre ces deux extrêmes, la proposition actuelle introduit une fonction de sanction quadratique à croissance lente. La formule utilisée pour calculer la fraction de stake à sanctionner pour chaque compte de vote est la suivante :

v = compte de vote passible de slashing

TSS = stake total passible de slashing

TS = stake total

Ligne NC = ligne du coefficient de Nakamoto

Selon cette formule, le pourcentage de stake à retirer au validateur fautif peut être calculé comme suit :

• 1,2 % lorsque 4,66 % du stake est en infraction (soit (3 * (0.0466 - 0.01) / 1)²)
• 7,3 % lorsque 10 % du stake est en infraction (soit (3 * (0.1 - 0.01) / 1)²)

Le graphique ci-dessous illustre la courbe proposée avec deux autres options, l’une agressive et l’autre linéaire.

Le stake total passible de slashing (TSS) est calculé à l’aide d’une pondération fondée sur le type d’infraction. Les infractions de vote reçoivent un poids de 1, car elles sont moins graves. Les infractions liées aux blocs en double reçoivent un poids de 10, car elles sont jugées plus graves.

L’un des principaux avantages des sanctions de slashing quadratiques et corrélées, comme celles actuellement proposées, est qu’elles incitent les acteurs exploitant plusieurs validateurs, notamment les plateformes d’échange ou les fournisseurs de staking en tant que service, à maintenir une infrastructure indépendante et de grande qualité afin de limiter le risque de défaillances généralisées et corrélées.

Solutions autres que le slashing traditionnel

Le slashing du stake délégué soulève d’importantes questions d’équité et de responsabilité. Dans le modèle de staking actuel, la grande majorité, voire la totalité, du stake de la plupart des validateurs non privés est déléguée. Ainsi, lorsqu’un slashing se produit, ce sont généralement les délégateurs, et non les opérateurs des validateurs ayant commis l’infraction, qui supportent l’essentiel de la sanction. Même des stakers diligents ayant choisi des validateurs réputés pourraient subir un slashing sans aucune faute de leur part si un validateur agit de manière malveillante ou configure incorrectement son nœud.

Pour corriger ce déséquilibre, plusieurs modèles alternatifs de slashing ont été proposés. Une approche consiste à imposer à tous les validateurs un niveau minimal de stake propre. Les opérateurs ont ainsi un intérêt financier direct et ne peuvent pas répercuter l’intégralité du coût du slashing sur leurs délégateurs. Une version plus stricte consisterait à sanctionner uniquement le stake propre, tout en désactivant automatiquement le stake de tous les délégateurs associés au validateur sanctionné. Les délégateurs perdraient les récompenses, mais conserveraient leur capital, ce qui leur permettrait de réaffecter leur stake à un autre validateur avec un impact minimal à long terme.

Une autre approche consiste à geler les comptes pendant une période définie, durant laquelle ils ne peuvent ni gagner de récompenses, ni changer de propriétaire, ni retirer de fonds. La durée du gel augmenterait selon la gravité de l’infraction. Le protocole pourrait aussi appliquer un slashing aux récompenses futures, réduisant les gains du validateur et de ses délégateurs pendant une période donnée sans toucher au stake principal.

Certains ont proposé de redistribuer le stake sanctionné aux validateurs honnêtes comme forme de renforcement positif, plutôt que de le brûler. Cependant, brûler des SOL produit en pratique un résultat similaire, car cela réduit l’offre totale et augmente ainsi la part relative de chaque détenteur dans la propriété du réseau.

Points à prendre en compte

L’introduction du slashing sur Solana entraîne plusieurs conséquences importantes. Dans cette section, nous examinons deux domaines essentiels : les périodes de cooldown et les risques, besoins d’assurance et charges opérationnelles qui en découlent pour les participants de l’écosystème.

Périodes de cooldown

Le modèle de staking actuel présente une vulnérabilité majeure lorsqu’un validateur commet une infraction passible de slashing, mais retire son stake avant que celle-ci soit observée et signalée. Sans mécanisme permettant de retarder le retrait, des acteurs malveillants pourraient exploiter cette fenêtre temporelle pour échapper à toute sanction.

Une période de cooldown durant laquelle le stake resterait passible de slashing même après sa désactivation atténuerait ce risque. Ce délai doit dépasser le temps maximal nécessaire aux validateurs ou aux observateurs externes pour détecter une infraction et coordonner une réponse de slashing, en particulier dans des conditions hostiles telles que des attaques DDoS au niveau du réseau ou une collusion entre validateurs malveillants. En pratique, les périodes de cooldown devraient donc durer plusieurs jours.

La dépendance de Solana à des instantanés de stake précalculés aggrave ce problème. Plusieurs composants essentiels du protocole, notamment le calendrier des leaders et la règle de sélection de fork, s’appuient sur des valeurs de stake calculées à l’avance. Par conséquent, un stake désactivé ou même entièrement retiré peut encore influencer le consensus.

Par exemple, le calendrier des leaders est établi à partir d’un instantané antérieur du stake, pris une époque à l’avance à la frontière d’époque. Cela crée une fenêtre durant laquelle un validateur pourrait commettre une infraction passible de slashing après avoir déjà désactivé son stake au cours de l’époque précédente et l’avoir retiré au début de l’époque actuelle. Lorsque l’infraction est découverte, il ne reste déjà plus de stake actif à sanctionner.

Une solution consisterait à instaurer une période de cooldown supplémentaire durant laquelle le stake resterait passible de slashing, mais ne compterait plus dans la pondération du stake du protocole. Les stakers qui désactivent leur stake à l’époque N ne pourraient le retirer qu’au début de l’époque N+3. Bien qu’un tel délai améliore la sécurité, il dégrade l’expérience utilisateur en obligeant les stakers à attendre environ ~2 à 4 jours supplémentaires avant de pouvoir retirer entièrement leur stake. Une solution serait de raccourcir les époques afin de conserver des délais réels de retrait proches de la norme actuelle. Toutefois, toute réduction de la durée des époques pourrait avoir des conséquences imprévues sur le protocole et devrait faire l’objet d’une évaluation approfondie.

Risques, assurance et charge opérationnelle

L’introduction du slashing sur Solana a des conséquences pour de nombreux participants de l’écosystème, en particulier ceux qui conservent ou gèrent des SOL stakés, ou qui développent des produits financiers reposant sur ceux-ci. La simple possibilité d’un slashing peut introduire un risque financier, une complexité opérationnelle et des enjeux de réputation, notamment pour les institutions soumises à des obligations fiduciaires ou réglementaires. Ces risques peuvent être atténués grâce à des protections telles que des assurances ou des garanties.

Les parties prenantes potentiellement concernées sont notamment :

• Les protocoles de liquid staking
• Les pools de stake
• Les fournisseurs de staking avec conservation
• Les protocoles de restaking
• Les protocoles DeFi
• Les ETF de staking

Pour certaines de ces entités, un événement de slashing pourrait avoir des conséquences en cascade. Par exemple, les tokens de liquid staking (LST) reposent sur l’hypothèse que les validateurs sous-jacents fonctionnent de manière sûre. Si un validateur subit un slashing, cela pourrait entraîner une forte réévaluation de son LST ou, dans des cas extrêmes, une perte d’ancrage si la confiance dans le validateur auprès duquel les SOL sous-jacents sont stakés s’effondre. Des liquidations pourraient alors survenir si le LST sert de garantie dans un protocole de prêt.

Dans d’autres écosystèmes, les fournisseurs de staking proposent couramment une assurance contre le slashing afin d’atténuer ces risques. Sur Ethereum, par exemple, de nombreux fournisseurs offrent une couverture abordable contre les pertes liées au slashing, avec des niveaux de protection variables selon la formule choisie.

Le risque de slashing introduit également de nouvelles responsabilités opérationnelles tout au long de la chaîne de valeur du staking. Les acteurs concernés comprennent :

• Les opérateurs de services de staking, qui doivent désormais surveiller le comportement des validateurs et atténuer les risques de manière proactive
• Les plateformes de conservation et les plateformes d’échange de cryptomonnaies, qui dépendent d’opérateurs tiers et peuvent devoir contrôler et diversifier leurs ensembles de validateurs
• Les gestionnaires d’actifs institutionnels, qui peuvent rechercher une couverture de leurs propres pertes afin de se protéger contre celles liées au slashing causées par des opérateurs externes

Comparaison avec des réseaux comparables

Cette section examine la mise en œuvre du slashing sur des réseaux de preuve d’enjeu comparables comme Ethereum et Cosmos. Ces réseaux appliquent le slashing programmatique depuis de nombreuses années et fournissent de précieuses données réelles sur la fréquence des événements de slashing et leur impact sur la sécurité du réseau et le comportement des validateurs.

Ethereum

Le protocole de preuve d’enjeu d’Ethereum, introduit avec le lancement de la Beacon Chain en décembre 2020, intègre le slashing comme mécanisme central d’application des règles depuis le premier jour. Ethereum définit quatre infractions précises passibles de slashing, toutes liées à l’équivoque :

• Proposer plusieurs blocs pour le même slot
• Soumettre des attestations contradictoires pour le même point de contrôle cible
• Attester des blocs de tête différents avec les mêmes points de contrôle source et cible
• Créer deux attestations dont l’une « englobe » l’autre en matière de votes source et cible

Chacune de ces infractions entraîne la même structure de sanction. Lorsqu’un validateur subit un slashing, une sanction immédiate correspondant à 1/32 de son solde effectif lui est appliquée, plafonnée à 1 ETH puisque le solde effectif maximal est de 32 ETH. Le validateur est ensuite exclu de force de l’ensemble actif et placé dans la file de sortie pendant environ 36 jours.

Pendant cette période, le validateur est inactif et ne peut pas retirer de fonds. Il continue de perdre les récompenses qu’il aurait perçues s’il était resté actif, ce qui représente un coût d’opportunité constant. Après 18 jours, une sanction de corrélation supplémentaire est appliquée. Elle est conçue pour augmenter proportionnellement au nombre de validateurs sanctionnés sur une période de 36 jours. Si seuls quelques validateurs subissent un slashing, la sanction est mineure. Toutefois, lors d’événements de slashing massifs, qu’ils résultent d’un comportement fautif coordonné ou de défaillances d’infrastructures communes, les sanctions augmentent fortement et pourraient, dans le pire des cas, entraîner la perte de la quasi-totalité du solde staké du validateur.

Malgré son rôle central dans le protocole Ethereum, le slashing est extrêmement rare en pratique. En mai 2025, seuls 484 validateurs, soit moins de 0,05 % de l’ensemble total, avaient subi un slashing au cours de 131 incidents. Ces incidents provenaient souvent d’une seule erreur affectant plusieurs validateurs et résultaient généralement de fautes d’opérateurs ou de bugs logiciels, et non d’une intention malveillante.

Le plus grand événement de slashing s’est produit en novembre 2023, lorsque Bitcoin Suisse a vu 100 validateurs sanctionnés pour des infractions liées à l’inactivité, chacun perdant 1 ETH.

À ce jour, aucun incident de slashing sur Ethereum n’a menacé l’intégrité globale du protocole. Cela laisse penser que, si le slashing constitue un moyen de dissuasion essentiel, son application réelle reste rare et que l’écosystème des validateurs a largement intégré les comportements nécessaires pour éviter ces sanctions.

Cosmos

Cosmos et les chaînes basées sur Cosmos SDK, comme Cosmos Hub, intègrent le slashing comme mécanisme de sécurité ciblant deux fautes principales : la double signature et les périodes d’arrêt prolongées. Ces règles de slashing permettent d’assurer à la fois la sécurité et la disponibilité du protocole.

Un validateur qui signe deux blocs différents à la même hauteur est immédiatement sanctionné. Tout participant peut soumettre on-chain une preuve de l’infraction. Une fois celle-ci vérifiée, 5 % des tokens stakés du validateur sont automatiquement sanctionnés, et celui-ci passe à l’état « tombstoned », ce qui signifie qu’il est définitivement exclu de l’ensemble des validateurs actifs et ne peut plus le réintégrer. Après ce passage à l’état « tombstoned », le validateur et ses délégateurs doivent attendre la fin de la période de déliaison avant de pouvoir redéléguer leur stake. Un opérateur de validateur dans cet état peut redémarrer avec une nouvelle clé, mais il doit reconstruire sa réputation et ses délégations à partir de zéro.

Cosmos garantit également la disponibilité au moyen d’un slashing automatique en cas d’arrêt prolongé. Si un validateur signe moins de 5 % des 10 000 derniers blocs, il est considéré comme inactif et sanctionné à hauteur de 0,01 % de son stake. Bien que mineure en comparaison, cette sanction est stricte et non négociable, afin de garantir que les validateurs restent disponibles et participent de manière fiable au consensus.

Fait intéressant, certains validateurs choisissent d’accepter cette sanction mineure comme coût d’un arrêt volontaire de leurs opérations, jugeant la perte négligeable.

Bien que les réseaux Cosmos SDK partagent des paramètres de slashing par défaut, chaque chaîne peut modifier ou étendre ces règles pour refléter ses propres hypothèses de sécurité et modèles de risque. Cette flexibilité permet à chaque réseau d’ajuster son système de slashing selon la taille de son ensemble de validateurs, ses objectifs de décentralisation ou sa tolérance aux pannes attendue. L’activité de slashing sur 57 mainnets basés sur Cosmos SDK offre une vue plus large de l’application des sanctions dans l’écosystème :

• 12 143 slashings liés à des périodes d’arrêt
• 111 slashings pour double signature
• 326 autres infractions
• 12 580 incidents de slashing au total

Ces chiffres montrent que, si la double signature est rare et lourdement sanctionnée, le slashing lié aux périodes d’arrêt est plus fréquent et principalement considéré comme un coût opérationnel courant. 

Conclusion

Le slashing reste l’un des sujets les plus débattus et chargés d’émotion du secteur de la blockchain. Dès que de nouvelles formes de comportement fautif des validateurs ou de désalignement des incitations apparaissent, les appels au slashing suivent rapidement. La raison est facile à comprendre : en apparence, le slashing semble être un puissant moyen de dissuasion, offrant un mécanisme direct et on-chain pour punir les acteurs malveillants et préserver l’intégrité du réseau.

Cependant, comme l’illustre cet article, le slashing programmatique est loin d’être une solution miracle aux comportements fautifs. Son efficacité dépend du caractère à la fois incontestable et démontrable des infractions, des conditions qui ne sont pas toujours faciles à remplir dans des situations réelles et complexes. Appliquer un slashing lorsque les preuves sont incertaines ou sujettes à interprétation risque de punir des acteurs honnêtes, d’ébranler la confiance et de causer davantage de tort que les infractions visées.

On peut considérer que le principal apport des formes automatisées de slashing à un réseau réside dans leur impact psychologique sur les parties prenantes. La simple possibilité d’une perte économique en cas d’infraction, aussi rare soit-elle, peut suffire à inciter les stakers réticents au risque à répartir leurs délégations entre plusieurs validateurs, tout en poussant les opérateurs à investir dans des infrastructures diversifiées et indépendantes.

Ressources complémentaires

• Le slashing : panacée ou boîte de Pandore ? - Tim Roughgarden, conférence Accelerate
• Les limites économiques du consensus sans permission - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Disponibilité responsable - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini