$DUSK #dusk @Dusk
J’ai passé du temps à fouiller la cryptographie de Dusk — Argon2, Equihash, PLONK, toute la partie sérieuse côté mathématiques de la pile.
Puis j’ai vérifié ce qui est devenu, en réalité, un problème de sécurité récemment.
Ce n’était pas la cryptographie.
C’était un portefeuille opérationnel.
Le 16 août, Dusk a mis en pause ses services de pont après avoir surveillé une activité signalée qui ne correspondait pas aux opérations normales du pont. DuskDS lui-même continuait à produire des blocs, et l’atténuation qui a suivi n’était pas un nouveau système de preuve ni un changement de consensus.
C’était beaucoup plus simple : une liste de blocage des destinataires dans le Web Wallet qui avertit les utilisateurs avant d’envoyer vers des adresses signalées.
Cette différence m’a marqué.
Dusk peut avoir une cryptographie sophistiquée en dessous, tandis que la défense la plus immédiate, visible par l’utilisateur, se trouve à la couche du portefeuille.
Et cela crée une frontière intéressante.
Si vous utilisez le Web Wallet, vous obtenez cet avertissement.
Si vous interagissez via vos propres outils ou directement via le protocole, vous ne l’obtenez peut-être pas.
Donc, le modèle de sécurité ne se résume pas seulement à la solidité de la cryptographie sous-jacente.
C’est aussi une question d’endroit où la protection réside réellement — et qui en hérite par défaut.
Je comprends pourquoi un contrôle au niveau du portefeuille est la réponse pratique la plus rapide.
Mais pour un réseau visant une finance réglementée, je reviens sans cesse à une question :
Quelle quantité de sécurité doit vivre dans le protocole, et quelle quantité peut vivre en toute sécurité dans l’interface ?
$PORTAL
$PROM
Où devraient se trouver les contrôles de sécurité de Dusk ? 👀
J’ai passé du temps à fouiller la cryptographie de Dusk — Argon2, Equihash, PLONK, toute la partie sérieuse côté mathématiques de la pile.
Puis j’ai vérifié ce qui est devenu, en réalité, un problème de sécurité récemment.
Ce n’était pas la cryptographie.
C’était un portefeuille opérationnel.
Le 16 août, Dusk a mis en pause ses services de pont après avoir surveillé une activité signalée qui ne correspondait pas aux opérations normales du pont. DuskDS lui-même continuait à produire des blocs, et l’atténuation qui a suivi n’était pas un nouveau système de preuve ni un changement de consensus.
C’était beaucoup plus simple : une liste de blocage des destinataires dans le Web Wallet qui avertit les utilisateurs avant d’envoyer vers des adresses signalées.
Cette différence m’a marqué.
Dusk peut avoir une cryptographie sophistiquée en dessous, tandis que la défense la plus immédiate, visible par l’utilisateur, se trouve à la couche du portefeuille.
Et cela crée une frontière intéressante.
Si vous utilisez le Web Wallet, vous obtenez cet avertissement.
Si vous interagissez via vos propres outils ou directement via le protocole, vous ne l’obtenez peut-être pas.
Donc, le modèle de sécurité ne se résume pas seulement à la solidité de la cryptographie sous-jacente.
C’est aussi une question d’endroit où la protection réside réellement — et qui en hérite par défaut.
Je comprends pourquoi un contrôle au niveau du portefeuille est la réponse pratique la plus rapide.
Mais pour un réseau visant une finance réglementée, je reviens sans cesse à une question :
Quelle quantité de sécurité doit vivre dans le protocole, et quelle quantité peut vivre en toute sécurité dans l’interface ?
$PORTAL
$PROM
Où devraient se trouver les contrôles de sécurité de Dusk ? 👀
🔒 Inside the protocol
50%
🖥️ At the wallet layer
50%
⚡ Both together
0%
🎯 Depends on the risk
0%
2 Votes • Vote fermé