#dusk $DUSK Je lis aujourd’hui la documentation du réseau de test de Dusk sur @Dusk et, au début, je pensais que c’était simplement « Dusk prend enfin en charge Solidity » — une couche EVM standard compatible, où il suffit de porter les contrats Ethereum pour qu’ils tournent. Mais en voyant le schéma d’architecture et la relation entre DuskEVM et DuskDS, je me suis rendu compte que ce n’est pas aussi simple.
DuskEVM est construit sur OP Stack, utilise l’interface JSON-RPC standard d’Ethereum, avec un Chain ID 745, et le token de gas reste $DUSK . Les développeurs peuvent déployer des contrats avec Foundry ou Hardhat ; le navigateur du réseau de test est aussi basé sur Blockscout. À première vue, on dirait que ça ne diffère pas des autres chaînes d’OP Stack.
Le point clé, c’est que DuskEVM ne gère pas lui-même le règlement et la DA. Il exécute au niveau EVM, tandis que le règlement et la disponibilité des données sont confiés à DuskDS — autrement dit, la couche de consensus et de finalité de Dusk L1. Cela signifie que les contrats EVM s’exécutent dans un environnement compatible, mais que l’état final est verrouillé par le consensus Succinct Attestation de DuskDS : on bénéficie d’une finalité déterministe, plutôt que de simples confirmations probabilistes.
Je fais une analogie : ce n’est pas comme rouvrir en ville un centre commercial exactement aux mêmes spécifications, mais plutôt comme si, dans le centre commercial, les boutiques utilisaient un système de caisse familier (EVM). Pourtant, chaque transaction est finalement soldée dans la banque centrale (DuskDS). Les clients ne voient pas de différence, mais l’audit et la conformité regardent le grand livre du siège, pas le cache de la caisse.
Il y a aussi une contrainte facile à sous-estimer : DuskEVM et Dusk L1 sont connectés via un bridge. DUSK est le même actif dans les systèmes de comptes des deux côtés, mais les transferts inter-couches nécessitent l’opération de bridge. Si la liquidité du bridge est insuffisante ou si la latence est trop élevée, l’expérience DeFi côté EVM sera dégradée. À l’étape actuelle du réseau de test, il n’y a pas encore beaucoup de données sur le débit réel et la latence du bridge : @Dusk
Donc, en regardant l’étape « EVM » à #dusk , je vais surtout me concentrer sur le volume réel de déploiements de contrats sur le réseau de test, la distribution de la latence du bridge, et le coût de friction lié aux flux d’actifs entre DuskEVM et Dusk L1. $DUSK Avoir une porte d’entrée EVM ne signifie pas que les développeurs viendront ; l’enjeu, c’est surtout s’ils parviennent à y rester une fois arrivés.