Le résultat le plus dangereux n’est pas forcément des nœuds qui se battent entre eux, mais le fait que tous les nœuds appellent le même jeu de code de vérification, puis vérifient, de manière parfaitement ordonnée, le mauvais.
J’ai comparé le livre blanc historique de @Dusk et la documentation actuelle. Les anciens documents appellent ce runtime Rust/WASM « Piecrust », tandis que la documentation en vigueur utilise « DuskVM ». Le nom a évolué, mais le design clé reste le même : les contrats peuvent confier des vérifications cryptographiques comme PLONK, Groth16, BLS, etc., à la couche hôte via des entrées publiques, sans avoir à les implémenter chacun de leur côté.
Les bénéfices sont très concrets. Les développeurs écrivent moins un ensemble de code cryptographique sujet aux erreurs, et les nœuds n’ont pas besoin de répéter, dans le bac à sable WASM, les calculs de bas niveau : l’application est plus légère, et les règles de validation sont plus faciles à uniformiser.
Le coût est aussi concentré. Un contrat applicatif qui se trompe nuit d’abord à lui-même ; en revanche, si un vérificateur partagé se trompe dans le parsing des entrées, le choix de version ou les conditions aux limites, tous les contrats qui en dépendent peuvent être affectés. À l’échelle du réseau, tout le monde exécute la même règle : on ne peut alors démontrer que cela.
Lors de la mise à niveau Aegis de Dusk en mars 2026, le système a activé PLONK V3 et le nouveau comportement BLS ; la requête d’hôte BLS utilisée par les contrats bascule aussi en fonction de la hauteur de bloc. Les blocs historiques appellent l’ancien vérificateur, tandis que les nouvelles données utilisent la nouvelle version. Si la hauteur est mal choisie, on peut alors parvenir à des conclusions différentes sur la validité des transactions.
C’est pourquoi je ne me contenterai pas de compter les rapports d’audit : je surveillerai aussi la version du vérificateur, la hauteur de mise à niveau, les vecteurs de test, l’invalidation du cache et les exercices de rollback. $DUSK supporte le Gas et la sécurité du consensus, mais il y a aussi ces entrées publiques de validation qui tiennent les applications financières. La vitesse détermine à quelle vitesse un système peut tourner, et le vérificateur détermine s’il fera aussi tourner plus vite des erreurs.
#dusk
J’ai comparé le livre blanc historique de @Dusk et la documentation actuelle. Les anciens documents appellent ce runtime Rust/WASM « Piecrust », tandis que la documentation en vigueur utilise « DuskVM ». Le nom a évolué, mais le design clé reste le même : les contrats peuvent confier des vérifications cryptographiques comme PLONK, Groth16, BLS, etc., à la couche hôte via des entrées publiques, sans avoir à les implémenter chacun de leur côté.
Les bénéfices sont très concrets. Les développeurs écrivent moins un ensemble de code cryptographique sujet aux erreurs, et les nœuds n’ont pas besoin de répéter, dans le bac à sable WASM, les calculs de bas niveau : l’application est plus légère, et les règles de validation sont plus faciles à uniformiser.
Le coût est aussi concentré. Un contrat applicatif qui se trompe nuit d’abord à lui-même ; en revanche, si un vérificateur partagé se trompe dans le parsing des entrées, le choix de version ou les conditions aux limites, tous les contrats qui en dépendent peuvent être affectés. À l’échelle du réseau, tout le monde exécute la même règle : on ne peut alors démontrer que cela.
Lors de la mise à niveau Aegis de Dusk en mars 2026, le système a activé PLONK V3 et le nouveau comportement BLS ; la requête d’hôte BLS utilisée par les contrats bascule aussi en fonction de la hauteur de bloc. Les blocs historiques appellent l’ancien vérificateur, tandis que les nouvelles données utilisent la nouvelle version. Si la hauteur est mal choisie, on peut alors parvenir à des conclusions différentes sur la validité des transactions.
C’est pourquoi je ne me contenterai pas de compter les rapports d’audit : je surveillerai aussi la version du vérificateur, la hauteur de mise à niveau, les vecteurs de test, l’invalidation du cache et les exercices de rollback. $DUSK supporte le Gas et la sécurité du consensus, mais il y a aussi ces entrées publiques de validation qui tiennent les applications financières. La vitesse détermine à quelle vitesse un système peut tourner, et le vérificateur détermine s’il fera aussi tourner plus vite des erreurs.
#dusk
