J’ai passé une heure à retracer l’activation PLONK V3 de Dusk au bloc 3,590,904, puis une ligne de sécurité liée à un wallet m’a arraché au dépôt ; le dépôt dit qu’aucun audit externe n’a encore été réalisé.
Cela ne rend pas la cryptographie de Dusk faible. Cela signifie simplement que des talents cryptographiques sérieux sont une mauvaise métrique de surface.
Un vérificateur de preuve peut rejeter des points mal formés incompatibles avec les entrées publiques et des circuits compressés parfaitement, tandis que la transaction de l’utilisateur dépend encore du code d’extension, de la dérivation du mot de passe, des autorisations mémoire JavaScript, de l’endpoint du nœud et de l’invite de signature.
L’extension utilise PBKDF2 avec 900 000 itérations et AES-GCM-256 ; le chemin natif utilise Stronghold avec Argon2. Des chemins différents impliquent des hypothèses de confiance différentes.
Donc je mesurerais le comportement : combien de builds indépendants génèrent des vérificateurs Solidity identiques octet pour octet ? Quelle preuve mal formée consomme le plus de gaz avant d’être rejetée ? L’interface CLI expose-t-elle le même avertissement au destinataire concerné que Web Wallet ? Et le chemin de signature a-t-il reçu une analyse comparable à PLONK ?
Une certaine asymétrie est normale. Les wallets de navigateur ne peuvent pas garantir la remise à zéro de la mémoire JavaScript, et un déploiement plus simple du vérificateur a de la valeur même si le coût en gaz ne baisse pas.
Mais la sécurité institutionnelle de Dusk sera déterminée par l’élément le plus faible de l’autorité responsable, et non par ses mathématiques les plus élégantes. Je surveille si les audits suivent le parcours de la transaction de bout en bout.
#dusk $DUSK @Dusk
Cela ne rend pas la cryptographie de Dusk faible. Cela signifie simplement que des talents cryptographiques sérieux sont une mauvaise métrique de surface.
Un vérificateur de preuve peut rejeter des points mal formés incompatibles avec les entrées publiques et des circuits compressés parfaitement, tandis que la transaction de l’utilisateur dépend encore du code d’extension, de la dérivation du mot de passe, des autorisations mémoire JavaScript, de l’endpoint du nœud et de l’invite de signature.
L’extension utilise PBKDF2 avec 900 000 itérations et AES-GCM-256 ; le chemin natif utilise Stronghold avec Argon2. Des chemins différents impliquent des hypothèses de confiance différentes.
Donc je mesurerais le comportement : combien de builds indépendants génèrent des vérificateurs Solidity identiques octet pour octet ? Quelle preuve mal formée consomme le plus de gaz avant d’être rejetée ? L’interface CLI expose-t-elle le même avertissement au destinataire concerné que Web Wallet ? Et le chemin de signature a-t-il reçu une analyse comparable à PLONK ?
Une certaine asymétrie est normale. Les wallets de navigateur ne peuvent pas garantir la remise à zéro de la mémoire JavaScript, et un déploiement plus simple du vérificateur a de la valeur même si le coût en gaz ne baisse pas.
Mais la sécurité institutionnelle de Dusk sera déterminée par l’élément le plus faible de l’autorité responsable, et non par ses mathématiques les plus élégantes. Je surveille si les audits suivent le parcours de la transaction de bout en bout.
#dusk $DUSK @Dusk