#dusk $DUSK
L’expression « fonctions hôtes » revenait constamment dans le livre blanc de Dusk, et je continuais à la traiter comme un détail d’implémentation. En lisant réellement la section sur les performances, j’ai compris que c’était plutôt une décision architecturale plus délibérée que je ne l’avais cru.
Exécuter ZK dans une VM WASM : le livre blanc cite des recherches montrant que l’exécution WASM peut être 45 à 255 % plus lente que le code natif pour des applications complexes. La surcharge vient de la gestion de la mémoire virtualisée et du traitement supplémentaire des instructions dans un environnement cloisonné (sandbox). Pour le hachage et la validation de signatures, c’est ennuyeux. Pour la vérification de preuves ZK, qui s’exécute à chaque transaction, un ralentissement de 45 à 255 % constitue un problème de débit (throughput) important.
Fonctions hôtes : Dusk expose un ensemble de fonctions qui s’exécutent nativement sur la machine hôte, en dehors du bac à sable WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls et hash. Le smart contract les appelle directement ; le gros du travail cryptographique s’exécute à la vitesse native. Le résultat est répliqué entre les nœuds de la même manière que toute autre opération de calcul.
Alors, pourquoi chaque chaîne qui exécute ZK ne fait pas cela.
Déplacer le calcul hors de la VM réduit la garantie de cloisonnement (sandboxing). Dans un modèle d’exécution WASM pur, un contrat buggy ou malveillant est isolé à l’intérieur des limites de la VM. Lorsque vous ajoutez des fonctions hôtes, vous offrez un accès de niveau natif à des opérations spécifiques — et un bug ou une mauvaise configuration au niveau des fonctions hôtes peut avoir des conséquences qu’un contrat sandboxé ne pourrait pas produire seul. Vous échangez l’isolation contre le débit.
Je trouve en fait l’argument d’efficacité énergétique plus intéressant que celui de la vitesse : le livre blanc présente partiellement les fonctions hôtes comme un moyen de réduire les coûts énergétiques par nœud, pas seulement la latence. C’est un cadrage inhabituel pour un document de conception d’une blockchain.
Ce que je n’ai toutefois pas vu expliqué, c’est comment Dusk gère la version des fonctions hôtes : savoir si une modification du comportement d’une fonction hôte constitue un changement de protocole nécessitant un consensus, ou si les opérateurs peuvent mettre à jour les implémentations de manière indépendante. @Dusk
$DUSK #dusk
L’expression « fonctions hôtes » revenait constamment dans le livre blanc de Dusk, et je continuais à la traiter comme un détail d’implémentation. En lisant réellement la section sur les performances, j’ai compris que c’était plutôt une décision architecturale plus délibérée que je ne l’avais cru.
Exécuter ZK dans une VM WASM : le livre blanc cite des recherches montrant que l’exécution WASM peut être 45 à 255 % plus lente que le code natif pour des applications complexes. La surcharge vient de la gestion de la mémoire virtualisée et du traitement supplémentaire des instructions dans un environnement cloisonné (sandbox). Pour le hachage et la validation de signatures, c’est ennuyeux. Pour la vérification de preuves ZK, qui s’exécute à chaque transaction, un ralentissement de 45 à 255 % constitue un problème de débit (throughput) important.
Fonctions hôtes : Dusk expose un ensemble de fonctions qui s’exécutent nativement sur la machine hôte, en dehors du bac à sable WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls et hash. Le smart contract les appelle directement ; le gros du travail cryptographique s’exécute à la vitesse native. Le résultat est répliqué entre les nœuds de la même manière que toute autre opération de calcul.
Alors, pourquoi chaque chaîne qui exécute ZK ne fait pas cela.
Déplacer le calcul hors de la VM réduit la garantie de cloisonnement (sandboxing). Dans un modèle d’exécution WASM pur, un contrat buggy ou malveillant est isolé à l’intérieur des limites de la VM. Lorsque vous ajoutez des fonctions hôtes, vous offrez un accès de niveau natif à des opérations spécifiques — et un bug ou une mauvaise configuration au niveau des fonctions hôtes peut avoir des conséquences qu’un contrat sandboxé ne pourrait pas produire seul. Vous échangez l’isolation contre le débit.
Je trouve en fait l’argument d’efficacité énergétique plus intéressant que celui de la vitesse : le livre blanc présente partiellement les fonctions hôtes comme un moyen de réduire les coûts énergétiques par nœud, pas seulement la latence. C’est un cadrage inhabituel pour un document de conception d’une blockchain.
Ce que je n’ai toutefois pas vu expliqué, c’est comment Dusk gère la version des fonctions hôtes : savoir si une modification du comportement d’une fonction hôte constitue un changement de protocole nécessitant un consensus, ou si les opérateurs peuvent mettre à jour les implémentations de manière indépendante. @Dusk
$DUSK #dusk
