Je pensais auparavant que « le solde insuffisant met automatiquement en pause » était une mauvaise expérience. Après avoir lu le compte-rendu de l’incident de pontage lié à @Dusk , j’ai compris que le fait de suspendre tôt ressemblait plutôt à une manière de rendre des comptes sur les actifs.
Le débrief est très direct : le nouveau pont ne conserve, du côté du terminal de signature, que le plus petit solde opérationnel possible. Si ce solde passe sous un seuil, le pont s’arrête ; il ne redémarre qu’après que le portefeuille à froid a été réapprovisionné manuellement. L’ancien pont faisait transiter, sur un même chemin, la signature, le traitement des événements et la connexion réseau. Une fois le portefeuille de signature victime d’un accès non autorisé, l’attaquant n’a même pas besoin de toucher à la consensus Dusk : il peut quand même mobiliser les fonds présents dans le pont.
Ce seuil n’est pas un simple interrupteur de limite ordinaire. Puisque le service inter-chaînes transporte des actifs à la place de l’utilisateur, il ne peut pas mettre « le service continue » avant « le portefeuille chaud place moins d’argent ». Les opérateurs gagnent une fenêtre de pertes plus petite ; pour les utilisateurs en attente de migration, c’est un coût réel en temps.
Quand le marché est volatil, beaucoup d’utilisateurs migrent en même temps : le pont se met en pause à cause du solde trop faible. Les transactions des utilisateurs ne échouent pas forcément, mais elles peuvent se retrouver bloquées dans une file d’attente en attente de réapprovisionnement. Si la page ne fait que dire « en maintenance », l’utilisateur ne sait pas si le problème vient du fait que les fonds n’arrivent pas, si la requête n’est pas traitée, ou si le système a déclenché lui-même un contrôle des risques.
Je reconnais à $DUSK le fait de céder une partie de la disponibilité à l’isolement et à la limitation des dégâts, mais cela ne signifie pas que le risque de pontage a disparu. Pour vérifier l’utilité de cette refonte, il faut voir si @Dusk peut continuer à publier le nombre de fois où la pause est déclenchée, le temps nécessaire pour rétablir le service, et comment les requêtes en attente sont finalement purgées. #dusk