Lorsque j’ai consulté la documentation officielle de Dusk, il y a une phrase que j’ai relue deux fois avant de comprendre : la couche d’exécution de DuskEVM utilise une architecture OP Stack — le sequencer lance op-geth pour exécuter les transactions EVM, le batcher publie les données des transactions sous forme de blob sur DuskDS, puis le proposer publie les engagements d’état en se référant à ces lots déjà exécutés. En clair, DuskEVM est essentiellement une couche 2 ; c’est DuskDS (la couche de règlement L1 de Dusk) qui constitue son socle d’« availability » des données et de règlement final.
Ce choix d’architecture est plutôt malin.
Le cadre natif de contrats intelligents de Dusk est DuskVM, qui tourne sur la machine virtuelle WASM de Piecrust (écrite en Rust) — pour les développeurs qui veulent utiliser directement Rust/WASM, et qui ont besoin d’actifs au niveau protocolaire et de capacités de preuve à connaissance nulle. À l’inverse, DuskEVM s’adresse aux équipes qui veulent tirer parti d’une chaîne d’outils Solidity existante et ne pas avoir à apprendre quelque chose de nouveau. Double approche, au lieu d’imposer à tout le monde de changer de langage.
Les récentes versions de Piecrust ajoutent aussi la prise en charge de memory64 et remplacent le runtime sous-jacent de wasmer par wasmtime : tout cela vise à préparer des contrats avec un état et une exécution à plus grande échelle.
Ce qui mérite vraiment d’être creusé, c’est la structure des frais : sur DuskEVM, les transactions nécessitent de payer deux postes. D’une part, des frais d’exécution de type EIP-1559 pour la couche 2 ; d’autre part, des frais d’« availability » des données pour publier les données de batch sur DuskDS. Cela signifie que le débit réel et le coût de DuskEVM sont, au final, encore bridés par la capacité d’« availability » des données de cette L1 qu’est DuskDS — même si la couche d’exécution L2 est rapide, si la couche de règlement de base est encombrée, on ne peut pas aller plus loin.
C’est très similaire à la plupart des blockchains L2 qui s’appuient sur Ethereum pour la DA : la différence n’est que le fait de remplacer Ethereum par la L1 de Dusk.
Pour les développeurs qui prévoient de déployer des contrats sur DuskEVM, ce détail d’architecture n’est pas un simple arrière-plan : il détermine directement, dans votre modèle de coût en Gas, si les frais DA constitueront une part plus importante que les frais d’exécution — en particulier pour des applications financières à haute fréquence et avec de grandes quantités de données.
@Dusk $DUSK #dusk
Ce choix d’architecture est plutôt malin.
Le cadre natif de contrats intelligents de Dusk est DuskVM, qui tourne sur la machine virtuelle WASM de Piecrust (écrite en Rust) — pour les développeurs qui veulent utiliser directement Rust/WASM, et qui ont besoin d’actifs au niveau protocolaire et de capacités de preuve à connaissance nulle. À l’inverse, DuskEVM s’adresse aux équipes qui veulent tirer parti d’une chaîne d’outils Solidity existante et ne pas avoir à apprendre quelque chose de nouveau. Double approche, au lieu d’imposer à tout le monde de changer de langage.
Les récentes versions de Piecrust ajoutent aussi la prise en charge de memory64 et remplacent le runtime sous-jacent de wasmer par wasmtime : tout cela vise à préparer des contrats avec un état et une exécution à plus grande échelle.
Ce qui mérite vraiment d’être creusé, c’est la structure des frais : sur DuskEVM, les transactions nécessitent de payer deux postes. D’une part, des frais d’exécution de type EIP-1559 pour la couche 2 ; d’autre part, des frais d’« availability » des données pour publier les données de batch sur DuskDS. Cela signifie que le débit réel et le coût de DuskEVM sont, au final, encore bridés par la capacité d’« availability » des données de cette L1 qu’est DuskDS — même si la couche d’exécution L2 est rapide, si la couche de règlement de base est encombrée, on ne peut pas aller plus loin.
C’est très similaire à la plupart des blockchains L2 qui s’appuient sur Ethereum pour la DA : la différence n’est que le fait de remplacer Ethereum par la L1 de Dusk.
Pour les développeurs qui prévoient de déployer des contrats sur DuskEVM, ce détail d’architecture n’est pas un simple arrière-plan : il détermine directement, dans votre modèle de coût en Gas, si les frais DA constitueront une part plus importante que les frais d’exécution — en particulier pour des applications financières à haute fréquence et avec de grandes quantités de données.
@Dusk $DUSK #dusk