Honnêtement, je n’ai cessé de regarder un seul petit mot à la page dix-neuf… « compact ». Il apparaît deux fois dans le même paragraphe qui décrit Piecrust, et quelque chose dans cette répétition m’a fait m’arrêter plus longtemps que je ne l’avais prévu.
Piecrust est la machine virtuelle WASM de Dusk, construite principalement en Rust, et elle se divise en deux parties. Le crate piecrust fonctionne comme la vraie VM, tandis que piecrust-uplink est la boîte à outils que les développeurs utilisent pour construire, tester et déployer des contrats. En le lisant, l’accent mis sur la modularité a continué de ressortir, l’idée que la VM peut s’étendre et se mettre à jour plus tard « sans révisions majeures ». C’est un objectif de conception raisonnable pour une chaîne encore au début de son cycle de vie.
Mais attendez : si la compacité et l’exécution légère sont la priorité, qu’en est-il de la logique de contrat complexe ? Un module « compact », par définition, fait un compromis sur quelque chose, et le livre blanc ne dit jamais vraiment ce que c’est. Est-ce l’expressivité ? Le temps de compilation ? La flexibilité du développeur une fois que les contrats dépassent les cas d’usage simples ? J’ai relu cette section en espérant une réponse concrète et je n’en ai pas trouvé.
Je pense toutefois que piecrust-uplink résout un problème réel : offrir aux développeurs un environnement contrôlé pour vérifier la justesse avant de toucher au mainnet est vraiment utile, pas juste une fonctionnalité à cocher. Cette partie se lit comme une ingénierie réfléchie, pas comme un langage marketing.
D’abord, je ne rejette pas la conception : je remarque simplement que « modulaire » et « léger » sonnent très bien sur le papier jusqu’à ce que la complexité réelle des contrats les mette à l’épreuve. Est-ce que Piecrust parvient à maintenir cet équilibre quand l’écosystème de Dusk deviendra plus animé… cette partie, je ne peux pas encore y répondre 🧐
Je continue à lire, à y réfléchir 📖
#dusk $DUSK @Dusk
$TUT
$UP