commenter votre idée
Publier
--
Kiko奇科
·
--
DuskVM contre DuskEVM : deux voies pour les développeurs
Une blockchain doit-elle forcer chaque développeur à travailler dans le même environnement d’exécution ?
Dusk adopte une approche différente en proposant deux parcours de contrats intelligents, chacun conçu autour d’un modèle de développement distinct.
DuskVM est la voie native. Les développeurs écrivent des contrats en Rust, les compilent en WASM et les exécutent directement sur le Dusk L1. Cela donne aux contrats un accès direct au modèle d’exécution de Dusk sur L1, aux modèles de transaction, ainsi qu’aux protocoles et aux capacités des contrats qui doivent rester proches de la couche de base, y compris la confidentialité et les fonctionnalités de preuve à connaissance nulle.
DuskEVM emprunte une voie axée sur la compatibilité. Les développeurs peuvent utiliser Solidity ou Vyper, ainsi que des portefeuilles EVM, des bibliothèques et des outils familiers. Le règlement et la disponibilité des données sont assurés via DuskDS, tandis que DUSK sert de jeton de gaz natif.
La distinction concerne donc moins le choix de l’environnement le « meilleur » et davantage l’adéquation de l’architecture aux besoins de l’application : DuskVM privilégie une exécution directe sur L1 et des capacités natives de Dusk. DuskEVM réduit la barrière d’entrée pour les développeurs qui travaillent déjà dans l’écosystème Ethereum.
Pour Dusk, proposer les deux parcours crée un équilibre intéressant entre fonctionnalités natives et familiarité pour les développeurs.
Le fait de prendre en charge à la fois l’exécution native et la compatibilité EVM pourrait-il constituer une stratégie développeur plus forte que d’imposer un environnement universel ?
$DUSK
#dusk @Dusk
Une blockchain doit-elle forcer chaque développeur à travailler dans le même environnement d’exécution ?
Dusk adopte une approche différente en proposant deux parcours de contrats intelligents, chacun conçu autour d’un modèle de développement distinct.
DuskVM est la voie native. Les développeurs écrivent des contrats en Rust, les compilent en WASM et les exécutent directement sur le Dusk L1. Cela donne aux contrats un accès direct au modèle d’exécution de Dusk sur L1, aux modèles de transaction, ainsi qu’aux protocoles et aux capacités des contrats qui doivent rester proches de la couche de base, y compris la confidentialité et les fonctionnalités de preuve à connaissance nulle.
DuskEVM emprunte une voie axée sur la compatibilité. Les développeurs peuvent utiliser Solidity ou Vyper, ainsi que des portefeuilles EVM, des bibliothèques et des outils familiers. Le règlement et la disponibilité des données sont assurés via DuskDS, tandis que DUSK sert de jeton de gaz natif.
La distinction concerne donc moins le choix de l’environnement le « meilleur » et davantage l’adéquation de l’architecture aux besoins de l’application : DuskVM privilégie une exécution directe sur L1 et des capacités natives de Dusk. DuskEVM réduit la barrière d’entrée pour les développeurs qui travaillent déjà dans l’écosystème Ethereum.
Pour Dusk, proposer les deux parcours crée un équilibre intéressant entre fonctionnalités natives et familiarité pour les développeurs.
Le fait de prendre en charge à la fois l’exécution native et la compatibilité EVM pourrait-il constituer une stratégie développeur plus forte que d’imposer un environnement universel ?
$DUSK
#dusk @Dusk
Avertissement : ce contenu inclut des opinions de tiers. Il ne constitue pas un conseil. Binance Ai peut être utilisée, sans garantie de résultat. Consultez les CG.