Explication du Dusk Staking : comment DUSK aide à sécuriser le réseau
Ce qui a réellement attiré mon attention ici n’était pas un chiffre de tableau de staking — c’était ce qui est resté constant pendant une semaine stressante. Le 16 août, l’équipe de Dusk a signalé une activité suspecte sur une adresse de portefeuille liée aux opérations d’un pont, a mis les services du pont en pause et a recyclé les adresses concernées. Ce que j’ai cherché ensuite, c’était de savoir si la production de blocs elle-même vacillait. Ce n’était pas le cas. L’avis d’incident de Dusk indique que ce n’était pas un problème au niveau du protocole et que le mainnet DuskDS a continué de fonctionner normalement pendant toute la période — ce qui signifie que le consensus SBA, sécurisé par le DUSK staké auprès des validateurs (provisioners et block generators), continuait de valider des blocs tandis qu’un portefeuille de garde distinct était compromis.
C’est un test plus clair de « comment le staking sécurise le réseau » que n’importe quelle phrase marketing : le portefeuille compromis était une infrastructure gérée par l’équipe pour le pont, pas un capital de consensus staké, et les deux systèmes n’ont pas partagé le même sort.
Ce que je n’ai pas pu vérifier : le montant total actuel staké ou le nombre de validateurs. Les sources publiques présentent des chiffres contradictoires ou obsolètes, et je ne vais pas citer un nombre périmé comme s’il était actuel.
Est-ce que le fait de séparer la sécurité du consensus du risque lié au bridge/à la garde change la façon dont vous évalueriez ce type d’incidents à l’avenir ?
Sources : l’avis officiel d’incident du bridge de Dusk et la page du projet Dusk Network de Messari pour la chronologie du 16 août et le langage relatif à l’état du réseau.
@Dusk $DUSK #dusk
Ce qui a réellement attiré mon attention ici n’était pas un chiffre de tableau de staking — c’était ce qui est resté constant pendant une semaine stressante. Le 16 août, l’équipe de Dusk a signalé une activité suspecte sur une adresse de portefeuille liée aux opérations d’un pont, a mis les services du pont en pause et a recyclé les adresses concernées. Ce que j’ai cherché ensuite, c’était de savoir si la production de blocs elle-même vacillait. Ce n’était pas le cas. L’avis d’incident de Dusk indique que ce n’était pas un problème au niveau du protocole et que le mainnet DuskDS a continué de fonctionner normalement pendant toute la période — ce qui signifie que le consensus SBA, sécurisé par le DUSK staké auprès des validateurs (provisioners et block generators), continuait de valider des blocs tandis qu’un portefeuille de garde distinct était compromis.
C’est un test plus clair de « comment le staking sécurise le réseau » que n’importe quelle phrase marketing : le portefeuille compromis était une infrastructure gérée par l’équipe pour le pont, pas un capital de consensus staké, et les deux systèmes n’ont pas partagé le même sort.
Ce que je n’ai pas pu vérifier : le montant total actuel staké ou le nombre de validateurs. Les sources publiques présentent des chiffres contradictoires ou obsolètes, et je ne vais pas citer un nombre périmé comme s’il était actuel.
Est-ce que le fait de séparer la sécurité du consensus du risque lié au bridge/à la garde change la façon dont vous évalueriez ce type d’incidents à l’avenir ?
Sources : l’avis officiel d’incident du bridge de Dusk et la page du projet Dusk Network de Messari pour la chronologie du 16 août et le langage relatif à l’état du réseau.
@Dusk $DUSK #dusk
