J’ai remarqué que lorsqu’on remet quelque chose à quelqu’un d’autre, « terminé » peut signifier deux choses différentes. Le travail peut être fait, mais j’attends encore que l’autre personne l’accepte. Tant que cela n’a pas eu lieu, je ne considère pas vraiment le résultat comme définitif.

J’y ai pensé en observant la manière dont Dusk sépare l’exécution du règlement. Au début, j’ai supposé que ce sont essentiellement deux parties d’une même opération. Une transaction s’exécute, certains états changent, puis le réseau la confirme. Mais plus j’ai suivi l’architecture, moins ces étapes semblaient interchangeables.

DuskVM et DuskEVM sont là où l’exécution a lieu. DuskDS se trouve en dessous et gère le consensus, la finalité et la disponibilité des données. Ainsi, l’exécution peut déterminer ce qu’une transaction fait, sans être l’élément qui décide en dernier ressort si cet état devient un état finalisé par le réseau.

Cette distinction m’a demandé un moment. Je traitais la sortie de l’exécution comme si elle était déjà la réponse finale. Dusk semble plutôt la considérer comme une transition d’état proposée, qui doit encore passer par le processus de règlement du réseau.

Pour l’infrastructure financière, cette séparation commence à paraître moins abstraite. Une application peut avoir son propre environnement d’exécution, tandis que la couche de règlement conserve la responsabilité de s’accorder sur l’état que tout le monde doit considérer comme final.

Mais cette frontière explicite a un coût. L’exécution devient plus modulaire, mais la finalité devient une dépendance distincte sur laquelle les applications finissent par s’appuyer.

Je me demande encore si la partie importante est la séparation elle-même, ou le fait que Dusk fasse deux questions différentes : « ce qui s’est passé » et « ce qui est final ».

#dusk $DUSK @Dusk $BR $APR