J’ai vu ce film suffisamment de fois pour suspecter chaque fois qu’une blockchain affirme avoir résolu à la fois la sécurité et les performances sans rien sacrifier.
Ce qui m’a marqué avec Dusk, c’est Piecrust. J’y suis allé en partant du raisonnement habituel : garder le calcul à l’intérieur du bac à sable WASM, car l’isolation fait partie de l’histoire de la sécurité. Ensuite, j’ai découvert que Dusk emprunte une autre voie. La VM exécute toujours des contrats WASM, mais certains calculs cryptographiques lourds sont exposés via des fonctions côté hôte, au lieu d’imposer que tout passe par le bac à sable. Dusk décrit lui-même Piecrust comme une VM WASM avec un support natif pour les opérations ZK, et la documentation actuelle présente encore DuskVM autour de la confidentialité et de l’exécution à connaissance nulle.
Honnêtement, je comprends pourquoi. Si le hachage, les vérifications de signatures et la validation des preuves font partie de ce que vous continuez à faire, payer la surcharge de virtualisation à chaque fois semble inutile. L’exécution native devrait être plus rapide. Mais la vitesse n’est jamais gratuite en crypto. Vous payez ailleurs.
C’est là-dessus que je bloque encore. Une fonction d’hôte devient une partie de la frontière de confiance. La question ne se limite donc plus à « la VM est-elle sécurisée ? » : elle devient « à quel point tout ce que la VM est autorisée à appeler est-il sécurisé ? »
Je n’y fais pas encore pleinement confiance, mais je ne pense pas non plus que la conception soit imprudente. Après avoir regardé assez de chaînes sacrifier des performances exploitables pour préserver une théorie propre de la décentralisation, je me suis mis à m’intéresser davantage aux systèmes qui reconnaissent qu’il existe des compromis.
Peut-être que c’est ce qui donne cette impression de différence ici. Pas que Dusk ait trouvé une réponse parfaite, mais plutôt que le système semble disposé à assumer publiquement le choix d’ingénierie inconfortable.
@Dusk $DUSK #dusk
Ce qui m’a marqué avec Dusk, c’est Piecrust. J’y suis allé en partant du raisonnement habituel : garder le calcul à l’intérieur du bac à sable WASM, car l’isolation fait partie de l’histoire de la sécurité. Ensuite, j’ai découvert que Dusk emprunte une autre voie. La VM exécute toujours des contrats WASM, mais certains calculs cryptographiques lourds sont exposés via des fonctions côté hôte, au lieu d’imposer que tout passe par le bac à sable. Dusk décrit lui-même Piecrust comme une VM WASM avec un support natif pour les opérations ZK, et la documentation actuelle présente encore DuskVM autour de la confidentialité et de l’exécution à connaissance nulle.
Honnêtement, je comprends pourquoi. Si le hachage, les vérifications de signatures et la validation des preuves font partie de ce que vous continuez à faire, payer la surcharge de virtualisation à chaque fois semble inutile. L’exécution native devrait être plus rapide. Mais la vitesse n’est jamais gratuite en crypto. Vous payez ailleurs.
C’est là-dessus que je bloque encore. Une fonction d’hôte devient une partie de la frontière de confiance. La question ne se limite donc plus à « la VM est-elle sécurisée ? » : elle devient « à quel point tout ce que la VM est autorisée à appeler est-il sécurisé ? »
Je n’y fais pas encore pleinement confiance, mais je ne pense pas non plus que la conception soit imprudente. Après avoir regardé assez de chaînes sacrifier des performances exploitables pour préserver une théorie propre de la décentralisation, je me suis mis à m’intéresser davantage aux systèmes qui reconnaissent qu’il existe des compromis.
Peut-être que c’est ce qui donne cette impression de différence ici. Pas que Dusk ait trouvé une réponse parfaite, mais plutôt que le système semble disposé à assumer publiquement le choix d’ingénierie inconfortable.
@Dusk $DUSK #dusk
