La partie de DuskEVM que je n’avais pas anticipée n’est pas la prise en charge de Solidity — c’est ce qui se passe lorsque DUSK repasse à la couche native.
Le guide de son propre réseau testnet de Dusk indique qu’un retrait depuis DuskEVM nécessite trois actions distinctes en chaîne : initier sur DuskEVM, prouver sur Dusk L1, puis finaliser sur Dusk L1. L’utilisateur doit aussi disposer de suffisamment de DUSK non protégé sur L1 pour payer à la fois les transactions de preuve et de finalisation. La disponibilité d’un retrait dépend de l’état réseau publié, de la maturité de la preuve et des vérifications liées au dispute-game, plutôt que d’un simple minuteur.
Cela m’a fait regarder deux fois, car « la compatibilité EVM » peut donner l’impression que l’ensemble de l’expérience devient familière par défaut. En pratique, le pont met en avant une architecture plus profonde : DuskEVM est un environnement d’exécution EVM qui règle et publie des données via DuskDS, et non la même couche d’exécution que les contrats natifs Rust/WASM de Dusk.
Je ne vois pas ces étapes supplémentaires comme automatiquement mauvaises. La documentation lie la disponibilité à la maturité de la preuve et aux vérifications du dispute-game : la friction est donc au moins liée au modèle de sécurité. Mais cela pose une vraie question produit pour $DUSK : les applications de production peuvent-elles abstraire correctement ce flux de preuve/finalisation afin que les utilisateurs obtiennent les bénéfices de sécurité sans ressentir toute la complexité inter-couches ?
Cela semble plus important à surveiller qu’une autre démonstration de déploiement.
@Dusk $DUSK #dusk
Le guide de son propre réseau testnet de Dusk indique qu’un retrait depuis DuskEVM nécessite trois actions distinctes en chaîne : initier sur DuskEVM, prouver sur Dusk L1, puis finaliser sur Dusk L1. L’utilisateur doit aussi disposer de suffisamment de DUSK non protégé sur L1 pour payer à la fois les transactions de preuve et de finalisation. La disponibilité d’un retrait dépend de l’état réseau publié, de la maturité de la preuve et des vérifications liées au dispute-game, plutôt que d’un simple minuteur.
Cela m’a fait regarder deux fois, car « la compatibilité EVM » peut donner l’impression que l’ensemble de l’expérience devient familière par défaut. En pratique, le pont met en avant une architecture plus profonde : DuskEVM est un environnement d’exécution EVM qui règle et publie des données via DuskDS, et non la même couche d’exécution que les contrats natifs Rust/WASM de Dusk.
Je ne vois pas ces étapes supplémentaires comme automatiquement mauvaises. La documentation lie la disponibilité à la maturité de la preuve et aux vérifications du dispute-game : la friction est donc au moins liée au modèle de sécurité. Mais cela pose une vraie question produit pour $DUSK : les applications de production peuvent-elles abstraire correctement ce flux de preuve/finalisation afin que les utilisateurs obtiennent les bénéfices de sécurité sans ressentir toute la complexité inter-couches ?
Cela semble plus important à surveiller qu’une autre démonstration de déploiement.
@Dusk $DUSK #dusk