Fais-moi confiance. Slashing n’est pas aussi mauvais qu’il y paraît. Je suis mortellement sérieux. | de John Albert Cole | Coinmons | mai 2022

Le slash instille la peur dans le cœur et l’esprit de nombreux validateurs novices en raison des énormes responsabilités qu’ils assument, mais il doit être considéré comme un outil utile mis en œuvre pour assurer la sécurité et la stabilité d’un réseau DeFi de preuve d’enjeu nommé comme SwapDEX.

Le réseau a deux exigences fondamentales et très simples qu’il attend de chaque validateur :

Un slash se produira si le protocole système détecte un mauvais comportement des validateurs en se déconnectant, en multipliant les blocs de signature, en attaquant le réseau ou en exécutant un logiciel modifié non approuvé sur le réseau. Dans ces cas, les validateurs et leurs nominateurs seront réduits en fonction de la gravité de l’infraction en perdant un pourcentage de leurs pièces liées (stakes).

Les validateurs qui commettent l’une de ces infractions, qu’elles soient intentionnelles ou non, font face aux conséquences d’une coupure si cela peut effectivement être prouvé, généralement en chaîne via le protocole. Étant donné que l’ensemble du poste de validateur est affecté, les proposants absorberont également les pénalités de coupure.

Le taux d’intérêt annuel de notre pool de validateurs est actuellement d’un peu plus de 20 %. Ainsi, réduire ou supprimer ne serait-ce que 1 % de la participation d’un validateur peut être important, enlevant de nombreuses semaines de gains gagnés en validant. Bien sûr, la réputation d’un validateur est également affectée.

Un validateur sera refroidi (retiré) du pool de validateurs pendant une ère en raison d’infractions mineures à la vivacité, et ne recevra pas de slash. Cependant, à mesure que la gravité de l’infraction à la sécurité du réseau augmente, dépassant un seuil du pool de validateurs, les sanctions de réduction augmenteront proportionnellement. Cette structure de sanctions en cascade comprend des cas de signatures multiples de blocs, ce qui est généralement considéré comme une infraction plus grave.

Les validateurs commettant une faute, comme le piratage délibéré du réseau, entraînant une perturbation majeure des opérations, sont considérés comme l’infraction la plus grave justifiant leur retrait et leur participation au pool de validateurs. Leur mise sera envoyée au Trésor et pourra être brûlée si l’infraction est prouvée en ligne ou peut être jugée hors ligne nécessitant une intervention de la Gouvernance.

Nous allons maintenant aborder plus en détail les trois types de failles à la sécurité du réseau, les conséquences encourues sur un poste de validateur nécessitant un slash, et les causes potentielles de chacune des failles.

1. Vivacité
2. Équivoque
3. Inconduite

Conséquences coupantes

Vivacité– Les événements isolés nécessitent un refroidissement. Une pénalité de barre oblique est encourue si plus de 10 % des validateurs sont impliqués et augmente linéairement jusqu’à 44 % où la pénalité maximale est de 7 %.

Équivoque– En supposant qu’il y ait un ensemble complet de validateurs, il y aura une pénalité de refroidissement plus 0,0004 % de réduction si plus de 10 % des validateurs sont impliqués. Cette pénalité augmente linéairement jusqu’à 100% à mesure que la proportion de validateurs impliqués augmente.

Inconduite– Toute infraction d’inconduite entraînera une pénalité de 100 %.

Vivacité

La vivacité est la capacité du validateur à rester en ligne et à être réactif. Si un validateur ne produit pas de bloc ou n’envoie pas de signal de pulsation pendant une ère, le validateur sera considéré comme hors ligne et refroidi. Dans ce cas, aucune réduction de pièces ne se produit, mais comme le validateur n’a contribué à aucun travail, aucune récompense globale n’est versée au pool de validateurs. Les raisons d’un manque de vivacité, comme ce mignon petit bonhomme dans l’image ci-dessus, vont d’un certain nombre de problèmes : avoir un serveur existant hors ligne, un pare-feu ou une connectivité réseau empêche la communication avec le réseau, l’espace SSD du disque dur est donc plein aucune autre synchronisation ne se produit.

Peut-être qu’un nouveau serveur est installé ou migré vers un nouveau serveur et que l’instance de validateur n’a peut-être pas été démarrée avec l’indicateur de validateur, ou lors du changement de serveur, vous n’avez peut-être pas appliqué la bonne clé de session, et enfin votre nœud peut ne pas être complètement synchronisé.

Toutes ces lacunes des validateurs peuvent entraîner de graves problèmes de temps d’arrêt, et si un groupe plus important de validateurs est impliqué, la réduction des pénalités peut être importante.

Voici une histoire parallèle que vous pourriez trouver amusante à propos de l’envoi du symbole du rythme cardiaque sur le réseau. En tant que nouveau validateur, je me demandais quel était le symbole de la lettre par mon nœud de validateur, et cela me concernait comme beaucoup d’autres validateurs novices. Je dois admettre que j’essayais même de cliquer sur la lettre pour l’ouvrir ou de trouver cette lettre de courrier électronique méchante ailleurs, mais en vain. Ainsi, dans notre chat Discord, l’un de nos validateurs a eu le courage d’exposer son manque de connaissances, pas moi, et a posté cette question : « Qu’est-ce que c’est que cette lettre électronique par nos noms de nœud ? » Je n’oublierai jamais cela quand l’un de nos validateurs les plus expérimentés, un développeur, a répondu en disant « Vous n’avez jamais reçu de lettre d’amour ? » expliquant plus tard que c’est un message au réseau de votre nœud actif que vous êtes en ligne, en vie et en bonne santé. Après cela, je peux vous garantir qu’il y avait beaucoup de validateurs novices, y compris moi, qui ont poussé un soupir de soulagement que la lettre était une bonne chose, et nous ne serions pas coupés après tout.

Ce qui suit est un résumé d’un événement réel important (vivacité) qui s’est produit sur notre réseau :

Le 10 mars 2022, un centre de données géré par Contabo GmbH à Düsseldorf a connu une panne en raison d’une coupure physique d’un câble Internet à fibre optique. La panne a provoqué une interruption immédiate de la connexion d’env. 60 % (180) de tous les emplacements de validation SwapDEX.

Le protocole réseau SwapDEX a détecté l’absence de réponse ultérieure car les validateurs n’ont pas réussi à envoyer le signal de pulsation « Je suis en ligne ». Ce signal est soumis automatiquement sur la chaîne à chaque session. De plus, le protocole réseau gardait trace des actions payantes effectuées (blocs produits dans BABE, références oncle, déclarations de validité) ce qui constituait une mesure supplémentaire de réactivité.

Le protocole réseau SwapDEX a classé la panne simultanée d’env. 60% des validateurs comme une attaque car une panne de cette ampleur menace la capacité du réseau à produire des blocs. Cela a pu être observé dans les temps de production de blocs culminant autour de la barre des 60 secondes (généralement 6 secondes).

Les validateurs qui ont perdu la connexion ou qui n’ont pas réussi à effectuer une action payante en raison de l’instabilité du réseau qui en a résulté ont donc été perçus comme une menace pour le réseau et ont reçu des pénalités de 7 % de toutes les pièces SDX collées sur leurs emplacements de validateur (lien propre et nominateur) et le perte de tous les nominateurs. Cependant, les barres obliques ont été annulées peu de temps après par une action de gouvernance accélérée.

Remarque : la réduction maximale de la vivacité de 7 % a été atteinte lorsque 44 % de l’ensemble du pool de validateurs a été affecté.

Pour plus d’informations sur l’incident, y compris les leçons apprises, veuillez consulter le lien ci-dessous :

Rapport de chaîne SwapDEX

Équivoque

Le réseau s’attend à ce qu’un seul validateur pointe vers le bloc et le signe. Si plusieurs validateurs prétendent avoir signé le bloc le plus récent, nous avons un cas d’équivoque, où d’autres validateurs dupliquent essentiellement l’effort d’un validateur honnête. Cela peut être dû au clonage d’un validateur à utiliser comme sauvegarde à l’aide d’un système de basculement pour fournir un « temps d’arrêt zéro », ou lors de la migration de votre validateur vers un nouveau serveur en copiant le dossier keystore lors de la tentative de copie de la base de données.

En cas d’équivoque, la pénalité est calculée d’une manière qui tient compte de la probabilité d’être une attaque coordonnée ou non. Les pénalités sont calculées selon la formule suivante :

x = délinquants, n = nombre total de validateurs dans l’ensemble actif

pénalité = MIN((3*x/n) ², 1)

Exemple 1 (équivoque) :

Supposons qu’il y ait 100 validateurs dans l’ensemble actif, et que l’un d’eux équivoque dans un slot.

Il est peu probable qu’il s’agisse d’une attaque sur le réseau, mais beaucoup plus probablement d’une mauvaise configuration d’un validateur

x = 1, n = 100

pénalité = MIN ((3*1/100) ², 1) = MIN (0.0009, 1) = 0.0009 = 0.09%

La barre oblique s’appliquera à ce validateur et le validateur sera refroidi.

Exemple 2 (équivoque) :

Supposons maintenant qu’il existe un groupe de 20 validateurs et qu’ils ont tous un problème dans le même emplacement.

x = 20, n = 100

pénalité = MIN ((3*20/100) ², 1) = MIN (0.36, 1) = 0.36 = 36.0%

La barre oblique sera appliquée aux 20 pools de validateurs et à leurs nominateurs. Tous les validateurs barrés seront également refroidis.

Remarque : notez comment le pourcentage de réduction d’équivoque augmente à mesure que le nombre de pools de validateurs x augmente, ce qui suggère qu’il pourrait s’agir d’une attaque coordonnée sur le réseau.

Inconduite

L’inconduite est un comportement qui présente un risque pour la sécurité ou l’argent du réseau. Par conséquent, l’inconduite est le comportement le plus punissable dans les réseaux Kusari et Smart DEX Chain. Les coupures signalées et confirmées dans cette catégorie peuvent entraîner le transfert des fonds à l’intérieur du pool de validateurs vers le Trésor et pourraient finalement être brûlées. Raisons pour involontaire inconduite pourrait utiliser un binaire provenant d’un emplacement tiers qui pourrait être modifié, ou un serveur compromis dans lequel un tiers indésirable modifie le code de manière indésirable.

Si un validateur est signalé pour l’une de ces infractions, il sera retiré de l’ensemble de validateurs (réfrigéré) et il ne sera pas payé pendant son absence. Ils seront considérés comme inactifs immédiatement et perdront leurs nominateurs. Ils doivent réémettre l’intention pour valider et recueillir à nouveau le soutien des proposants.

Remarque : Les personnes qui commettent faute intentionnelle ne devrait être autorisé sur aucun réseau DeFi.

Ne craignez rien. Il y a de l’espoir pour les validateurs honnêtes. L’atténuation est la clé.

Voici des moyens de réduire le risque de se faire taillader pour Infractions de vivacité :

• Utilisation d’outils de surveillance tels que Telemetry, Grafana et Prometheus, ainsi que PagerDuty pour les alertes
• Déclencher des alertes lorsque le service est inaccessible ou lorsque des blocs sont bloqués (par exemple, 100 blocs)
• Assurez-vous que les clés de session sont vérifiées sur le serveur de destination
• Assurez-vous que le --validator le drapeau existe
• Comprendre les temps d’attente pour la migration des serveurs. Il faut au moins 2 ères avant que de nouvelles clés soient appliquées.

Voici des moyens de réduire le risque d’être tailladé pour Infractions d’équivoque :

• Ne copiez jamais votre Magasin de clés dossier vers un autre serveur
• Si votre serveur s’est déconnecté spontanément, ne paniquez pas et essayez de restaurer un serveur cloné pour minimiser les temps d’arrêt
• Utilisez un serveur de sauvegarde, s’il n’est pas entièrement synchronisé, utilisez un instantané pour accélérer le processus
• Appliquez un jeu de clés fraîchement généré à partir de ce serveur à la réserve
• Il vaut mieux être refroidi sans perte que de tenter une manœuvre sans temps d’arrêt et de se faire sabrer

Voici des moyens de réduire le risque d’être tailladé pour involontaire Inconduites :

• Téléchargez toujours les fichiers source et les binaires depuis le serveur officiel
• Vérifier le hachage des binaires téléchargés
• Utilisez la configuration du serveur « validateur sécurisé » sur le référentiel w3f ou respectez ses principes
• Les conseils de sécurité de base s’appliquent, utilisez un pare-feu, gérez l’accès des utilisateurs, utilisez l’accès au certificat SSH, etc.
• Évitez d’utiliser votre serveur comme une machine à usage général. Plus grande interaction = plus grand risque.

Remarque finale: N’oubliez pas qu’il est important de faire vos propres recherches avant de nominer (stake) car il y a un risque d’être coupé si vos validateurs se comportent mal. L’article lié ci-dessous fournit des informations utiles sur la façon de choisir un validateur sur notre réseau.

Cinq choses à considérer lors du jalonnement

Rendez-nous visite sur les réseaux sociaux :
TwitterLinkedIn, Discorde, Télégramme

Rejoignez Coinmonks Telegram Channel et Youtube Channel pour en savoir plus sur le trading et l’investissement cryptographiques