$DUSK #Crépuscule — DuskEVM contourne la fenêtre d’attente classique de 7 jours d’Optimism. Ce délai n’était pas un simple défaut d’expérience utilisateur ; il fait partie du modèle de sécurité.
En se penchant sur la note de @DuskFoundation concernant le port vers l’OP Stack, DuskEVM passe à DuskDS, tandis qu’un pré-vérificateur basé sur MIPS contrôle les transitions d’état avant qu’elles ne soient acceptées pour le règlement. La documentation de Dusk indique que les retraits se finalisent en environ 15 minutes.
Au premier abord, cela ressemble à une amélioration UX évidente. Mais la question de sécurité est plus intéressante.
Sur l’OP Stack standard, la fenêtre de 7 jours laisse le temps aux preuves de fraude sans permission (permissionless) de contester une racine d’état invalide. Dans la conception de Dusk, la vérification est déplacée plus tôt dans le flux.
Je ne décrirais donc pas cela comme un simple « suppression de l’exigence de confiance ». La question cruciale est : où se situe désormais l’hypothèse de sécurité ? La pré-vérification est-elle imposée indépendamment par l’ensemble de validateurs de DuskDS, ou dépend-elle d’un ensemble de vérificateurs distinct ?
Cette distinction compte. Une finalité plus rapide est précieuse, mais seulement si l’on comprend ce qui a changé en dessous.
Je consulte ensuite le GitHub de Rusk et la documentation technique de Dusk pour voir comment l’ensemble de pré-vérification se relie aux validateurs de DuskDS.
#dusk $DUSK @Dusk
En se penchant sur la note de @DuskFoundation concernant le port vers l’OP Stack, DuskEVM passe à DuskDS, tandis qu’un pré-vérificateur basé sur MIPS contrôle les transitions d’état avant qu’elles ne soient acceptées pour le règlement. La documentation de Dusk indique que les retraits se finalisent en environ 15 minutes.
Au premier abord, cela ressemble à une amélioration UX évidente. Mais la question de sécurité est plus intéressante.
Sur l’OP Stack standard, la fenêtre de 7 jours laisse le temps aux preuves de fraude sans permission (permissionless) de contester une racine d’état invalide. Dans la conception de Dusk, la vérification est déplacée plus tôt dans le flux.
Je ne décrirais donc pas cela comme un simple « suppression de l’exigence de confiance ». La question cruciale est : où se situe désormais l’hypothèse de sécurité ? La pré-vérification est-elle imposée indépendamment par l’ensemble de validateurs de DuskDS, ou dépend-elle d’un ensemble de vérificateurs distinct ?
Cette distinction compte. Une finalité plus rapide est précieuse, mais seulement si l’on comprend ce qui a changé en dessous.
Je consulte ensuite le GitHub de Rusk et la documentation technique de Dusk pour voir comment l’ensemble de pré-vérification se relie aux validateurs de DuskDS.
#dusk $DUSK @Dusk
