Aller au contenu
Financial Context Wiki

Slashing

Slashing est une réduction du participation pouvant être coupée définie par le protocole après un comportement répréhensible imputable à un validateur ou opérateur. Analysez l'infraction exacte, les preuves, la base de participation, la formule de pénalité, le calendrier, la délégation et l'exposition au retrait au lieu de supposer que chaque devoir manqué ou pourcentage indiqué a le même effet.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Le slashing est une réduction de stake définie par le protocole après une faute attribuable à un validateur, un opérateur ou un autre participant engagé. Une règle complète précise la faute passible de slashing, la preuve ou le compteur qui l’établit, le stake exposé, le calcul de la pénalité et sa période d’application. Le slashing peut s’accompagner d’une suspension, d’une désactivation, d’une sortie forcée, d’une perte de récompenses ou d’une prime de signalement, mais il s’agit de transitions d’état distinctes sauf si le protocole les regroupe explicitement.

Il n’existe pas de règle universelle pour les sanctions. Ethereum sanctionne les propositions et attestations en conflit mais traite séparément les manquements ordinaires et la fuite d’inactivité. Une chaîne Cosmos SDK peut configurer à la fois les sanctions pour double signature et pour temps d’arrêt. Polkadot distingue les infractions, les sanctions, la désactivation et les changements de réputation. Un service de restaking peut ajouter un autre engagement passible de sanction dont les contrats, l’ensemble des opérateurs et la fenêtre de retrait diffèrent de la chaîne de base. Consultez les règles actives pour le réseau, la branche, l’exécution ou le déploiement de contrat exact.

Slashing prouve un prédicat de protocole, et non une intention malveillante. Une clé de validateur dupliquée, une bascule de type split-brain, une sauvegarde restaurée, une course de signataire à distance ou une base de données de protection contre la punition corrompue peuvent produire deux signatures valides qui entrent en conflit même lorsque l’opérateur n’avait pas l’intention de mener une attaque. Inversement, une mauvaise disponibilité n’est pas automatiquement punissable sur chaque réseau, et un message invalide ou en retard n’est pas punissable à moins qu’il ne satisfasse à une règle d’infraction définie.

Gardez ces concepts séparés :

  • Récompense manquée ou pénalité ordinaire : une obligation était absente, en retard ou incorrecte, mais aucune infraction punissable n’a été prouvée.
  • Mécanisme d’inactivité : Les pénalités augmentent ou le poids de vote change pendant une non-finalité prolongée ; la fuite d’inactivité de Ethereum n’entraîne pas elle-même de réduction.
  • Slashing : une transition d’état reconnue sur la chaîne ou par le protocole réduit la mise attachée à une infraction prouvée.
  • Emprisonnement, désactivation, expulsion ou mise hors service : La participation est suspendue ou terminée ; l’action peut se produire avec ou sans réduction supplémentaire de mise.
  • Pénalité sociale ou contractuelle : La gouvernance , un contrat de service, une police d’assurance ou un fork coordonné impose une conséquence en dehors de la fonction de réduction automatique du protocole de base.

La partie opérant la clé n’est pas nécessairement la seule partie à subir une perte. Les règles du protocole et les contrats de service peuvent exposer la mise personnelle, la mise déléguée, la mise du nominateur, les allocations réinvesties, les retraits en attente ou les réclamations groupées. L’assurance et le remboursement sont des promesses de crédit distinctes, et non des annulations de l’événement du protocole.

Comment analyser le slashing

1. Fixer le jeu de règles et le point d’observation

Enregistrez le network, chain ID, le fork version actif ou le temps d’exécution, le bloc ou l’époque, la version client/spécification et les adresses de contrat pertinentes. Séparez les règles de consensus des conditions d’un fournisseur de staking et de l’interface utilisateur. Une requête de paramètre actuelle et un état finalisé constituent des preuves plus solides qu’une page d’aide non datée.

2. Écrivez le motif exact de l’infraction

Nommez la règle en termes exécutables : deux propositions distinctes par un même validateur pour le même créneau, un double vote, un surround vote, un vote invalide reconnu par le protocole, ou missed > max_missed dans une fenêtre de vivacité. Ne remplacez pas le prédicat par des étiquettes telles que « mauvais comportement », « hors ligne » ou « attaque ».

3. Valider l’attribution et les éléments de preuve

Vérifiez l’identité du validateur ou de l’opérateur, les signatures, signing root, la séparation de domaine, le contexte du fork, les hauteurs ou époques, et l’âge des preuves. Pour les infractions de messages conflictuels, conservez les deux objets signés. Pour les règles de vivacité, reproduisez le compteur et la fenêtre du protocole. L’inclusion de preuves peut se produire après l’infraction, donc distinguez infraction time, detection time et application time.

4. Identifiez chaque solde exposé

Déterminez si la base est effective balance, mise en jeu liée à la hauteur de l’infraction, mise en jeu actuelle, mise en jeu personnelle, mise en jeu déléguée, allocation de slot de validateur, ou mise en jeu attribuée à un operator set. Vérifiez les limites maximales, les planchers, les incréments d’arrondi, la dénomination, les pénalités antérieures, les réaffectations et si les retraits en attente restent susceptibles de sanction.

5. Recalculer chaque composante de la pénalité

Divisez le résultat en initial penalty, correlation penalty, pénalités pour devoirs continus, récompenses perdues, effets de sortie forcée, et récompenses pour signalement ou lanceur d’alerte. Une règle simple et fixe peut utiliser slash_amount = slashable_stake * slash_fraction ; de nombreux protocoles en direct utilisent plutôt des fonctions dépendant de l’état. N’appliquez jamais un pourcentage de titre au solde du portefeuille sans confirmer la base.

6. Retracer toute la chronologie et identifier qui supporte la perte

Infraction de traçage, propagation des preuves, inclusion, comptabilisation des slashs, période de prison ou de désactivation, fenêtre d’appel ou d’annulation, sortie, désengagement et achèvement du retrait. Ensuite, répartir la perte entre l’opérateur, les délégateurs, les nominateurs, les détenteurs de jetons de pool et les réinvestisseurs selon le protocole et le contrat de service. Inclure les effets sur le prix du jeton et la liquidité séparément des unités brûlées.

7. Vérifiez les contrôles et réconciliez l’état

Passez en revue les éléments clés de la garde, l’exclusivité des signataires, la durabilité slashing protection database, le fencing de basculement, la restauration des sauvegardes, la surveillance de l’horloge et du réseau, la diversité des clients et les procédures d’incidents. Recalculez l’événement à partir de l’état finalisé, des paramètres, des preuves et des deltas de solde ; réconciliez-le avec les étiquettes de l’explorateur, les déclarations des fournisseurs, les écritures comptables et toute indemnité d’assurance sans considérer qu’une source est concluante.

Exemples travaillés

Signatures conflictuelles de style Ethereum

Supposons que le validateur V signe l’en-tête de bloc A et un en-tête différent B pour slot = 8, avec des signatures valides dans le même contexte de fork applicable. La paire satisfait la forme de double-lancement du proposant Ethereum ; une proposition manquée au créneau 9 ne la satisfait pas. Pour les attestations, prenons A = (source = 120, target = 125) et B = (source = 118, target = 127). Comme B entoure A, la paire a la forme de vote entourant. Les étiquettes seules sont insuffisantes : les données réellement signées, les domaines, l’indice du validateur et les vérifications de la période punissable doivent réussir selon la spécification active.

Cet exemple montre également pourquoi l’intention n’est pas une entrée. Deux machines utilisant la même clé peuvent créer la preuve. Une capture d’écran disant “double sign” ne peut pas ; le protocole nécessite des objets signés valides en conflit.

Calcul de la perte de participation au prorata

Considérez un protocole illustratif avec des jetons slashable_stake = 12,500 et un slash_fraction = 0.015 fixe. La perte du protocole est :

12,500 * 0.015 = 187.5 tokens.

Si la règle prélève toutes les mises de soutien au prorata, les jetons 2,500 de l’auto-mise de l’opérateur perdent 37.5, tandis que les jetons délégués 10,000 perdent 150. Si le contrat de service rembourse les délégateurs mais pas l’opérateur, ce paiement constitue un créance distincte et une exposition au crédit. Cela ne modifie pas la pénalité sur la chaîne, et cette répartition ne doit pas être transférée à un protocole qui protège les délégateurs ou utilise une base de mise différente.

Fenêtre de vivacité de style Cosmos

Supposons qu’une chaîne basée sur Cosmos SDK ait interrogé les paramètres window = 1,000 et min_signed = 0.95. Ses manquements maximum autorisés sont :

max_missed = 1,000 - (0.95 * 1,000) = 50.

Si la règle active se déclenche lorsque missed > max_missed, exactement 50 manque ne franchit pas le seuil, tandis que 51 le fait. La fraction de slash résultante, la durée de la prison, la réinitialisation du compteur et la possibilité de libération proviennent des paramètres actifs et de la version du module de cette chaîne. Ceci est un exemple de chaîne configurée, et non une règle universelle de preuve d’enjeu ni le traitement de Ethereum en cas de temps d’arrêt.

Formule d’infraction corrélée

La documentation révisée de Polkadot donne la fraction d’équivoque min((3 * x / n)^2, 1), où x est le nombre de contrevenants et n le nombre de validateurs actifs. Avec x = 5 et n = 100 :

min((3 * 5 / 100)^2, 1) = 0.0225 = 2.25%.

Appliqué aux unités 40,000 de participation dans le créneau du validateur, c’est-à-dire 900 unités. Avec x = 20, la même formule donne 36%, et non quatre fois 2.25%. Cela démontre un risque de corrélation ; cela n’autorise pas à utiliser cette formule sur Ethereum, une chaîne Cosmos, une parachaine ou un autre environnement d’exécution Polkadot sans vérifier les règles en vigueur.

Risques et échecs de révision

  • Mauvais ensemble de règles : une autre chaîne, fourche, runtime, testnet ou déploiement de contrat peut avoir des infractions et des pénalités différentes.
  • Confusion entre infraction et sanction : Les récompenses manquées, les pénalités d’inactivité, l’emprisonnement, la désactivation, l’expulsion et la réduction de ne sont pas des termes interchangeables.
  • Paramètres obsolètes : La gouvernance et les mises à niveau de peuvent modifier les fenêtres, les fractions, les limites, les délais et les soldes protégés.
  • Confusion de domaine : Les signatures provenant de contextes de fork ou de domaine différents peuvent ne pas constituer des preuves punissables.
  • Preuve invalide : Les preuves mal formées, en double, expirées, mal indexées ou non authentifiées peuvent être rejetées.
  • Découverte tardive : Les preuves peuvent arriver après la redélégation ou l’initiation de la sortie, donc les états de l’infraction et de l’application diffèrent.
  • Capture d’écran de mise incorrecte : Le solde actuel de peut ne pas être le solde, le pouvoir de vote ou la participation effective utilisée par la règle.
  • Amplification de la corrélation : un client partagé, cloud, signataire ou procédure peut transformer une faute en une pénalité de masse dépendant de l’état.
  • Clés dupliquées : a copié des magasins de clés et des sauvegardes actives simultanées peuvent générer des signatures conflictuelles.
  • Échec du signataire à distance : Les nouvelles tentatives , les verrous obsolètes, les bases de données inconsistantes ou les reconnaissances ambiguës peuvent provoquer une double signature.
  • Basculement en cas de partition de cerveau : deux sites peuvent tous deux croire qu’ils sont principaux à moins que le basculement ne soit sécurisé cryptographiquement.
  • Perte de la base de données de protection : Restaurer les clés sans un historique complet de signature peut rendre un validateur apparemment propre dangereux.
  • Concentration de l’opérateur : de nombreux validateurs sous un même plan de contrôle partagent l’exposition opérationnelle et de corrélation.
  • Transmission de délégation : Les délégateurs ou les nominateurs peuvent subir des pertes causées par un opérateur qu’ils ne peuvent pas contrôler directement.
  • Chevauchement de restaking : un actif peut soutenir plusieurs engagements avec des autorités de sanction distinctes et des règles d’allocation.
  • Exposition au sevrage : le déliement ou le retrait en file d’attente peut rester susceptible de sanctions pour des infractions antérieures ou nouvellement attribuables.
  • Incertitude de gouvernance : Les appels , les périodes d’annulation, les mises à niveau ou la récupération sociale peuvent modifier le calendrier mais ne sont pas des remèdes garantis.
  • Comptabilité et arrondi : Les incréments de solde effectif , les conversions d’actions, les plafonds et les décimales de jetons peuvent annuler la multiplication du solde du portefeuille.
  • Lacunes d’observabilité : Les étiquettes de l’explorateur peuvent omettre la paire de preuves, l’instantané des paramètres, les délégations affectées ou les pénalités ultérieures.
  • Risque contractuel et de contrepartie : Les promesses de la piscine , de garde, d’assurance et de remboursement peuvent échouer indépendamment de la précision du consensus.

Idées reçues

Chaque validateur hors ligne est-il pénalisé ?

Non. Ethereum applique des pénalités pour absence de service et inactivité mais ne classe pas les temps d’arrêt ordinaires comme une infraction punissable. Les chaînes Cosmos SDK peuvent configurer la punition pour temps d’arrêt. D’autres protocoles peuvent désactiver, mettre en prison, réduire les récompenses, ou ne rien faire. Interrogez la règle exacte au lieu de généraliser à partir d’un seul réseau.

La réduction nécessite-t-elle une preuve d’intention malveillante ?

Habituellement, la règle automatique évalue les messages signés, les preuves, les contre-preuves et l’état, pas le motif. Un accident opérationnel peut satisfaire le même prédicat qu’une équivoque délibérée. L’intention peut être importante pour la gouvernance, l’assurance, les litiges ou un contrat de service, mais pas pour la transition d’état déterministe.

La perte maximale correspond-elle au pourcentage de réduction annoncé ?

Pas nécessairement. Le pourcentage peut s’appliquer à la mise effective, liée, allouée, déléguée ou historique ; la corrélation et les pénalités continues peuvent augmenter la perte ; l’exclusion forcée entraîne la perte des récompenses futures ; et le prix du token ou les réductions de staking liquide peuvent modifier la valeur économique. Inversement, un plafond ou un solde protégé peut réduire la base facturée.

Le lancement d’une sortie met-il immédiatement fin à l’exposition au slashing ?

Aucune règle universelle ne le dit. Les preuves peuvent être retardées, le déliement existe en partie pour préserver la responsabilité, et certains retraits de restaking restent susceptibles de pénalité pendant une file d’attente. Vérifiez le dernier moment pénalisable pour chaque engagement, pas seulement la transaction qui a demandé la sortie.

La délégation, l’assurance ou la récupération sociale éliminent-elles le risque de slashing ?

Non. Ils redistribuent ou promettent de rembourser une perte selon des règles supplémentaires. La couverture peut exclure des fautes corrélées, expirer, plafonner les réclamations, dépendre de la gouvernance ou créer un risque de contrepartie. La réduction du protocole reste un événement distinct qui doit être concilié indépendamment.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...