Plus j’observe DuskEVM, plus je me dis que la partie intéressante ne tient pas simplement au fait que Dusk prend désormais en charge l’EVM.
C’est plutôt que les développeurs n’ont pas besoin de jeter le workflow qu’ils connaissent déjà.
Si vous construisez avec Solidity, Foundry, Hardhat, viem, ethers, ou des portefeuilles EVM familiers, DuskEVM est conçu pour apporter cette expérience dans l’écosystème Dusk.
Mais c’est l’architecture en dessous qui a retenu mon attention.
DuskEVM gère l’exécution compatible avec Ethereum, tandis que DuskDS fournit le consensus sous-jacent, la couche de règlement et de disponibilité des données.
DUSK est utilisé pour l’exécution, et il peut passer entre Dusk L1 et DuskEVM via le bridge.
Le chemin de la transaction mérite aussi d’être compris.
Une transaction arrive au séquenceur de DuskEVM, est incluse dans un bloc L2, puis le batcher publie les données de transaction sur DuskDS. Les engagements d’état et les preuves de faute relient ensuite l’état résultant à DuskDS pour le règlement.
Cette distinction compte.
L’inclusion d’une transaction n’est pas automatiquement la même chose que le règlement final.
J’aime aussi que Dusk n’oblige pas chaque développeur à évoluer dans un seul environnement.
Les développeurs EVM peuvent utiliser DuskEVM et leurs outils existants, tandis que les développeurs qui construisent directement des contrats Rust/WASM pour Dusk L1 peuvent continuer à utiliser DuskVM.
Donc mon idée est assez simple :
DuskEVM n’est pas intéressant seulement parce qu’il apporte la compatibilité EVM à Dusk.
Il est intéressant parce qu’il offre aux développeurs un environnement d’exécution familier tout en reliant cet environnement à la propre architecture de règlement et de disponibilité des données de Dusk.
Cela ressemble à une histoire beaucoup plus vaste que le simple fait de dire : « Dusk a maintenant un EVM ».
@Dusk_Foundation
#dusk $DUSK
$EDEN $AKE
C’est plutôt que les développeurs n’ont pas besoin de jeter le workflow qu’ils connaissent déjà.
Si vous construisez avec Solidity, Foundry, Hardhat, viem, ethers, ou des portefeuilles EVM familiers, DuskEVM est conçu pour apporter cette expérience dans l’écosystème Dusk.
Mais c’est l’architecture en dessous qui a retenu mon attention.
DuskEVM gère l’exécution compatible avec Ethereum, tandis que DuskDS fournit le consensus sous-jacent, la couche de règlement et de disponibilité des données.
DUSK est utilisé pour l’exécution, et il peut passer entre Dusk L1 et DuskEVM via le bridge.
Le chemin de la transaction mérite aussi d’être compris.
Une transaction arrive au séquenceur de DuskEVM, est incluse dans un bloc L2, puis le batcher publie les données de transaction sur DuskDS. Les engagements d’état et les preuves de faute relient ensuite l’état résultant à DuskDS pour le règlement.
Cette distinction compte.
L’inclusion d’une transaction n’est pas automatiquement la même chose que le règlement final.
J’aime aussi que Dusk n’oblige pas chaque développeur à évoluer dans un seul environnement.
Les développeurs EVM peuvent utiliser DuskEVM et leurs outils existants, tandis que les développeurs qui construisent directement des contrats Rust/WASM pour Dusk L1 peuvent continuer à utiliser DuskVM.
Donc mon idée est assez simple :
DuskEVM n’est pas intéressant seulement parce qu’il apporte la compatibilité EVM à Dusk.
Il est intéressant parce qu’il offre aux développeurs un environnement d’exécution familier tout en reliant cet environnement à la propre architecture de règlement et de disponibilité des données de Dusk.
Cela ressemble à une histoire beaucoup plus vaste que le simple fait de dire : « Dusk a maintenant un EVM ».
@Dusk_Foundation
#dusk $DUSK
$EDEN $AKE