Quand je regardais les mises à jour d’ingénierie de Dusk, j’ai d’abord cru que Moonlight et Phoenix étaient deux systèmes de comptes indépendants. Jusqu’à ce que je mette le nez dans la fonction « convert » : j’ai alors compris que l’astuce de Dusk réside dans le fait que les deux modèles ne coexistent pas simplement ; ils sont interchangeables de manière atomique. @Dusk
Dans le compte Phoenix, les actifs sont des notes chiffrées. Quand on les transfère vers le compte Moonlight, le Transfer Contract traite d’abord ces notes, puis les ajoute ensuite à un solde public selon leur valeur équivalente. À l’inverse, lors d’un transfert depuis Moonlight, le Transfer Contract déduit d’abord le solde, puis génère des notes du montant correspondant et les envoie vers une adresse masquée. L’utilisateur n’a pas besoin de prouver son identité : il lui suffit de prouver qu’il est bien le propriétaire des comptes ou des adresses concernés par la conversion. Tout le processus est atomique et se fait d’un bloc, sans possibilité d’interruption dans un état intermédiaire.
Mais lors d’une re-vérification, je me suis aperçu que j’avais parlé de ce mécanisme en le mélangeant avec la norme de valeurs mobilières XSC, et que ce n’était pas rigoureux. convert résout la conversion des jetons natifs DUSK entre ces deux modèles ; tandis que, pour les valeurs mobilières XSC, tout repose réellement sur Zedger : un modèle qui combine les capacités UTXO et compte, conçu pour gérer minutieusement les détails de conformité tels que la vérification de l’éligibilité, les transferts soumis à limites et les versements. Les deux partagent la couche de base en connaissances nulles de Phoenix, mais ce n’est pas la même logique. Je ne devais pas les assimiler.
Dusk sépare très clairement ces deux couches : le mécanisme de conversion au niveau inférieur gère la circulation des jetons, et la couche Zedger au niveau supérieur gère la conformité des titres. C’est aussi pour cela que, plus je regarde, plus je pense que Dusk ne fait pas simplement une chaîne axée sur la confidentialité.
$DUSK supporte les coûts de gaz de toute cette conversion et de ce règlement.
#dusk $DUSK @Dusk
Dans le compte Phoenix, les actifs sont des notes chiffrées. Quand on les transfère vers le compte Moonlight, le Transfer Contract traite d’abord ces notes, puis les ajoute ensuite à un solde public selon leur valeur équivalente. À l’inverse, lors d’un transfert depuis Moonlight, le Transfer Contract déduit d’abord le solde, puis génère des notes du montant correspondant et les envoie vers une adresse masquée. L’utilisateur n’a pas besoin de prouver son identité : il lui suffit de prouver qu’il est bien le propriétaire des comptes ou des adresses concernés par la conversion. Tout le processus est atomique et se fait d’un bloc, sans possibilité d’interruption dans un état intermédiaire.
Mais lors d’une re-vérification, je me suis aperçu que j’avais parlé de ce mécanisme en le mélangeant avec la norme de valeurs mobilières XSC, et que ce n’était pas rigoureux. convert résout la conversion des jetons natifs DUSK entre ces deux modèles ; tandis que, pour les valeurs mobilières XSC, tout repose réellement sur Zedger : un modèle qui combine les capacités UTXO et compte, conçu pour gérer minutieusement les détails de conformité tels que la vérification de l’éligibilité, les transferts soumis à limites et les versements. Les deux partagent la couche de base en connaissances nulles de Phoenix, mais ce n’est pas la même logique. Je ne devais pas les assimiler.
Dusk sépare très clairement ces deux couches : le mécanisme de conversion au niveau inférieur gère la circulation des jetons, et la couche Zedger au niveau supérieur gère la conformité des titres. C’est aussi pour cela que, plus je regarde, plus je pense que Dusk ne fait pas simplement une chaîne axée sur la confidentialité.
$DUSK supporte les coûts de gaz de toute cette conversion et de ce règlement.
#dusk $DUSK @Dusk