J’ai d’abord regroupé Dusk Trade, DuskEVM et DuskDS dans ma tête, et je trouvais qu’il y avait trop de termes. Après les avoir séparés à nouveau, la logique est devenue, au contraire, très claire.
DuskDS prend en charge le consensus, l’issue finale déterministe, la disponibilité des données et les modèles de transaction Moonlight et Phoenix ; DuskVM permet d’exécuter directement des contrats Rust/WASM sur le L1 natif ; DuskEVM fournit l’environnement d’applications Solidity ; et Dusk Trade regroupe enfin l’accès, l’achat/la vente et le règlement dans un produit que les utilisateurs peuvent manipuler.
Cela ressemble à un marché boursier : DuskDS est le grand livre et le centre de compensation, DuskVM et DuskEVM sont deux voies distinctes de développement applicatif, et Dusk Trade est le guichet de négociation face aux investisseurs.
Le guichet peut être remanié, mais le registre sous-jacent doit rester stable.
Cette architecture en couches m’a aidé à comprendre pourquoi Dusk insiste sans cesse sur le « deterministic settlement ».
Les actifs réglementés ne peuvent pas accepter l’idée que « ça ne va probablement pas revenir en arrière » : le marché a besoin d’un état final explicite.
Mes doutes se sont donc déplacés : une architecture en plusieurs niveaux ne va-t-elle pas transformer le risque, d’un problème de performance sur une seule chaîne, en une complexité de messages inter-couches, de ponts et d’exploitation/maintenance ? La finalité rapide au niveau inférieur est un avantage, mais ce n’est que si les couches supérieures l’héritent correctement que l’utilisateur obtient réellement un règlement plus propre.
#dusk $DUSK @Dusk
DuskDS prend en charge le consensus, l’issue finale déterministe, la disponibilité des données et les modèles de transaction Moonlight et Phoenix ; DuskVM permet d’exécuter directement des contrats Rust/WASM sur le L1 natif ; DuskEVM fournit l’environnement d’applications Solidity ; et Dusk Trade regroupe enfin l’accès, l’achat/la vente et le règlement dans un produit que les utilisateurs peuvent manipuler.
Cela ressemble à un marché boursier : DuskDS est le grand livre et le centre de compensation, DuskVM et DuskEVM sont deux voies distinctes de développement applicatif, et Dusk Trade est le guichet de négociation face aux investisseurs.
Le guichet peut être remanié, mais le registre sous-jacent doit rester stable.
Cette architecture en couches m’a aidé à comprendre pourquoi Dusk insiste sans cesse sur le « deterministic settlement ».
Les actifs réglementés ne peuvent pas accepter l’idée que « ça ne va probablement pas revenir en arrière » : le marché a besoin d’un état final explicite.
Mes doutes se sont donc déplacés : une architecture en plusieurs niveaux ne va-t-elle pas transformer le risque, d’un problème de performance sur une seule chaîne, en une complexité de messages inter-couches, de ponts et d’exploitation/maintenance ? La finalité rapide au niveau inférieur est un avantage, mais ce n’est que si les couches supérieures l’héritent correctement que l’utilisateur obtient réellement un règlement plus propre.
#dusk $DUSK @Dusk