Récemment, en lisant la documentation de pontage de DuskEVM, je suis tombé sur un avertissement que l’on insiste sans cesse.
Le pontage actuel ne prend en charge que le réseau de test DUSK.
Ce n’est pas une limitation technique.
C’est plutôt que la publication d’état, la maturité des preuves et la fenêtre de controverse ont encore besoin de temps pour être validées.$BTC
Cela m’a amené à réfléchir à un problème plus concret : réussir sur le réseau de test ne signifie pas que c’est utilisable sur le mainnet.
Dans la conception en couches de @Dusk , DuskDS gère le consensus et le règlement, DuskEVM fournit la compatibilité EVM via OP Stack ; entre les deux, le pont transmet des messages et des actifs. En théorie, les développeurs peuvent déployer directement des contrats Solidity sur DuskEVM et se lancer rapidement avec un outillage familier.
Mais le pontage n’est pas instantané.
Les dépôts doivent attendre la confirmation de DuskDS, les retraits doivent attendre la publication de l’état sur le L1, la soumission des preuves et la fin de la période de contestation. Si une application DeFi a besoin d’arbitrage à haute fréquence ou de liquidations rapides, ces délais peuvent-ils être acceptés ? Et si, à une étape, les messages entre couches se bloquent, qui assurera la prise en charge, comment la reprise se fera, et les pertes des utilisateurs seront-elles de la responsabilité de qui ?
Le plus crucial, c’est la liquidité.
Sur le réseau de test, on peut facilement frapper des tokens. Sur le mainnet, chaque transaction de $DUSK a un coût réel. Si, au lancement de DuskEVM, la liquidité dans le pont est insuffisante, les utilisateurs auront tendance à déposer facilement, mais à retirer difficilement ; ou alors, le temps d’attente pour les retraits sera trop long. Même avec une très bonne compatibilité, il sera difficile de fidéliser les applications.
En parcourant le plan de route de #dusk , je constate que le calendrier d’audit des contrats de pontage et celui du déploiement sur le mainnet ne sont pas encore assez clairement définis. Ce n’est pas que la technique ne fonctionne pas : entre le réseau de test et la production, il y a encore plusieurs “portes” à franchir, notamment exploitation, supervision, gestion des incidents et guidage de la liquidité.
Donc, quand j’observe les progrès de DuskEVM, je ne me demande pas seulement “peut-on déployer des contrats”.
Je m’intéresse davantage à trois étapes de transformation : la proportion d’applications du réseau de test migrées vers le mainnet, la taille initiale de la liquidité du pont et les mécanismes de reconstitution, ainsi que la vitesse de réponse réelle lors d’exceptions inter-couches.
La compatibilité EVM réduit le coût d’entrée, mais pour conserver les développeurs et les utilisateurs, il faut que le pont soit fiable, que l’argent circule vite, et que quelqu’un prenne en charge les problèmes.
À cette distance, est-ce vraiment “juste une question de temps” ?
#dusk @Dusk $DUSK