Slashing des validateurs : comment les stakers perdent de l'argent

Le slashing est une pénalité qui détruit une partie des fonds stakés d'un validateur pour un comportement nuisible prouvable — principalement la double signature (equivocation) ou les votes englobants (surround votes). Il existe pour rendre coûteuse toute attaque contre la chaîne. Une indisponibilité ordinaire n'est pas du slashing ; passer hors ligne entraîne plutôt de petites pénalités d'inactivité.

C'est la réponse courte. Le reste de cette page sépare les deux façons très différentes dont un staker perd de l'argent, et montre où se situe le vrai risque.

---

Slashing contre indisponibilité : deux pénalités différentes

Les chaînes proof-of-stake punissent les validateurs selon deux catégories, et les confondre est le malentendu le plus courant.

Le slashing est réservé aux infractions que le protocole peut prouver cryptographiquement comme des attaques contre le consensus. Un validateur slashé voit ses fonds brûlés, est expulsé de force de l'ensemble actif et ne peut pas revenir. Sur Ethereum, les infractions slashables sont :

• Double proposition (double-proposing) — signer deux blocs différents pour le même slot.
• Double attestation (equivocation) — signer deux attestations contradictoires pour la même cible.
• Votes englobants (surround votes) — émettre une attestation dont la portée du vote englobe ou est englobée par un vote précédent, un schéma que seul un validateur malhonnête ou mal configuré produit.

Les trois reviennent à ce que le validateur dise deux choses contradictoires à la fois sur l'historique de la chaîne. C'est exactement ce que ferait un attaquant cherchant à forker ou à inverser la chaîne, donc le protocole le traite comme hostile quelle que soit l'intention.

L'indisponibilité (downtime) n'est pas du slashing. Si votre validateur est hors ligne et manque des attestations, vous subissez une petite fuite d'inactivité (inactivity leak) — vous ne gagnez pas de récompenses et perdez un montant infime, à peu près égal à ce que vous auriez gagné. Dans des conditions normales, cela se mesure en fractions de pour cent par jour. Cela ne dégénère en pertes sérieuses que lors d'un événement d'inactivity leak, quand la chaîne ne finalise pas pendant longtemps et que les validateurs hors ligne sont drainés pour restaurer une supermajorité. C'est une urgence rare à l'échelle de la chaîne, pas une pénalité de routine.

---

La pénalité de corrélation

Le slashing n'est pas une amende fixe. Le montant s'échelonne selon le nombre de validateurs slashés à peu près en même temps, via la pénalité de corrélation (sur Ethereum : le slashing proportionnel).

La logique : un seul validateur commettant une equivocation est probablement une erreur ou un acteur malveillant isolé et cause peu de dégâts. Des milliers le faisant ensemble ressemblent à une attaque coordonnée. Donc plus de stake est slashé dans la même fenêtre, plus la pénalité que paie chaque contrevenant est grande — potentiellement l'intégralité de son solde si la part corrélée est suffisamment élevée.

Cette conception décourage directement la concentration. Faire tourner de nombreux validateurs sur une infrastructure identique signifie qu'un seul bug peut tous les slasher simultanément, déclenchant le multiplicateur de corrélation. C'est une incitation délibérée à répartir le stake sur des clients, des machines et des opérateurs indépendants.

---

Événements, causes et gravité

L'écart entre la première ligne et le reste est tout l'enjeu : l'indisponibilité vous coûte des récompenses, le slashing vous coûte le capital.

---

Qui est à risque et comment l'éviter

L'écrasante majorité des slashings réels a une cause racine : les mêmes clés de validateur tournant sur deux machines à la fois. Quelqu'un configure un nœud de secours ou de bascule avec les mêmes clés, les deux passent en ligne, et les deux instances signent des messages contradictoires — un slashing d'equivocation instantané. Il n'y a pas d'attaque ici, juste une mauvaise configuration que le protocole ne peut distinguer d'une attaque.

Si vous faites tourner des validateurs vous-même, les défenses pratiques sont :

• Ne faites jamais tourner des clés identiques sur deux nœuds simultanément. Ne construisez pas un « hot spare » partageant les clés. Si vous migrez vers un nouveau matériel, arrêtez complètement l'ancienne instance et confirmez qu'elle est morte avant de démarrer la nouvelle.
• Utilisez la base de données de protection contre le slashing. Les clients tiennent un registre local de chaque message signé et refusent de signer tout ce qui serait slashable. Importez et transférez toujours cette base lors du déplacement de configurations ; ne repartez jamais de zéro avec des clés existantes.
• Diversifiez les clients et l'infrastructure pour qu'un seul bug de client ne slashe pas toute votre flotte et ne déclenche pas la pénalité de corrélation.
• Comprenez le compromis de la délégation. Avec un pool de staking ou un fournisseur de liquid staking, c'est l'opérateur qui fait tourner les validateurs. Le risque de slashing repose sur lui, pas directement sur vous — mais vous héritez de sa compétence et de sa concentration.

---

Limites honnêtes

Il n'existe pas de version sans risque du staking ; il n'y a qu'un choix du risque que vous portez.

Le solo staking vous donne des récompenses complètes et un contrôle total, ainsi qu'une responsabilité totale. Un événement d'indisponibilité vous coûte des récompenses ; une erreur de clés-sur-deux-machines vous coûte du capital par slashing. Les modes de défaillance sont opérationnels et largement entre vos mains.

Le staking délégué ou liquide transfère cette charge opérationnelle à un fournisseur. Vous n'êtes plus celui qui peut doubler la signature. À la place, vous assumez le risque de fournisseur et de contrepartie : l'opérateur peut toujours être slashé (et vous répercuter les pertes), la plateforme peut faire faillite, les arrangements de garde peuvent se rompre, et un token de liquid staking peut décrocher (depeg) du stake sous-jacent. Vous avez échangé un risque que vous contrôlez contre un que vous ne contrôlez pas.

Aucun n'est strictement plus sûr. Le slashing est un petit risque de queue évitable pour un opérateur solo prudent, et un risque délégué que vous ne pouvez pas empêcher personnellement en utilisant un pool.

---

FAQ

Qu'est-ce qui fait slasher un validateur ? Des violations de consensus prouvables : proposer deux blocs pour le même slot, ou faire des attestations contradictoires (doubles votes et votes englobants). En pratique, elles proviennent presque toujours de clés dupliquées tournant sur deux machines, pas d'attaques délibérées.

Vais-je être slashé si je passe hors ligne ? Non. L'indisponibilité n'est pas une infraction slashable. Vous perdez des récompenses et payez une petite fuite d'inactivité à peu près égale à ce que vous auriez gagné. Les pertes ne deviennent sérieuses que lors d'une non-finalisation prolongée, ce qui est rare.

Combien peut coûter un slashing ? Il commence par un brûlage initial et une expulsion forcée, puis ajoute une pénalité de corrélation basée sur la quantité de stake slashée en même temps que le vôtre. Isolée, la perte est modérée ; dans un slashing de masse corrélé, elle peut monter jusqu'à l'intégralité de votre solde staké.

Le staking via un pool me protège-t-il du slashing ? Il déplace le risque opérationnel vers l'opérateur plutôt que de l'éliminer. Vous ne doublerez pas la signature personnellement, mais l'opérateur peut toujours être slashé et vous répercuter la perte, et en échange vous assumez un risque de fournisseur et de contrepartie.

---

Avant même de staker, assurez-vous de comprendre le mécanisme que vous sécurisez — lisez ce qu'est le staking et comment le proof-of-stake se compare au proof-of-work. Si vous préférez ne pas faire tourner de validateur, pesez les compromis du liquid staking.