#dusk $DUSK @Dusk
Quatre nombres ont suffi. Le chemin du Phoenix de Dusk, protégé par un bouclier — la partie qui porte toute son offre de confidentialité — a vérifié des preuves en un seul appel, et cet appel n’a jamais vérifié quatre valeurs de sélection par rapport aux engagements qui se trouvaient juste là, dans la clé de vérification. $DUSK #dusk @Dusk avait déjà passé trois audits distincts avant que ce point ne soit découvert en février.
Ce qui m’a frappé, c’est la forme de la faille. Dans le PLONK standard, les sélecteurs sont censés être des données publiques, fixes, côté vérificateur. Les widgets personnalisés de dusk-plonk les ont forcés à devenir des nombres fournis par le prouveur, et personne n’a mis à jour le modèle mental qui détermine ce qui doit être lié cryptographiquement. La logique du circuit elle-même était correcte de bout en bout — l’écart se situait juste en dessous, dans le câblage de la vérification.
Ce qui a changé pour moi, c’est de comprendre que « audité trois fois » n’est pas la même chose que « audité contre le bon modèle de menace ». Un relecteur qui vérifie la logique des contraintes peut passer à côté d’une hypothèse structurelle qui cesse silencieusement de tenir. C’est plus difficile à détecter qu’un bogue de code classique, et ce n’est pas propre à Dusk — le même schéma a été mis au jour indépendamment dans Jellyfish d’Espresso.
La prochaine chose que je vérifierais : si la volonté de Dusk de pousser une spécification standardisée de vérification PLONK est effectivement livrée, ou si elle reste un simple fil de discussion.
Quatre nombres ont suffi. Le chemin du Phoenix de Dusk, protégé par un bouclier — la partie qui porte toute son offre de confidentialité — a vérifié des preuves en un seul appel, et cet appel n’a jamais vérifié quatre valeurs de sélection par rapport aux engagements qui se trouvaient juste là, dans la clé de vérification. $DUSK #dusk @Dusk avait déjà passé trois audits distincts avant que ce point ne soit découvert en février.
Ce qui m’a frappé, c’est la forme de la faille. Dans le PLONK standard, les sélecteurs sont censés être des données publiques, fixes, côté vérificateur. Les widgets personnalisés de dusk-plonk les ont forcés à devenir des nombres fournis par le prouveur, et personne n’a mis à jour le modèle mental qui détermine ce qui doit être lié cryptographiquement. La logique du circuit elle-même était correcte de bout en bout — l’écart se situait juste en dessous, dans le câblage de la vérification.
Ce qui a changé pour moi, c’est de comprendre que « audité trois fois » n’est pas la même chose que « audité contre le bon modèle de menace ». Un relecteur qui vérifie la logique des contraintes peut passer à côté d’une hypothèse structurelle qui cesse silencieusement de tenir. C’est plus difficile à détecter qu’un bogue de code classique, et ce n’est pas propre à Dusk — le même schéma a été mis au jour indépendamment dans Jellyfish d’Espresso.
La prochaine chose que je vérifierais : si la volonté de Dusk de pousser une spécification standardisée de vérification PLONK est effectivement livrée, ou si elle reste un simple fil de discussion.