Je continuais de remarquer que @Dusk ne force pas chaque transaction à passer par un seul modèle.

Moonlight utilise une structure basée sur des comptes, tandis que Phoenix adopte une approche UTXO. Au début, cela ressemble à une complexité inutile. Pourquoi maintenir deux façons de représenter les transactions au lieu d’en choisir une seule et de garder l’architecture plus simple ?

Plus j’y regardais, plus la séparation me paraissait avoir du sens. L’état basé sur des comptes est simple pour les soldes et la logique applicative. Phoenix donne à Dusk une structure de transaction différente qui peut prendre en charge des flux davantage orientés vers la confidentialité.

Cette flexibilité est utile.

Mais il y a un compromis dont je pense qu’on ne parle pas assez. Chaque modèle de transaction supplémentaire ajoute un autre modèle mental pour que les développeurs et les utilisateurs comprennent. L’architecture peut devenir plus performante, tandis que le système, dans l’ensemble, devient plus difficile à appréhender.

Alors, est-ce que disposer de modèles de transaction distincts apporte réellement une flexibilité utile à Dusk, ou est-ce que la complexité supplémentaire finit par dépasser le bénéfice ?

#dusk @Dusk $DUSK