Je me demande sans cesse si mon Phoenix DUSK est déjà prêt côté paiement et si la preuve XSC a été acceptée ; alors, la partie relative à la propriété devrait essentiellement être terminée.
Alors, qu’est-ce qui manque exactement ?
C’est à ce moment-là que j’ai réalisé que je traitais « valable » et « définitif » comme la même chose.
Phoenix prépare la partie paiement.
La condition XSC prouve que le portefeuille destinataire est éligible.
DuskVM peut accepter la preuve à connaissance zéro qui satisfait cette condition.
Mais aucun de ces instants n’est nécessairement le même que le moment où DuskDS rend le changement de propriété définitif sur Dusk L1.
Cette distinction est facile à manquer.
J’ai commencé à séparer le flux en trois jalons différents :
Validité du paiement → validation de l’éligibilité → caractère définitif de la propriété.
Et cela change ma façon de penser le transfert.
Une sécurité réglementée n’est vraiment pas transférée simplement parce que le paiement est valable, ni même parce que le destinataire a satisfait aux conditions requises. L’état de propriété doit encore devenir définitif sur la couche de règlement.
Cela m’a rendu l’architecture de Dusk plus intéressante, parce qu’ici le règlement ne consiste pas seulement à déplacer un actif de A à B. Il s’agit aussi d’établir un état de propriété final et vérifiable tout en gardant les détails sous-jacents de la transaction de façon sélectivement privée.
Mais il y a un compromis auquel je reviens sans cesse.
Le fait de séparer la validité du paiement, la validation de l’éligibilité et le caractère définitif de la propriété rend-il le règlement réglementé plus robuste et plus facile à comprendre — ou bien introduit-il un autre état que les institutions doivent également saisir et gérer ?
C’est la question que je continue de suivre avec $DUSK . @Dusk
#dusk
Alors, qu’est-ce qui manque exactement ?
C’est à ce moment-là que j’ai réalisé que je traitais « valable » et « définitif » comme la même chose.
Phoenix prépare la partie paiement.
La condition XSC prouve que le portefeuille destinataire est éligible.
DuskVM peut accepter la preuve à connaissance zéro qui satisfait cette condition.
Mais aucun de ces instants n’est nécessairement le même que le moment où DuskDS rend le changement de propriété définitif sur Dusk L1.
Cette distinction est facile à manquer.
J’ai commencé à séparer le flux en trois jalons différents :
Validité du paiement → validation de l’éligibilité → caractère définitif de la propriété.
Et cela change ma façon de penser le transfert.
Une sécurité réglementée n’est vraiment pas transférée simplement parce que le paiement est valable, ni même parce que le destinataire a satisfait aux conditions requises. L’état de propriété doit encore devenir définitif sur la couche de règlement.
Cela m’a rendu l’architecture de Dusk plus intéressante, parce qu’ici le règlement ne consiste pas seulement à déplacer un actif de A à B. Il s’agit aussi d’établir un état de propriété final et vérifiable tout en gardant les détails sous-jacents de la transaction de façon sélectivement privée.
Mais il y a un compromis auquel je reviens sans cesse.
Le fait de séparer la validité du paiement, la validation de l’éligibilité et le caractère définitif de la propriété rend-il le règlement réglementé plus robuste et plus facile à comprendre — ou bien introduit-il un autre état que les institutions doivent également saisir et gérer ?
C’est la question que je continue de suivre avec $DUSK . @Dusk
#dusk