#dusk $DUSK @Dusk
En générant la preuve localement pour mesurer les performances du circuit, j’ai remarqué quelque chose qui m’a fait revenir lire les notes techniques de l’équipe cryptographie plutôt que les pages marketing.
Les chiffres réels de PLONK sont ce qui permet de défendre le dossier de conformité, pas seulement l’angle confidentialité. Le temps de vérification reste autour de 6 à 9 millisecondes, quelle que soit la taille du circuit — le temps de génération évolue avec la complexité du circuit (environ 5,46 secondes pour un circuit de 2^16 portes sur du matériel modestе), mais le côté vérificateur reste rapide et constant. Cette asymétrie compte davantage pour la finance réglementée que ce que les gens veulent bien reconnaître : un auditeur ou une contrepartie qui vérifie une preuve ne brûle pas de calcul significatif à chaque fois, même lorsque la logique sous-jacente de la transaction devient plus complexe.
Ce que je n’avais pas anticipé, c’est que PLONK lui-même avait une vulnérabilité réelle et divulguée, pas seulement un risque théorique. L’équipe de recherche de Dusk a mis au jour un problème critique dans la manière dont la transformation Fiat-Shamir était implémentée — la partie qui transforme une preuve interactive en preuve non interactive en hachant les défis au lieu de laisser un vérificateur en ligne les envoyer. L’implémentation initiale n’a pas haché les entrées publiques assez tôt, ce qui a affaibli la garantie de solidité. Trail of Bits a coordonné la divulgation, Dusk l’a corrigée avant le mainnet, et a publié le correctif au lieu de le garder.
C’est ce détail qui continue de me marquer : une chaîne orientée conformité construite sur un système de preuve cryptographique qui comportait un vrai bogue de solidité dans un code proche de la production, détecté et corrigé avant que cela ne devienne réellement problématique. Je ne sais pas combien d’autres implémentations utilisant PLONK ailleurs étaient encore vulnérables lorsque cette information est devenue publique, ni combien de temps il s’est écoulé entre la divulgation et la mise à jour des autres projets sur leurs propres forks.
En générant la preuve localement pour mesurer les performances du circuit, j’ai remarqué quelque chose qui m’a fait revenir lire les notes techniques de l’équipe cryptographie plutôt que les pages marketing.
Les chiffres réels de PLONK sont ce qui permet de défendre le dossier de conformité, pas seulement l’angle confidentialité. Le temps de vérification reste autour de 6 à 9 millisecondes, quelle que soit la taille du circuit — le temps de génération évolue avec la complexité du circuit (environ 5,46 secondes pour un circuit de 2^16 portes sur du matériel modestе), mais le côté vérificateur reste rapide et constant. Cette asymétrie compte davantage pour la finance réglementée que ce que les gens veulent bien reconnaître : un auditeur ou une contrepartie qui vérifie une preuve ne brûle pas de calcul significatif à chaque fois, même lorsque la logique sous-jacente de la transaction devient plus complexe.
Ce que je n’avais pas anticipé, c’est que PLONK lui-même avait une vulnérabilité réelle et divulguée, pas seulement un risque théorique. L’équipe de recherche de Dusk a mis au jour un problème critique dans la manière dont la transformation Fiat-Shamir était implémentée — la partie qui transforme une preuve interactive en preuve non interactive en hachant les défis au lieu de laisser un vérificateur en ligne les envoyer. L’implémentation initiale n’a pas haché les entrées publiques assez tôt, ce qui a affaibli la garantie de solidité. Trail of Bits a coordonné la divulgation, Dusk l’a corrigée avant le mainnet, et a publié le correctif au lieu de le garder.
C’est ce détail qui continue de me marquer : une chaîne orientée conformité construite sur un système de preuve cryptographique qui comportait un vrai bogue de solidité dans un code proche de la production, détecté et corrigé avant que cela ne devienne réellement problématique. Je ne sais pas combien d’autres implémentations utilisant PLONK ailleurs étaient encore vulnérables lorsque cette information est devenue publique, ni combien de temps il s’est écoulé entre la divulgation et la mise à jour des autres projets sur leurs propres forks.