Le marché était calme ce soir-là, alors j’ai fini par rouvrir de vieilles notes de DUSK. Un détail ne cessait de me tracasser : de vieilles discussions disent que Zedger, tandis que la documentation actuelle présente Hedger comme son évolution, a été construit sur DuskEVM.
Au début, je l’ai pris comme une simple mise à jour de nom....Puis j’ai suivi l’architecture.
L’hypothèse intuitive est facile : si Hedger s’exécute via DuskEVM, et que DuskEVM héberge des applications, peut-être que c’est dans cet environnement que vit toute l’histoire économique.
Mais l’architecture de DUSK est plus en couches.
Hedger repose sur DuskEVM. DUSK peut passer entre Dusk L1 et DuskEVM via le bridge... Pourtant, l’exécution se rattache finalement à DuskDS, la base de disponibilité des données et de règlement de la L1.
L’exécution peut avoir lieu ailleurs ; la vérité économique finale doit néanmoins se déposer quelque part.
Cette distinction compte.
DuskEVM offre aux applications d’actifs réglementés un environnement d’exécution compatible avec l’EVM....Le bridge fournit la circulation entre les environnements. DuskDS ancre le règlement et l’état final.
Mais cela soulève aussi une question de frontière de confiance : si une application produit un état techniquement valide, mais que sa logique, ses entrées ou son intégration sont défaillantes, le règlement peut finaliser le résultat sans juger si la décision économique était sensée.
Je ne dis pas que c’est propre à DUSK. Les architectures modulaires rencontrent la même distinction.
L’onglet de documentation est encore ouvert. Je suis simplement moins enclin maintenant à assimiler « où se produit l’exécution » à « où se trouve la vérité ».
@Dusk $DUSK #dusk
Au début, je l’ai pris comme une simple mise à jour de nom....Puis j’ai suivi l’architecture.
L’hypothèse intuitive est facile : si Hedger s’exécute via DuskEVM, et que DuskEVM héberge des applications, peut-être que c’est dans cet environnement que vit toute l’histoire économique.
Mais l’architecture de DUSK est plus en couches.
Hedger repose sur DuskEVM. DUSK peut passer entre Dusk L1 et DuskEVM via le bridge... Pourtant, l’exécution se rattache finalement à DuskDS, la base de disponibilité des données et de règlement de la L1.
L’exécution peut avoir lieu ailleurs ; la vérité économique finale doit néanmoins se déposer quelque part.
Cette distinction compte.
DuskEVM offre aux applications d’actifs réglementés un environnement d’exécution compatible avec l’EVM....Le bridge fournit la circulation entre les environnements. DuskDS ancre le règlement et l’état final.
Mais cela soulève aussi une question de frontière de confiance : si une application produit un état techniquement valide, mais que sa logique, ses entrées ou son intégration sont défaillantes, le règlement peut finaliser le résultat sans juger si la décision économique était sensée.
Je ne dis pas que c’est propre à DUSK. Les architectures modulaires rencontrent la même distinction.
L’onglet de documentation est encore ouvert. Je suis simplement moins enclin maintenant à assimiler « où se produit l’exécution » à « où se trouve la vérité ».
@Dusk $DUSK #dusk