Lorsque les ingénieurs de Dusk Network ont dû décider comment les contrats devaient réellement s’exécuter, ils n’ont pas choisi le raccourci évident. La plupart des nouvelles chaînes Layer-1 lancées ces dernières années ont livré, dès le premier jour, une compatibilité EVM, pariant que la familiarité avec Solidity pèserait plus lourd que tout coût technique. Dusk Network a d’abord construit sa propre machine virtuelle : Piecrust, un environnement d’exécution basé sur WASM, avec une prise en charge native des opérations à preuve à divulgation nulle comme les vérifications PLONK et Groth16, ainsi qu’un modèle d’état basé sur des deltas qui ne conserve que ce qui a réellement changé, au lieu de réécrire l’état complet à chaque bloc.

C’est un chemin plus difficile et plus lent. C’est aussi le seul chemin qui a permis aux contrats de Dusk Network d’être natifs à la preuve à divulgation nulle, plutôt qu’« à proximité » de celle-ci, car les environnements EVM standard n’ont pas été conçus pour la vérification de preuves confidentielles comme opération de premier plan. Le compromis, c’était la familiarité développeur : la plupart des ingénieurs connaissent Solidity, beaucoup moins connaissent Rust et les macros de contrats de Dusk Network — et c’est un coût réel que l’équipe a accepté en connaissance de cause.

Ce qui est intéressant, c’est que Dusk Network n’est pas resté définitivement attaché à ce compromis. DuskEVM est arrivé comme un deuxième environnement d’exécution, entièrement équivalent à l’EVM, et s’appuyant sur la même couche sous-jacente DuskDS que les contrats basés sur Piecrust, avec un pont natif sans confiance et des outils standard que les développeurs connaissent déjà. Au lieu de choisir un seul modèle d’exécution et de forcer tous les cas d’usage à passer par celui-ci, Dusk Network a séparé totalement le règlement de l’exécution, permettant aux applications nativement orientées confidentialité de vivre sur Piecrust et aux équipes « natives Ethereum » de vivre sur DuskEVM, les deux héritant des mêmes garanties de consensus et de finalité sous-jacentes.

Je pense que cette séquence était le bon choix : construire d’abord la chose la plus difficile et la plus différenciée, puis ajouter l’accès familier une fois la base en place. Le fait que deux environnements d’exécution fragmentent la liquidité et l’attention plutôt que d’ajouter de la flexibilité est encore une question de design ouverte que personne en dehors de Dusk Network ne peut pleinement trancher pour l’instant.

#dusk $DUSK @Dusk