#dusk $DUSK Je constate les problèmes de sécurité de @Dusk et je sépare volontairement la « sécurité du protocole » et la « sécurité de l’écosystème ». La première inclut le consensus, l’implémentation cryptographique, les contrats intelligents et les limites de la machine virtuelle ; la seconde recouvre le portefeuille, le front-end, les services de pont, la gestion des clés, l’exploitation des nœuds et l’intégration de tiers. Beaucoup de projets aiment souligner, après un incident, que la chaîne principale n’a aucun problème. Cette affirmation est parfois vraie, mais pour les personnes qui détiennent du $DUSK et utilisent des produits de l’écosystème, la sécurité des actifs ne revient pas automatiquement du seul fait que les responsabilités ont été réparties de façon très claire. $SPCXB
Pour des réseaux comme Dusk, orientés vers la finance de confidentialité, les exigences de sécurité sont en réalité plus élevées. Étant donné que les utilisateurs et les institutions acceptent d’utiliser des capacités de confidentialité, il ne s’agit pas seulement de croire que les algorithmes sont fiables : il faut aussi croire que les points d’entrée, les services et les processus opérationnels sont suffisamment maîtrisés. Une erreur dans la gestion d’une clé de signature, une page d’autorisation remplacée, un retard de surveillance lors d’un pont peuvent tous contourner la conception rigoureuse du protocole sous-jacent. Le maillon le plus faible d’un système technique se trouve souvent non pas dans la partie cryptographique la plus complexe, mais dans ces segments « supposés dignes de confiance par défaut » lors de la transmission entre différents composants. $SNDKB
J’apprécie l’importance des analyses publiques et des correctifs continus, mais je m’intéresse surtout à savoir si, après la répétition des revues, des améliorations vérifiables sont réellement produites. Par exemple : les autorisations critiques sont-elles bien séparées ? Les opérations sensibles nécessitent-elles des confirmations multiples ? L’exposition au risque des portefeuilles chauds ou des comptes de service est-elle plafonnée de manière explicite ? Les transactions anormales peuvent-elles être détectées en temps voulu ? L’utilisateur peut-il savoir dans quel état se trouve le service. Pour l’écosystème DUSK, une annonce de sécurité ne devrait pas n’être qu’une explication après l’incident : elle devrait devenir un document permettant aux utilisateurs d’évaluer le niveau de maturité de la gestion des risques.
C’est pourquoi je ne pense pas qu’un seul problème suffise à nier la direction technologique de Dusk, mais je ne considère pas non plus « c’est réparé » comme la fin du débat. Ce qui mérite vraiment d’être suivi, c’est si les correctifs couvrent des parcours similaires, si l’audit externe est continu, si les avertissements sur les risques sont suffisamment transparents, et si l’équipe peut fournir rapidement des informations vérifiables sous pression. La finance de confidentialité a besoin de confiance, mais la confiance ne peut pas reposer uniquement sur des slogans. Si Dusk veut prendre en charge des actifs et des utilisateurs plus complexes, il faut que chaque couche de service supporte les mêmes interrogations rigoureuses : en cas d’anomalie, qui peut la détecter, qui peut la limiter, qui peut l’expliquer, et qui en porte la responsabilité.
#dusk @Dusk