Le véritable avantage du modèle d’exécution dual de Dusk n’est pas la compatibilité EVM. C’est un choix architectural.
@Dusk sépare le règlement de l’exécution : DuskVM exécute directement des contrats Rust/WASM sur le Dusk L1, tandis que DuskEVM fournit une exécution compatible EVM avec le règlement et la disponibilité des données via DuskDS.
La conséquence plus profonde est que les développeurs peuvent choisir où appartient la logique applicative, au lieu de forcer chaque charge de travail dans un seul modèle d’exécution.
Si un contrat a besoin d’un accès direct au L1 aux modèles de transactions de Dusk, pour la confidentialité ou des capacités de preuve à divulgation nulle, DuskVM est la voie native. Si la priorité est Solidity, les portefeuilles existants et les outils Ethereum, DuskEVM réduit la barrière de migration. Dusk présente explicitement les deux voies comme des choix selon les exigences de l’application.
Mais cette flexibilité soulève une question d’architecture que je trouve plus intéressante que la compatibilité :
Où doit vivre un invariant ?
À mon avis, les règles liées uniquement à un environnement d’exécution peuvent rester locales à cet environnement. Les règles qui couvrent plusieurs chemins d’exécution ou qui dépendent du règlement nécessitent une propriété explicite et des limites de coordination.
Cette distinction compte car les couches de Dusk ne sont pas interchangeables. DuskDS fournit le consensus, la finalité, le règlement et la disponibilité des données, tandis que DuskVM et DuskEVM fournissent des environnements d’exécution différents.
Le pont rend la frontière concrète. Dans le flux de retrait DuskEVM Testnet documenté, un retrait est initié sur DuskEVM, puis prouvé et finalisé sur le L1 de Dusk. Le workflow traverse donc des couches d’exécution au lieu de se comporter comme une opération monolithique.
Ma conclusion est que la modularité ne réduit pas simplement la complexité. Elle permet aux développeurs de décider où doit vivre cette complexité.
Pour les applications financières, cela peut constituer un avantage architectural significatif : garder la logique spécifique à l’exécution locale tout en traitant les règles inter-couches comme des contraintes architecturales explicites.
Quelles règles doivent rester à l’intérieur d’un environnement d’exécution, et lesquelles sont suffisamment importantes pour être appliquées à travers l’architecture ?
$DUSK #dusk
@Dusk sépare le règlement de l’exécution : DuskVM exécute directement des contrats Rust/WASM sur le Dusk L1, tandis que DuskEVM fournit une exécution compatible EVM avec le règlement et la disponibilité des données via DuskDS.
La conséquence plus profonde est que les développeurs peuvent choisir où appartient la logique applicative, au lieu de forcer chaque charge de travail dans un seul modèle d’exécution.
Si un contrat a besoin d’un accès direct au L1 aux modèles de transactions de Dusk, pour la confidentialité ou des capacités de preuve à divulgation nulle, DuskVM est la voie native. Si la priorité est Solidity, les portefeuilles existants et les outils Ethereum, DuskEVM réduit la barrière de migration. Dusk présente explicitement les deux voies comme des choix selon les exigences de l’application.
Mais cette flexibilité soulève une question d’architecture que je trouve plus intéressante que la compatibilité :
Où doit vivre un invariant ?
À mon avis, les règles liées uniquement à un environnement d’exécution peuvent rester locales à cet environnement. Les règles qui couvrent plusieurs chemins d’exécution ou qui dépendent du règlement nécessitent une propriété explicite et des limites de coordination.
Cette distinction compte car les couches de Dusk ne sont pas interchangeables. DuskDS fournit le consensus, la finalité, le règlement et la disponibilité des données, tandis que DuskVM et DuskEVM fournissent des environnements d’exécution différents.
Le pont rend la frontière concrète. Dans le flux de retrait DuskEVM Testnet documenté, un retrait est initié sur DuskEVM, puis prouvé et finalisé sur le L1 de Dusk. Le workflow traverse donc des couches d’exécution au lieu de se comporter comme une opération monolithique.
Ma conclusion est que la modularité ne réduit pas simplement la complexité. Elle permet aux développeurs de décider où doit vivre cette complexité.
Pour les applications financières, cela peut constituer un avantage architectural significatif : garder la logique spécifique à l’exécution locale tout en traitant les règles inter-couches comme des contraintes architecturales explicites.
Quelles règles doivent rester à l’intérieur d’un environnement d’exécution, et lesquelles sont suffisamment importantes pour être appliquées à travers l’architecture ?
$DUSK #dusk
