@Dusk je me rendais compte que le bit modulaire ne consiste pas seulement à avoir davantage de composants. $DUSK en fait, il sépare l’endroit où a lieu le règlement de celui où a lieu l’exécution, et cela change la façon dont je pense la chaîne.
En consultant les dernières documentations de Dusk, je n’ai cessé de comparer DuskDS et DuskEVM. DuskDS gère le consensus, la finalité et la disponibilité des données, tandis que DuskEVM est la couche d’exécution EVM qui se règle via elle.
DuskVM est un autre environnement d’exécution directement sur la L1. Le plus intéressant est qu’ils peuvent tous s’appuyer sur la même base de règlement plutôt que de forcer chaque application à entrer dans un seul modèle d’exécution.
Au départ, j’ai lu ça comme un langage d’architecture modulaire standard et j’ai presque sauté l’explication. Ensuite, j’ai regardé de plus près comment Dusk gère les transactions réelles : Moonlight et Phoenix règlent toutes deux via DuskDS, tandis que l’exécution des smart contracts peut se faire ailleurs. Cela a rendu la séparation beaucoup plus concrète que ce que suggère le schéma.
Pour autant, je suis curieux des compromis. Une fois que des applications commencent à passer entre ces environnements d’exécution, la modularité réduit-elle réellement la complexité pour les développeurs, ou fait-elle simplement migrer cette complexité dans les interfaces entre eux…
@Dusk $DUSK #dusk
En consultant les dernières documentations de Dusk, je n’ai cessé de comparer DuskDS et DuskEVM. DuskDS gère le consensus, la finalité et la disponibilité des données, tandis que DuskEVM est la couche d’exécution EVM qui se règle via elle.
DuskVM est un autre environnement d’exécution directement sur la L1. Le plus intéressant est qu’ils peuvent tous s’appuyer sur la même base de règlement plutôt que de forcer chaque application à entrer dans un seul modèle d’exécution.
Au départ, j’ai lu ça comme un langage d’architecture modulaire standard et j’ai presque sauté l’explication. Ensuite, j’ai regardé de plus près comment Dusk gère les transactions réelles : Moonlight et Phoenix règlent toutes deux via DuskDS, tandis que l’exécution des smart contracts peut se faire ailleurs. Cela a rendu la séparation beaucoup plus concrète que ce que suggère le schéma.
Pour autant, je suis curieux des compromis. Une fois que des applications commencent à passer entre ces environnements d’exécution, la modularité réduit-elle réellement la complexité pour les développeurs, ou fait-elle simplement migrer cette complexité dans les interfaces entre eux…
@Dusk $DUSK #dusk
