DuskEVM est intéressant parce qu’il ne demande pas aux développeurs EVM de repartir de zéro.
Si vous construisez déjà avec Solidity, Vyper, Foundry, Hardhat, viem ou ethers, l’idée est d’apporter ce workflow familier dans la pile Dusk.
Mais la partie que je trouve la plus intéressante, c’est ce qui se passe en dessous.
DuskEVM est l’environnement d’exécution compatible avec Ethereum, tandis que DuskDS gère le consensus, le règlement et la disponibilité des données. DUSK est utilisé pour l’exécution et peut passer entre Dusk L1 et DuskEVM via le pont.
Le flux des transactions mérite aussi qu’on s’y attarde.
Une transaction atteint d’abord le séquenceur de DuskEVM, puis est incluse dans un bloc L2. Le batcher publie les données de transaction sur DuskDS, tandis que les engagements d’état et les preuves de faute relient l’état résultant au règlement de DuskDS.
Cette dernière partie est importante, car l’inclusion d’une transaction et son règlement ne sont pas la même chose. Le simple fait de voir une transaction incluse ne signifie pas qu’il faille supposer une finalité en se basant uniquement sur le temps écoulé.
J’aime aussi que Dusk n’oblige pas chaque application à fonctionner dans le même environnement.
Pour les applications Solidity, les portefeuilles EVM et l’outillage Ethereum existant, DuskEVM est la voie évidente.
Pour les contrats Rust/WASM qui doivent fonctionner directement avec Dusk L1, DuskVM reste l’option.
Donc la partie intéressante ne se résume pas à « Dusk a maintenant un EVM. »
C’est plutôt que Dusk offre aux développeurs un environnement d’exécution familier tout en le gardant connecté à sa propre couche de règlement et de disponibilité des données.
@Dusk_Foundation
#dusk
$DUSK
Si vous construisez déjà avec Solidity, Vyper, Foundry, Hardhat, viem ou ethers, l’idée est d’apporter ce workflow familier dans la pile Dusk.
Mais la partie que je trouve la plus intéressante, c’est ce qui se passe en dessous.
DuskEVM est l’environnement d’exécution compatible avec Ethereum, tandis que DuskDS gère le consensus, le règlement et la disponibilité des données. DUSK est utilisé pour l’exécution et peut passer entre Dusk L1 et DuskEVM via le pont.
Le flux des transactions mérite aussi qu’on s’y attarde.
Une transaction atteint d’abord le séquenceur de DuskEVM, puis est incluse dans un bloc L2. Le batcher publie les données de transaction sur DuskDS, tandis que les engagements d’état et les preuves de faute relient l’état résultant au règlement de DuskDS.
Cette dernière partie est importante, car l’inclusion d’une transaction et son règlement ne sont pas la même chose. Le simple fait de voir une transaction incluse ne signifie pas qu’il faille supposer une finalité en se basant uniquement sur le temps écoulé.
J’aime aussi que Dusk n’oblige pas chaque application à fonctionner dans le même environnement.
Pour les applications Solidity, les portefeuilles EVM et l’outillage Ethereum existant, DuskEVM est la voie évidente.
Pour les contrats Rust/WASM qui doivent fonctionner directement avec Dusk L1, DuskVM reste l’option.
Donc la partie intéressante ne se résume pas à « Dusk a maintenant un EVM. »
C’est plutôt que Dusk offre aux développeurs un environnement d’exécution familier tout en le gardant connecté à sa propre couche de règlement et de disponibilité des données.
@Dusk_Foundation
#dusk
$DUSK