Skip to main content

Qu'est-ce que le slashing

Remarque : Ce document est une traduction automatique de la version originale anglaise.

Qu'est-ce que le slashing

Le slashing est un mécanisme de pénalité dans les réseaux blockchain Proof of Stake (PoS) qui punit les validateurs pour des comportements menaçant la sécurité ou l'intégrité du réseau. Lorsqu'un validateur est slashé, une partie de ses tokens stakés est détruite (brûlée) ou redistribuée, et le validateur est généralement retiré de l'ensemble actif — temporairement ou définitivement.

Le slashing existe parce que les réseaux PoS s'appuient sur des incitations économiques plutôt que sur du travail de calcul pour sécuriser la chaîne. Les validateurs verrouillent des tokens comme garantie ; le slashing garantit que cette garantie est réellement en jeu si le validateur se comporte mal.

En bref : le slashing est la punition économique de l'inconduite des validateurs dans les systèmes PoS — et pour les projets crypto IA impliquant du staking ou une participation de validateurs, il représente un risque financier concret lié à la fiabilité de l'infrastructure.

Comment fonctionne le slashing

Infractions déclenchant le slashing

Toutes les erreurs de validateur ne mènent pas au slashing. Les protocoles distinguent généralement les pénalités mineures (pour être hors ligne ou lent) et les infractions de niveau slashing (pour des comportements pouvant compromettre le consensus du réseau). Les infractions slashables les plus courantes sont :

  • La double signature (équivocation) — un validateur signe deux blocs différents pour le même slot ou la même hauteur, essayant effectivement de créer un fork. C'est l'infraction la plus grave car elle menace directement l'intégrité du consensus.
  • Le vote enveloppant (surround voting) — un validateur émet des votes d'attestation qui se contredisent d'une manière qui pourrait permettre une réorganisation de la chaîne. Ceci est spécifique au consensus Casper FFG d'Ethereum.
  • L'indisponibilité prolongée — sur certains réseaux, des périodes hors ligne prolongées entraînent des pénalités progressives pouvant aller jusqu'au slashing. Sur Ethereum, être hors ligne entraîne des pénalités de « fuite d'inactivité » plutôt qu'un slashing formel, mais d'autres chaînes PoS peuvent traiter l'indisponibilité prolongée comme une infraction slashable.

Le processus de pénalité

Lorsqu'un comportement slashable est détecté, le protocole applique les conséquences automatiquement via la logique on-chain :

  1. Détection — d'autres validateurs ou des contrats de surveillance identifient les signatures conflictuelles ou la violation du protocole.
  2. Soumission de preuve — la preuve de l'inconduite (par exemple, deux messages signés contradictoires) est soumise on-chain, souvent par un « lanceur d'alerte » qui peut recevoir une récompense.
  3. Application de la pénalité — le protocole brûle un pourcentage défini de la mise du validateur fautif. Le montant exact varie selon le réseau et la gravité de l'infraction. Sur Ethereum, la pénalité minimale de slashing est de 1/32 du solde effectif du validateur, avec des « pénalités de corrélation » supplémentaires si de nombreux validateurs sont slashés simultanément.
  4. Éjection — le validateur slashé est retiré de l'ensemble actif et entre dans une file d'attente de retrait. Sur certains réseaux, le validateur ne peut pas revenir ; sur d'autres, il peut réintégrer après une période de refroidissement et un nouveau staking.

Pénalités de corrélation

Certains protocoles, notamment Ethereum, imposent des pénalités de corrélation qui augmentent avec le nombre de validateurs slashés dans la même fenêtre temporelle. Si un seul validateur est slashé isolément, la pénalité est relativement faible. Mais si un grand nombre de validateurs sont slashés ensemble — suggérant une attaque coordonnée ou un bug logiciel répandu — les pénalités augmentent considérablement, jusqu'à la totalité de la mise. Cette conception garantit que les défaillances corrélées (plus dangereuses pour le réseau) sont punies plus sévèrement que les incidents isolés.

Pourquoi le slashing est important pour les projets crypto IA

Projets IA adjacents aux validateurs. Certains projets crypto IA impliquent du staking ou des rôles de type validateur : les participants stakent des tokens et fournissent des services de calcul IA, d'étiquetage de données ou de vérification de modèles. Si ces systèmes intègrent le slashing pour des sorties de mauvaise qualité ou un comportement malhonnête, les participants font face à un risque économique réel — pas seulement un coût d'opportunité.

Risque pour le capital staké. Tout projet qui encourage les utilisateurs à staker des tokens sur un réseau PoS expose ces utilisateurs au risque de slashing. Les outils d'optimisation de staking pilotés par l'IA ou les protocoles de liquid staking doivent tenir compte des scénarios de slashing dans leurs modèles de risque. Un agent IA gérant des positions stakées qui ignore le risque de slashing est incomplet.

Application de la qualité. Dans les réseaux IA décentralisés (places de marché de calcul, réseaux d'inférence, couches de validation de données), des mécanismes de type slashing peuvent faire respecter la qualité : les nœuds qui renvoient des résultats d'inférence incorrects, soumettent des données corrompues ou n'accomplissent pas les tâches assignées peuvent perdre leur garantie stakée. Cela adapte le concept de slashing blockchain à des contextes spécifiques à l'IA.

Où cela apparaît dans les fiches projet DecAIHub

  • Consensus — les projets sur des chaînes PoS (Ethereum, Solana, Avalanche, réseaux basés sur Cosmos et autres) héritent du slashing comme partie du mécanisme de consensus. Le champ consensus d'une fiche projet indique indirectement si le slashing s'applique au réseau sous-jacent.
  • Staking — les projets qui impliquent du staking (sur leur propre réseau ou sur la chaîne principale sur laquelle ils se déploient) exposent les stakers au risque de slashing. Le modèle de staking décrit dans la fiche projet peut faire référence aux conditions de slashing.
  • Token model — pour les projets avec des architectures basées sur des validateurs, le modèle de token peut inclure le slashing comme partie de la conception des incitations : les validateurs stakent les tokens du projet et risquent le slashing en cas d'inconduite.
  • Type — les projets L1 qui implémentent leur propre consensus PoS définissent directement les règles de slashing. Les projets L2 et dApp héritent des conditions de slashing de leur chaîne principale.

Ce que le slashing seul ne prouve pas

  • La sécurité — la présence de slashing ne garantit pas qu'un réseau est sécurisé. Le slashing dissuade les acteurs économiques rationnels, mais il n'empêche pas les bugs, l'ingénierie sociale ou les attaques de gouvernance. Un validateur peut être slashé à cause d'un bug logiciel plutôt que d'une intention malveillante.
  • La décentralisation — le slashing est un mécanisme, pas une mesure de décentralisation. Un réseau avec du slashing peut toujours avoir un ensemble de validateurs restreint et concentré.
  • La qualité de l'IA — adapter le slashing pour pénaliser de mauvaises sorties IA est un patron de conception valide, mais son efficacité dépend de la capacité à vérifier objectivement la qualité des sorties on-chain. Pour les tâches IA complexes où la qualité est subjective, les critères de slashing peuvent être difficiles à définir équitablement.
  • La valeur du token — le slashing affecte l'offre de tokens (les tokens brûlés réduisent l'offre en circulation), mais cet effet mécanique ne détermine pas si le token a une valeur ou une nécessité fondamentale.

Questions fréquentes

Le slashing peut-il arriver par accident ?

Oui. La cause la plus courante de slashing accidentel est l'exécution des mêmes clés de validateur sur deux machines différentes simultanément (une erreur de configuration qui entraîne une double signature). Des bugs logiciels dans les clients de validateurs ont également causé des événements de slashing. C'est pourquoi les opérateurs de validateurs prennent au sérieux la redondance et la gestion des clés — et pourquoi la diversité des clients (exécuter différentes implémentations logicielles) est importante pour le réseau dans son ensemble.

Tous les réseaux PoS ont-ils du slashing ?

La plupart des réseaux PoS implémentent une forme de slashing, mais la sévérité et les conditions varient. Ethereum a un mécanisme formel de slashing pour la double signature et le surround voting. Les chaînes basées sur Cosmos slashent pour la double signature et l'indisponibilité prolongée. Certains réseaux utilisent des pénalités plus douces (comme la mise « en prison » temporaire d'un validateur) plutôt que la destruction de la mise. Les règles spécifiques de slashing font partie de la conception de chaque protocole et sont documentées dans ses spécifications.

Références externes

Voir aussi