Je lance un petit script Python sur mon ordinateur portable à Islamabad qui effectue des hachages intensifs pour un projet annexe, et j’ai une fois essayé de le déplacer dans un environnement sandboxé en pensant que ça tournerait tout aussi vite puisque la logique ne changeait pas. C’était nettement plus lent, et avant de lire à propos du VM de Piecrust de Dusk, je n’avais jamais compris pourquoi cela arrive au niveau technique.
Je supposais que l’exécution des smart contracts à l’intérieur d’une machine virtuelle WASM tourne à peu près à la vitesse native, puisque le WASM est généralement présenté comme offrant des performances proches du natif. Ce n’est pas exact pour les opérations cryptographiques en particulier. Des recherches citées dans le livre blanc indiquent que l’exécution WASM peut être de 45 à 255 % plus lente que du code natif pour des applications complexes, principalement à cause de la gestion de mémoire virtualisée et du traitement supplémentaire d’instructions dans la sandbox.
C’est précisément pour cela que Piecrust ne fait exécuter en aucun cas, à l’intérieur de la sandbox WASM, des opérations comme la vérification de preuves ZK, le hachage ou les vérifications de signatures. Il expose plutôt des fonctions hôtes : des appels natifs directs pour des opérations comme hash, verify_plonk, verify_groth16_bn254, verify_schnorr et verify_bls. Le contrat appelle du code natif pour le travail cryptographique coûteux, puis revient dans le WASM pour le reste. Il s’agit d’une séparation d’architecture délibérée, pas d’un contournement.
Ce que le livre blanc reconnaît directement, c’est que Dusk n’a pas encore quantifié les économies de puissance réelles obtenues grâce à cette configuration. Je ne peux donc pas te donner un chiffre d’efficacité fiable, car Dusk lui-même n’en a pas publié.
Le vrai test pour DUSK, c’est de savoir si cette approche par fonctions hôtes continue de tenir à mesure que la complexité des contrats augmente sur le mainnet.
Quelqu’un a-t-il déjà comparé/benchmarqué les appels de fonctions hôtes de Piecrust par rapport à une exécution WASM pure ?
@Dusk #dusk $DUSK
Je supposais que l’exécution des smart contracts à l’intérieur d’une machine virtuelle WASM tourne à peu près à la vitesse native, puisque le WASM est généralement présenté comme offrant des performances proches du natif. Ce n’est pas exact pour les opérations cryptographiques en particulier. Des recherches citées dans le livre blanc indiquent que l’exécution WASM peut être de 45 à 255 % plus lente que du code natif pour des applications complexes, principalement à cause de la gestion de mémoire virtualisée et du traitement supplémentaire d’instructions dans la sandbox.
C’est précisément pour cela que Piecrust ne fait exécuter en aucun cas, à l’intérieur de la sandbox WASM, des opérations comme la vérification de preuves ZK, le hachage ou les vérifications de signatures. Il expose plutôt des fonctions hôtes : des appels natifs directs pour des opérations comme hash, verify_plonk, verify_groth16_bn254, verify_schnorr et verify_bls. Le contrat appelle du code natif pour le travail cryptographique coûteux, puis revient dans le WASM pour le reste. Il s’agit d’une séparation d’architecture délibérée, pas d’un contournement.
Ce que le livre blanc reconnaît directement, c’est que Dusk n’a pas encore quantifié les économies de puissance réelles obtenues grâce à cette configuration. Je ne peux donc pas te donner un chiffre d’efficacité fiable, car Dusk lui-même n’en a pas publié.
Le vrai test pour DUSK, c’est de savoir si cette approche par fonctions hôtes continue de tenir à mesure que la complexité des contrats augmente sur le mainnet.
Quelqu’un a-t-il déjà comparé/benchmarqué les appels de fonctions hôtes de Piecrust par rapport à une exécution WASM pure ?
@Dusk #dusk $DUSK
