#dusk $DUSK @Dusk #dusk $DUSK @Dusk
Voici une décision de conception sur Dusk que je n’avais jamais vue formulée correctement nulle part.
DuskVM exécute des contrats Rust/WASM sur Wasmtime, directement sur la L1. Très bien, c’est un choix de pile. La partie que je trouve plus intéressante est ce que le nœud expose à ces contrats.
Vérifier une preuve à connaissance nulle à l’intérieur d’un contrat, instruction par instruction, est extrêmement coûteux. Alors Dusk l’a fait descendre d’un niveau : rusk-abi fournit aux contrats des fonctions hôtes pour la vérification des preuves, y compris verify_groth16. L’hôte prend actuellement en charge deux systèmes de preuve — Groth16 et PLONK.
C’est une capacité réelle. Cela signifie qu’un contrat sur Dusk peut accepter une preuve ZK en entrée et la vérifier à un coût proche du natif. Sur la plupart des chaînes, c’est soit impossible, soit destructeur financièrement.
Mais notez aussi ce que cela implique. L’ensemble des systèmes de preuve disponibles pour vous, en tant que constructeur, est fixé au niveau du protocole : il n’est pas choisi par votre application. Vous voulez un schéma différent parce que votre circuit s’y prête mieux ? Vous demandez un changement de protocole, pas l’import d’une bibliothèque.
Voilà le compromis en une phrase : la vérification au niveau de l’hôte vous apporte le coût, et vous fait payer en optionnalité.
Pour une chaîne visant la finance réglementée, je pense que c’est justement le bon côté du compromis. Le logiciel institutionnel veut un petit ensemble de primitives auditées et stables — pas cinquante dialectes cryptographiques. Mais cela signifie aussi que l’équipe protocole, et non le marché, décide de quelle cryptographie l’écosystème peut construire ; et cette décision s’accumule au fil des années.
Il vaut aussi la peine de se rappeler que la VM elle-même a sa propre historique d’audit — Piecrust a été revu en juillet 2024, avant que la plupart de l’architecture actuelle n’existe.
Faut-il que les systèmes de preuve soient des primitives de niveau protocole partagées par tous, ou des choix au niveau des applications que chaque équipe fait pour elle-même ?
Voici une décision de conception sur Dusk que je n’avais jamais vue formulée correctement nulle part.
DuskVM exécute des contrats Rust/WASM sur Wasmtime, directement sur la L1. Très bien, c’est un choix de pile. La partie que je trouve plus intéressante est ce que le nœud expose à ces contrats.
Vérifier une preuve à connaissance nulle à l’intérieur d’un contrat, instruction par instruction, est extrêmement coûteux. Alors Dusk l’a fait descendre d’un niveau : rusk-abi fournit aux contrats des fonctions hôtes pour la vérification des preuves, y compris verify_groth16. L’hôte prend actuellement en charge deux systèmes de preuve — Groth16 et PLONK.
C’est une capacité réelle. Cela signifie qu’un contrat sur Dusk peut accepter une preuve ZK en entrée et la vérifier à un coût proche du natif. Sur la plupart des chaînes, c’est soit impossible, soit destructeur financièrement.
Mais notez aussi ce que cela implique. L’ensemble des systèmes de preuve disponibles pour vous, en tant que constructeur, est fixé au niveau du protocole : il n’est pas choisi par votre application. Vous voulez un schéma différent parce que votre circuit s’y prête mieux ? Vous demandez un changement de protocole, pas l’import d’une bibliothèque.
Voilà le compromis en une phrase : la vérification au niveau de l’hôte vous apporte le coût, et vous fait payer en optionnalité.
Pour une chaîne visant la finance réglementée, je pense que c’est justement le bon côté du compromis. Le logiciel institutionnel veut un petit ensemble de primitives auditées et stables — pas cinquante dialectes cryptographiques. Mais cela signifie aussi que l’équipe protocole, et non le marché, décide de quelle cryptographie l’écosystème peut construire ; et cette décision s’accumule au fil des années.
Il vaut aussi la peine de se rappeler que la VM elle-même a sa propre historique d’audit — Piecrust a été revu en juillet 2024, avant que la plupart de l’architecture actuelle n’existe.
Faut-il que les systèmes de preuve soient des primitives de niveau protocole partagées par tous, ou des choix au niveau des applications que chaque équipe fait pour elle-même ?