Je ne cessais de me tromper sur un point en réfléchissant à Moonlight et Phoenix : je traitais la forme de l’état comme si elle déterminait aussi la finalité.
Cette hypothèse a commencé à me gêner.
Moonlight arrive en #DuskVM portant un modèle de compte public : Soldes, Expéditeur, Destinataire, Montant et Progression du nonce.
Phoenix est construit autour d’une piste entièrement différente : Notes chiffrées, Sorties dissimulées, Nullificateurs et État privé.
Mon premier réflexe était que deux systèmes aussi différents devaient probablement nécessiter deux façons différentes de devenir final.
Mais peut-être que c’est là que j’ajoutais une complexité qui n’était pas réellement nécessaire.
Moonlight peut rester en forme de compte. Phoenix peut rester en forme de note. #DuskVM n’a pas besoin d’aplatir l’un ou l’autre dans un format d’état universel juste pour décider quand l’exécution est terminée.
Cela m’a aussi amené à reconsidérer #DuskDS .
J’avais supposé qu’il devait créer un seul état partagé $DUSK sous les deux modèles. Je n’en suis plus aussi sûr.
La logique d’exécution peut rester spécialisée tandis que Dusk L1 donne à l’état résultant une frontière de finalité déterministe.
Et honnêtement, cette séparation m’intéresse davantage que les modèles d’état individuels.
Des façons différentes de représenter l’état ne nécessitent pas forcément des réponses différentes à la question de savoir quand cet état est enfin terminé.
Ce qui me préoccupe encore, c’est à quel point cette séparation reste propre à mesure que Moonlight et Phoenix deviennent plus complexes.

#dusk $DUSK @Dusk