Je suis retourné ce soir dans la documentation technique de @Dusk, et la conception de la VM est la partie à laquelle je n’arrête pas de penser.
Mon hypothèse de départ était simple : si le calcul s’effectue sur la chaîne, alors tout ce qui compte devrait rester dans la VM. Plus d’isolation signifie plus de sécurité.
Dusk emprunte une autre voie.
Avec Piecrust, des opérations cryptographiques coûteuses comme le hachage, la vérification de signatures et la vérification ZK peuvent être gérées via des fonctions natives de l’hôte au lieu d’être entièrement exécutées dans l’environnement WASM.
L’argument de performance est compréhensible. Si les mêmes opérations cryptographiques lourdes se produisent constamment, payer la surcouche de la VM à chaque fois peut devenir coûteux. L’exécution native peut supprimer une bonne partie de ces frictions.
Mais cela soulève aussi une question que je ne peux pas ignorer :
Dans quelle mesure fait-on confiance à ces fonctions d’hôte ?
Déplacer des opérations critiques en dehors du bac à sable peut améliorer l’efficacité, mais cela fait aussi de la couche native une partie de la frontière de sécurité. Cela signifie que la qualité d’implémentation, l’isolation et l’audit comptent soudain encore davantage.
Je ne dis pas que Dusk a fait le mauvais choix. Je pense au contraire que c’est un compromis intéressant.
Pour une chaîne axée sur la finance, préféreriez-vous maximiser l’isolation du bac à sable, ou accepter une couche native soigneusement contrôlée pour de bien meilleures performances ?
Je penche vers l’efficacité — mais seulement si les hypothèses de sécurité sont suffisamment solides.
#dusk $DUSK @Dusk
Mon hypothèse de départ était simple : si le calcul s’effectue sur la chaîne, alors tout ce qui compte devrait rester dans la VM. Plus d’isolation signifie plus de sécurité.
Dusk emprunte une autre voie.
Avec Piecrust, des opérations cryptographiques coûteuses comme le hachage, la vérification de signatures et la vérification ZK peuvent être gérées via des fonctions natives de l’hôte au lieu d’être entièrement exécutées dans l’environnement WASM.
L’argument de performance est compréhensible. Si les mêmes opérations cryptographiques lourdes se produisent constamment, payer la surcouche de la VM à chaque fois peut devenir coûteux. L’exécution native peut supprimer une bonne partie de ces frictions.
Mais cela soulève aussi une question que je ne peux pas ignorer :
Dans quelle mesure fait-on confiance à ces fonctions d’hôte ?
Déplacer des opérations critiques en dehors du bac à sable peut améliorer l’efficacité, mais cela fait aussi de la couche native une partie de la frontière de sécurité. Cela signifie que la qualité d’implémentation, l’isolation et l’audit comptent soudain encore davantage.
Je ne dis pas que Dusk a fait le mauvais choix. Je pense au contraire que c’est un compromis intéressant.
Pour une chaîne axée sur la finance, préféreriez-vous maximiser l’isolation du bac à sable, ou accepter une couche native soigneusement contrôlée pour de bien meilleures performances ?
Je penche vers l’efficacité — mais seulement si les hypothèses de sécurité sont suffisamment solides.
#dusk $DUSK @Dusk
