Je lisais les documents d’infrastructure de marché de Dusk et je me suis à chaque fois retrouvé bloqué sur la partie paiement. Un transfert d’actifs, pris isolément, est assez simple à imaginer. Le côté délicat commence quand le paiement doit s’aligner dessus.
Dusk traite la Livraison-contre-Paiement comme un problème de workflow plutôt que comme un simple autre transfert de jetons. La partie « actif » et la partie « paiement » peuvent être coordonnées via les chemins d’exécution de Dusk, tandis que DuskDS fournit le règlement et la finalité déterministe en dessous. Cela signifie que la partie intéressante n’est pas vraiment de mettre les deux actifs sur la même chaîne. Il s’agit plutôt de faire en sorte que les deux changements d’état puissent se régler de façon prévisible.
J’aime bien l’idée, mais je pense aussi qu’il est facile de surestimer ce que fait réellement le protocole ici.
Dusk fournit les éléments de base pour cette coordination. L’application elle-même doit encore définir comment les conditions relatives à l’actif, au paiement, à l’éligibilité et au règlement s’assemblent. Les propres documents de Dusk indiquent assez clairement que différents produits peuvent implémenter le workflow de manières différentes.
Cela compte, car la DvP peut sembler trompeusement simple de l’extérieur. Vous transférez le titre, transférez le paiement, et vous dites que c’est réglé. Dans un workflow réel soumis à une réglementation, il existe davantage de conditions autour de ces deux volets.
Donc je ne dirais pas que Dusk a, d’une manière ou d’une autre, éliminé le problème de coordination. Il l’a déplacé vers une fondation de règlement commune, avec une finalité déterministe.
La chose que je voudrais encore examiner dans un déploiement réel est assez étroite : lorsque l’une des parties échoue au niveau des conditions applicatives, dans quel état exact l’autre partie reste-t-elle, et à quelle vitesse le workflow peut-il se dérouler en toute sécurité en sens inverse ?
#dusk $DUSK @Dusk $ACE
Dusk traite la Livraison-contre-Paiement comme un problème de workflow plutôt que comme un simple autre transfert de jetons. La partie « actif » et la partie « paiement » peuvent être coordonnées via les chemins d’exécution de Dusk, tandis que DuskDS fournit le règlement et la finalité déterministe en dessous. Cela signifie que la partie intéressante n’est pas vraiment de mettre les deux actifs sur la même chaîne. Il s’agit plutôt de faire en sorte que les deux changements d’état puissent se régler de façon prévisible.
J’aime bien l’idée, mais je pense aussi qu’il est facile de surestimer ce que fait réellement le protocole ici.
Dusk fournit les éléments de base pour cette coordination. L’application elle-même doit encore définir comment les conditions relatives à l’actif, au paiement, à l’éligibilité et au règlement s’assemblent. Les propres documents de Dusk indiquent assez clairement que différents produits peuvent implémenter le workflow de manières différentes.
Cela compte, car la DvP peut sembler trompeusement simple de l’extérieur. Vous transférez le titre, transférez le paiement, et vous dites que c’est réglé. Dans un workflow réel soumis à une réglementation, il existe davantage de conditions autour de ces deux volets.
Donc je ne dirais pas que Dusk a, d’une manière ou d’une autre, éliminé le problème de coordination. Il l’a déplacé vers une fondation de règlement commune, avec une finalité déterministe.
La chose que je voudrais encore examiner dans un déploiement réel est assez étroite : lorsque l’une des parties échoue au niveau des conditions applicatives, dans quel état exact l’autre partie reste-t-elle, et à quelle vitesse le workflow peut-il se dérouler en toute sécurité en sens inverse ?
#dusk $DUSK @Dusk $ACE