@Dusk
Quelque part dans la conception de Piecrust, il y a une admission discrète : le bac à sable n’est pas le bon endroit pour tout.
Les contrats s’exécutent en WebAssembly, ce qui donne au VM son environnement d’exécution contrôlé.
Ce qui est intéressant, c’est à quel point une grande partie du travail lourd ne touche même pas cet environnement WASM.
Le hachage est calculé nativement.
Il en va de même pour la vérification des preuves ZK, à la fois PlonK et Groth16.
Et pour les vérifications de signature aussi : Schnorr et BLS.
Tout cela ne tourne pas dans le bac à sable qui exécute le contrat.
La raison tient à un chiffre, et il est assez rude.
La recherche citée par Dusk indique que le WASM est quelque part entre 45 et 255 % plus lent que le code natif une fois que les opérations deviennent complexes. La vérification cryptographique est exactement le type de travail pour lequel cette différence compte.
Appliquer cette pénalité à chaque transaction n’était pas un compromis que Dusk était prêt à faire, donc ces opérations sont gérées via des fonctions hôtes natives à la place.
Voilà ce qui m’a frappé.
Les opérations qu’on retire ne sont pas aléatoires.
Le hachage, la vérification des preuves, les signatures : c’est une grande partie de la mécanique cryptographique dont des applications orientées confidentialité comme Phoenix et Zedger dépendent.
Le bac à sable gère la logique du contrat.
La partie des calculs liés à la confidentialité s’exécute ailleurs.
Du coup, il n’y a pas vraiment une seule frontière d’exécution. Il y a la frontière générale du VM, puis des sorties délibérées pour les opérations pour lesquelles l’exécution native est la plus importante.
Ce que je veux encore comprendre, c’est ce qui garantit que ce chemin natif reste déterministe sur chaque nœud. Le WASM vous donne un environnement d’exécution très explicite ; une fois qu’un contrat en sort pour appeler l’extérieur, quelles garanties font que chaque nœud arrive encore au même résultat exactement ?
$DUSK gets plus intéressant pour moi dès lors que cette question a une vraie réponse derrière elle, pas juste une fonction native qui fait le travail plus vite.
#dusk
Quelque part dans la conception de Piecrust, il y a une admission discrète : le bac à sable n’est pas le bon endroit pour tout.
Les contrats s’exécutent en WebAssembly, ce qui donne au VM son environnement d’exécution contrôlé.
Ce qui est intéressant, c’est à quel point une grande partie du travail lourd ne touche même pas cet environnement WASM.
Le hachage est calculé nativement.
Il en va de même pour la vérification des preuves ZK, à la fois PlonK et Groth16.
Et pour les vérifications de signature aussi : Schnorr et BLS.
Tout cela ne tourne pas dans le bac à sable qui exécute le contrat.
La raison tient à un chiffre, et il est assez rude.
La recherche citée par Dusk indique que le WASM est quelque part entre 45 et 255 % plus lent que le code natif une fois que les opérations deviennent complexes. La vérification cryptographique est exactement le type de travail pour lequel cette différence compte.
Appliquer cette pénalité à chaque transaction n’était pas un compromis que Dusk était prêt à faire, donc ces opérations sont gérées via des fonctions hôtes natives à la place.
Voilà ce qui m’a frappé.
Les opérations qu’on retire ne sont pas aléatoires.
Le hachage, la vérification des preuves, les signatures : c’est une grande partie de la mécanique cryptographique dont des applications orientées confidentialité comme Phoenix et Zedger dépendent.
Le bac à sable gère la logique du contrat.
La partie des calculs liés à la confidentialité s’exécute ailleurs.
Du coup, il n’y a pas vraiment une seule frontière d’exécution. Il y a la frontière générale du VM, puis des sorties délibérées pour les opérations pour lesquelles l’exécution native est la plus importante.
Ce que je veux encore comprendre, c’est ce qui garantit que ce chemin natif reste déterministe sur chaque nœud. Le WASM vous donne un environnement d’exécution très explicite ; une fois qu’un contrat en sort pour appeler l’extérieur, quelles garanties font que chaque nœud arrive encore au même résultat exactement ?
$DUSK gets plus intéressant pour moi dès lors que cette question a une vraie réponse derrière elle, pas juste une fonction native qui fait le travail plus vite.
#dusk
