Le pont est encore en panne, et c’est exactement à cela que je reviens pendant un certain temps.
@Dusk a suspendu ses services de pont le 16 janvier après que la surveillance a détecté une activité incohérente avec les opérations normales — un portefeuille opérationnel géré par une équipe, et non le protocole. Les blocs de DuskDS n’ont jamais cessé. Mais le pont reste à l’arrêt pendant qu’ils finalisent les travaux de durcissement, et la mitigation déjà déployée est une liste de blocage des destinataires dans le Web Wallet. Signalez une adresse frauduleuse, affichez un avertissement, arrêtez l’envoi.
C’est tout. C’est le filet de sécurité.
Et voici ce que je n’arrive pas à arrêter de me demander : si vous utilisez Rusk CLI ou vos propres outils, cet avertissement ne se déclenche jamais. Vous êtes totalement souverain — et totalement exposé. La cryptographie ZK en dessous est un travail réellement sérieux. Rien de tout cela n’a touché la surface de risque réelle de cette semaine.
Je ne pense pas que la liste de blocage soit un mauvais choix. Pragmatiquement, c’est correct — couvrir le plus grand nombre d’utilisateurs le plus vite possible, et corriger l’architecture ensuite.
Mais $DUSK se positionne explicitement pour des marchés institutionnels réglementés. Si le contrôle de sécurité le plus visible vit dans un Web Wallet plutôt que dans le protocole lui-même, il existe une vraie question sur ce qui se passe lorsqu’une équipe de conformité soumet réellement cette pile à des tests de résistance.
C’est l’écart que je surveille. Pas la cryptographie — la gouvernance de l’endroit où la protection vit réellement.
Si les institutions ont besoin de garanties au niveau du protocole, et pas d’avertissements côté interface, la feuille de route actuelle de Dusk va-t-elle assez vite dans cette direction ?
#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS
@Dusk a suspendu ses services de pont le 16 janvier après que la surveillance a détecté une activité incohérente avec les opérations normales — un portefeuille opérationnel géré par une équipe, et non le protocole. Les blocs de DuskDS n’ont jamais cessé. Mais le pont reste à l’arrêt pendant qu’ils finalisent les travaux de durcissement, et la mitigation déjà déployée est une liste de blocage des destinataires dans le Web Wallet. Signalez une adresse frauduleuse, affichez un avertissement, arrêtez l’envoi.
C’est tout. C’est le filet de sécurité.
Et voici ce que je n’arrive pas à arrêter de me demander : si vous utilisez Rusk CLI ou vos propres outils, cet avertissement ne se déclenche jamais. Vous êtes totalement souverain — et totalement exposé. La cryptographie ZK en dessous est un travail réellement sérieux. Rien de tout cela n’a touché la surface de risque réelle de cette semaine.
Je ne pense pas que la liste de blocage soit un mauvais choix. Pragmatiquement, c’est correct — couvrir le plus grand nombre d’utilisateurs le plus vite possible, et corriger l’architecture ensuite.
Mais $DUSK se positionne explicitement pour des marchés institutionnels réglementés. Si le contrôle de sécurité le plus visible vit dans un Web Wallet plutôt que dans le protocole lui-même, il existe une vraie question sur ce qui se passe lorsqu’une équipe de conformité soumet réellement cette pile à des tests de résistance.
C’est l’écart que je surveille. Pas la cryptographie — la gouvernance de l’endroit où la protection vit réellement.
Si les institutions ont besoin de garanties au niveau du protocole, et pas d’avertissements côté interface, la feuille de route actuelle de Dusk va-t-elle assez vite dans cette direction ?
#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS
