Après avoir examiné la documentation de développement complète de @Dusk , je me suis rendu compte que ce qui mérite le plus d’être regardé n’est pas un slogan TPS quelconque : c’est le fait d’avoir séparé l’entrée de développement en deux environnements, DuskVM et DuskEVM. Cela ressemble à une roue réinventée à première vue, mais en réalité, l’objectif est de résoudre le problème où les « capacités de confidentialité natives » et « l’écosystème de développement prêt à l’emploi » ne peuvent pas être obtenus en une seule étape.
DuskVM permet d’exécuter directement des contrats Rust/WASM sur le L1 : c’est plus proche de Phoenix, qui masque les transactions, les capacités à preuves à divulgation nulle (zero-knowledge) et le modèle d’actifs natifs ; DuskEVM, lui, s’appuie sur OP Stack. Les développeurs peuvent continuer à utiliser Solidity, Hardhat, Foundry et les outils de portefeuille qu’ils connaissent, et les résultats d’exécution sont ensuite pris en charge pour le règlement et la disponibilité des données via DuskDS. En termes simples, le premier ressemble à un laboratoire spécialisé : capacités profondes, mais seuil d’apprentissage élevé ; le second ressemble à une interface standard : branchement rapide, mais nécessite de gérer la coordination entre couches.
Cette feuille de route est effectivement pragmatique. Beaucoup de technologies de chaînes de confidentialité sont très lourdes, puis finissent par bloquer faute de développeurs. À l’inverse, les outils classiques d’une chaîne EVM sont complets, mais il est difficile de traiter nativement la confidentialité et la divulgation sélective requises par les actifs soumis à réglementation. Dusk conserve les deux types de développeurs, au moins en évitant le vieux problème « solution techniquement correcte, écosystème vide ».
Mais ces deux environnements ne sont pas un cadeau. Le fait de savoir à quelle couche placer les contrats, comment faire passer les actifs entre couches, et quelle couche est responsable en cas de panne, augmente forcément la complexité d’ingénierie. En particulier, DuskEVM dépend de DuskDS pour le règlement et la disponibilité des données : l’utilisateur voit une interface EVM familière, mais en dessous ce n’est pas un simple sidechain Ethereum ordinaire. Si la documentation, le navigateur et les notifications d’état entre couches ne suivent pas, la compatibilité risque au contraire de créer de nouveaux coûts de compréhension.
Je ne tirerai donc pas, uniquement sur la base de « prise en charge de Solidity », une conclusion de croissance pour #dusk . Ce qu’il vaut mieux surveiller ensuite, c’est : le nombre de contrats réels sur le réseau principal, la fluidité des parcours d’actifs entre couches, et le moment où des capacités comme celles de Hedger formeront des composants réutilisables. $DUSK , en tant qu’actif de gas et de sécurité dans ces deux environnements, verra finalement sa valeur confirmée par le volume d’appels effectifs, pas par un schéma d’architecture qui s’auto-entretient.
Pensez-vous que ces deux environnements d’exécution sont une répartition intelligente du travail, ou bien qu’ils augmentent simplement la difficulté de maintenance ? N’hésitez pas à laisser votre avis.
$BTW $ETH
DuskVM permet d’exécuter directement des contrats Rust/WASM sur le L1 : c’est plus proche de Phoenix, qui masque les transactions, les capacités à preuves à divulgation nulle (zero-knowledge) et le modèle d’actifs natifs ; DuskEVM, lui, s’appuie sur OP Stack. Les développeurs peuvent continuer à utiliser Solidity, Hardhat, Foundry et les outils de portefeuille qu’ils connaissent, et les résultats d’exécution sont ensuite pris en charge pour le règlement et la disponibilité des données via DuskDS. En termes simples, le premier ressemble à un laboratoire spécialisé : capacités profondes, mais seuil d’apprentissage élevé ; le second ressemble à une interface standard : branchement rapide, mais nécessite de gérer la coordination entre couches.
Cette feuille de route est effectivement pragmatique. Beaucoup de technologies de chaînes de confidentialité sont très lourdes, puis finissent par bloquer faute de développeurs. À l’inverse, les outils classiques d’une chaîne EVM sont complets, mais il est difficile de traiter nativement la confidentialité et la divulgation sélective requises par les actifs soumis à réglementation. Dusk conserve les deux types de développeurs, au moins en évitant le vieux problème « solution techniquement correcte, écosystème vide ».
Mais ces deux environnements ne sont pas un cadeau. Le fait de savoir à quelle couche placer les contrats, comment faire passer les actifs entre couches, et quelle couche est responsable en cas de panne, augmente forcément la complexité d’ingénierie. En particulier, DuskEVM dépend de DuskDS pour le règlement et la disponibilité des données : l’utilisateur voit une interface EVM familière, mais en dessous ce n’est pas un simple sidechain Ethereum ordinaire. Si la documentation, le navigateur et les notifications d’état entre couches ne suivent pas, la compatibilité risque au contraire de créer de nouveaux coûts de compréhension.
Je ne tirerai donc pas, uniquement sur la base de « prise en charge de Solidity », une conclusion de croissance pour #dusk . Ce qu’il vaut mieux surveiller ensuite, c’est : le nombre de contrats réels sur le réseau principal, la fluidité des parcours d’actifs entre couches, et le moment où des capacités comme celles de Hedger formeront des composants réutilisables. $DUSK , en tant qu’actif de gas et de sécurité dans ces deux environnements, verra finalement sa valeur confirmée par le volume d’appels effectifs, pas par un schéma d’architecture qui s’auto-entretient.
Pensez-vous que ces deux environnements d’exécution sont une répartition intelligente du travail, ou bien qu’ils augmentent simplement la difficulté de maintenance ? N’hésitez pas à laisser votre avis.
$BTW $ETH
