#dusk $DUSK @Dusk
J’ai décidé de vérifier ce qui se passait réellement sur le réseau Dusk ces derniers temps et j’ai constaté un intéressant décalage entre le niveau du protocole et la sécurité côté utilisateur. Le 16 août, les services de passerelle ont été suspendus après la surveillance d’une activité suspecte dans le portefeuille opérationnel. Au moment de la vérification, ils étaient encore dans l’étape de renforcement (hardening). Par ailleurs, au niveau de DuskDS, aucun problème de production de blocs n’a été observé : le réseau continuait à fonctionner.
Ce qui m’a particulièrement frappé, c’est que la principale mesure d’atténuation n’a pas reposé sur un mécanisme de preuve, mais sur une blocklist des destinataires dans Web Wallet. Avant d’envoyer à l’adresse marquée, l’utilisateur reçoit un avertissement. Et c’est là que naît une contradiction. La cryptographie la plus complexe de Dusk n’était pas à l’origine du problème : c’est la protection qui a fonctionné précisément au niveau de l’interface. D’un côté, c’est pragmatique, car le front-end permet de protéger rapidement la majorité des utilisateurs. Mais de l’autre, l’utilisateur ne bénéficie pas automatiquement de cette protection via ses propres outils ou via la CLI.
Pour moi, c’est désormais une question d’architecture importante : si Dusk est conçu pour des finances réglementées, la sécurité critique doit-elle se situer au niveau du protocole, et pas seulement de l’interface ?
J’ai décidé de vérifier ce qui se passait réellement sur le réseau Dusk ces derniers temps et j’ai constaté un intéressant décalage entre le niveau du protocole et la sécurité côté utilisateur. Le 16 août, les services de passerelle ont été suspendus après la surveillance d’une activité suspecte dans le portefeuille opérationnel. Au moment de la vérification, ils étaient encore dans l’étape de renforcement (hardening). Par ailleurs, au niveau de DuskDS, aucun problème de production de blocs n’a été observé : le réseau continuait à fonctionner.
Ce qui m’a particulièrement frappé, c’est que la principale mesure d’atténuation n’a pas reposé sur un mécanisme de preuve, mais sur une blocklist des destinataires dans Web Wallet. Avant d’envoyer à l’adresse marquée, l’utilisateur reçoit un avertissement. Et c’est là que naît une contradiction. La cryptographie la plus complexe de Dusk n’était pas à l’origine du problème : c’est la protection qui a fonctionné précisément au niveau de l’interface. D’un côté, c’est pragmatique, car le front-end permet de protéger rapidement la majorité des utilisateurs. Mais de l’autre, l’utilisateur ne bénéficie pas automatiquement de cette protection via ses propres outils ou via la CLI.
Pour moi, c’est désormais une question d’architecture importante : si Dusk est conçu pour des finances réglementées, la sécurité critique doit-elle se situer au niveau du protocole, et pas seulement de l’interface ?
