#dusk $DUSK

Honnêtement, je suis choqué. Seulement 5 points malgré 5K vues, ça me paraît vraiment injuste et décevant.

Je poste aujourd’hui le cœur lourd… mais avant le post, voici un petit scalp :

Long $PORTAL 📈
Short $CYS 📉
N’oubliez pas de me remercier quand vous encaissez le profit

Au départ, je pensais que m’être fait “scalper” sur @Dusk signifiait une seule chose : perdre la mise et redémarrer le nœud

Le guide de récupération trace une ligne beaucoup plus nette.

Une pénalité douce peut suspendre l’éligibilité d’un provisioner et déplacer une partie de sa mise active vers une mise verrouillée. Cette mise appartient toujours à l’opérateur et peut être retirée.

Des pénalités dures s’appliquent à des comportements de consensus prouvablement invalides, comme des votes contradictoires ou l’equivocation. Une partie de la mise est brûlée, et redémarrer ou restaker ne peut pas la récupérer.

C’est bien cette distinction qui est restée.

Dusk traite différemment la participation manquée et la participation contradictoire. Une version obsolète, une interruption prolongée, une mauvaise synchronisation ou un blocage du trafic réseau peuvent entraîner une défaillance opérationnelle. Le fait de signer des messages contradictoires bascule dans un comportement que le protocole peut prouver comme invalide.

L’avertissement de clé dupliquée rend la frontière concrète.

Exécuter la même clé de consensus sur deux nœuds actifs peut amener les deux machines à signer des messages incompatibles, même si l’opérateur pensait que le deuxième nœud n’était qu’une sauvegarde.

J’aime l’idée que la récupération commence par corriger la version, la synchronisation, la connectivité et la configuration de clé avant de créer une nouvelle position de provisioner. Restaker sans trouver la cause ne ferait que placer une nouvelle position derrière la même configuration défectueuse

Le modèle implique aussi que la redondance doit être conçue avec soin. Une sauvegarde prévue pour améliorer la disponibilité peut créer un risque de “hard-slashing” si elle devient active avec la même clé.

Séparer la défaillance opérationnelle de l’equivocation rend-il les pénalités plus justes, ou bien la gestion de la clé de consensus est-elle la partie la plus impitoyable de l’exécution d’un provisioner ?
Le slashing du provisioner sur @Dusk soulève une question intéressante
Qu’est-ce qui compte le plus pour garder les validateurs en sécurité ?