J’ai extrait l’avis d’incident relatif au pont du réseau Dusk ($DUSK ) du 16 août pendant que je menais à bien cette tâche. #Dusk @Dusk . L’équipe a signalé une activité suspecte sur une adresse de portefeuille de pont gérée par l’équipe, a désactivé puis recyclé les adresses concernées, a mis en pause les services de pont et a coordonné avec Binance — apparemment avant qu’aucun fonds utilisateur ne bouge. Aucun problème au niveau du protocole sur DuskDS. Réponse standard à un incident. Mais je l’ai relu sans cesse pour une raison différente.
Ce qui est resté : leurs systèmes de surveillance l’ont détecté. Cela signifie que l’équipe avait une visibilité sur un comportement précis de portefeuille que des observateurs externes, y compris toute personne consultant l’explorateur de blocs, n’avaient probablement pas. Ce n’est pas un hasard. C’est l’architecture. Les transactions Phoenix sur DuskDS n’exposent ni l’expéditeur, ni le destinataire, ni le montant à quiconque sans clé de vue. DuskEVM fonctionne sans mempool public — seul le séquenceur intervient. La visibilité sur Dusk est attribuée, pas supposée.
Et c’est précisément la promesse institutionnelle. Pas la confidentialité comme fonctionnalité ajoutée. La visibilité comme autorisation configurable. Les régulateurs reçoivent une clé de vue limitée à ce dont ils ont besoin. Les contreparties voient ce que le contrat autorise. Les opérateurs voient ce que leur rôle leur accorde. Et le reste du monde voit… pas grand-chose.
Je n’ai cessé de penser à quel point c’est différent de la conception standard d’une chaîne, où l’explorateur de blocs voit tout par défaut et où les contrôles d’accès ne sont que des réflexions a posteriori. Ici, le défaut est l’opacité. Les institutions semblent préférer cela. Ce qui est compréhensible — jusqu’au moment où l’on commence à se demander qui contrôle la distribution de la clé de vue, et si ce contrôle ne finit jamais entre de moins en moins de mains que ce que la conception laisse entendre.