#dusk $DUSK @Dusk Je suis resté assis avec la tâche un moment sur le déplacement de Dusk vers OP Stack, une collation à la main, et une chose continue de me trotter dans la tête.
DuskEVM tourne maintenant sur OP Stack, revenant vers DuskDS plutôt que de rester là avec la fenêtre classique de challenge optimiste de 7 jours à laquelle tout le monde est habitué. Dusk le présente comme une finalité déterministe : pas d’attente pendant une semaine, pas de purgatoire de preuves de fraude. Sur le papier, ça paraît propre.
Puis, le 16 août 2026 arrive.
L’équipe de Dusk elle-même repère une activité suspecte sur un wallet géré par l’équipe, lié à des opérations de pont. Réponse ? Pas une preuve de fraude “on-chain” qui se déclenche automatiquement. L’équipe désactive et recycle les adresses de pont affectées, met en pause les services de pont manuellement, puis déploie une liste de blocage de Web Wallet pour les destinataires signalés.
Bref… une équipe d’opérations humaines qui tire des leviers, pas la couche de règlement qui fait quelque chose de manière sans confiance.
Hmm. Je ne remets pas en cause le correctif : il a été rapide, raisonnable, exactement ce que tu voudrais. Mais c’est un rappel : une “fenêtre sans faute” est une déclaration sur la mathématique de finalité de la couche d’exécution, pas sur la personne ou le système qui intervient réellement quand quelque chose se passe mal en amont.
Le filet de sécurité qui comptait ce jour-là, c’était une équipe avec des accès administrateur, pas l’architecture d’OP Stack.
Ça m’a fait faire une pause au milieu de la tâche : dans mes notes, j’ai écrit “aucune fenêtre de 7 jours n’est sans confiance”, puis je l’ai barré.
Où est-ce que le règlement déterministe réduit vraiment la dépendance à une équipe réactive—plutôt que de déplacer la confiance vers un endroit moins visible ?
DuskEVM tourne maintenant sur OP Stack, revenant vers DuskDS plutôt que de rester là avec la fenêtre classique de challenge optimiste de 7 jours à laquelle tout le monde est habitué. Dusk le présente comme une finalité déterministe : pas d’attente pendant une semaine, pas de purgatoire de preuves de fraude. Sur le papier, ça paraît propre.
Puis, le 16 août 2026 arrive.
L’équipe de Dusk elle-même repère une activité suspecte sur un wallet géré par l’équipe, lié à des opérations de pont. Réponse ? Pas une preuve de fraude “on-chain” qui se déclenche automatiquement. L’équipe désactive et recycle les adresses de pont affectées, met en pause les services de pont manuellement, puis déploie une liste de blocage de Web Wallet pour les destinataires signalés.
Bref… une équipe d’opérations humaines qui tire des leviers, pas la couche de règlement qui fait quelque chose de manière sans confiance.
Hmm. Je ne remets pas en cause le correctif : il a été rapide, raisonnable, exactement ce que tu voudrais. Mais c’est un rappel : une “fenêtre sans faute” est une déclaration sur la mathématique de finalité de la couche d’exécution, pas sur la personne ou le système qui intervient réellement quand quelque chose se passe mal en amont.
Le filet de sécurité qui comptait ce jour-là, c’était une équipe avec des accès administrateur, pas l’architecture d’OP Stack.
Ça m’a fait faire une pause au milieu de la tâche : dans mes notes, j’ai écrit “aucune fenêtre de 7 jours n’est sans confiance”, puis je l’ai barré.
Où est-ce que le règlement déterministe réduit vraiment la dépendance à une équipe réactive—plutôt que de déplacer la confiance vers un endroit moins visible ?
