J’ai relu une seconde fois, cette année, le récapitulatif de la passerelle cross-chain (pont) lié au @Dusk , et ce qu’il y a de plus intéressant à regarder n’est pas les deux mots « volé », mais à quel niveau précis la panne s’est produite. Le 16 janvier, le problème venait du portefeuille de signature utilisé par le service du pont : après avoir obtenu l’autorisation de prêt, l’attaquant transfère les actifs depuis le côté Dusk, puis en envoie une partie vers la BSC. Officiellement, il est clairement indiqué que ce n’est ni un échec de consensus, ni un protocole L1 qui a été percé.
Mais cela ne veut pas dire que la couche sous-jacente va bien, et que les utilisateurs devraient ignorer les risques du pont. Dans l’ancienne architecture, la réception des événements, la signature et la libération des fonds étaient regroupées sur un seul chemin : c’est rapide, mais si la partie signature est compromise, les autorisations deviennent trop concentrées. La refonte suivante a séparé les trois choses : d’abord l’événement est enregistré en tant que tâche, le worker traite ensuite selon la machine à états ; les transactions brutes signées sont conservées, et en cas d’échec, on rejoue la même transaction ; le hot wallet ne conserve que le solde nécessaire à court terme : s’il tombe sous un seuil, on suspend, et un cold wallet est complété manuellement.
Avant, j’avais aussi tendance à utiliser la phrase « le pont n’est pas un protocole » comme clause d’exonération. Aujourd’hui, je suis plus enclin à la regarder à l’envers : tant que l’utilisateur le considère comme une porte d’entrée de liquidité, le pont se trouve déjà dans la vraie frontière de sécurité de $DUSK . La sécurité du consensus on-chain et la sécurité des points d’entrée/sortie d’actifs sont deux copies qu’il faut réussir en même temps.
Cette fois, la direction de la remédiation est correcte, et le risque n’a pas disparu : l’isolation des clés est-elle appliquée durablement, le seuil est-il raisonnable, l’arrêt et l’ajout de fonds sont-ils auditables—il faut continuer à surveiller tout cela. #dusk La communauté devrait plutôt demander non pas « est-ce que la chaîne a été piratée », mais « quelle clé conserve encore des pouvoirs au-delà du nécessaire ». Quand vous regardez un pont cross-chain, vous commencez par l’audit du code, ou d’abord par la manière dont les droits d’exploitation sont découpés ?
$TREE $ETH
Mais cela ne veut pas dire que la couche sous-jacente va bien, et que les utilisateurs devraient ignorer les risques du pont. Dans l’ancienne architecture, la réception des événements, la signature et la libération des fonds étaient regroupées sur un seul chemin : c’est rapide, mais si la partie signature est compromise, les autorisations deviennent trop concentrées. La refonte suivante a séparé les trois choses : d’abord l’événement est enregistré en tant que tâche, le worker traite ensuite selon la machine à états ; les transactions brutes signées sont conservées, et en cas d’échec, on rejoue la même transaction ; le hot wallet ne conserve que le solde nécessaire à court terme : s’il tombe sous un seuil, on suspend, et un cold wallet est complété manuellement.
Avant, j’avais aussi tendance à utiliser la phrase « le pont n’est pas un protocole » comme clause d’exonération. Aujourd’hui, je suis plus enclin à la regarder à l’envers : tant que l’utilisateur le considère comme une porte d’entrée de liquidité, le pont se trouve déjà dans la vraie frontière de sécurité de $DUSK . La sécurité du consensus on-chain et la sécurité des points d’entrée/sortie d’actifs sont deux copies qu’il faut réussir en même temps.
Cette fois, la direction de la remédiation est correcte, et le risque n’a pas disparu : l’isolation des clés est-elle appliquée durablement, le seuil est-il raisonnable, l’arrêt et l’ajout de fonds sont-ils auditables—il faut continuer à surveiller tout cela. #dusk La communauté devrait plutôt demander non pas « est-ce que la chaîne a été piratée », mais « quelle clé conserve encore des pouvoirs au-delà du nécessaire ». Quand vous regardez un pont cross-chain, vous commencez par l’audit du code, ou d’abord par la manière dont les droits d’exploitation sont découpés ?
$TREE $ETH
