Le marché était calme ce soir-là, alors j’ai rouvert la documentation de Dusk après avoir vu la même affirmation : la tokenisation est facile ; le vrai problème consiste à la faire fonctionner dans des marchés réglementés.
Un lecteur pourrait entendre « règlementation encadrée » et supposer que Dusk résout qui peut détenir un actif,... lorsque la propriété change,... et si le paiement et la livraison deviennent un seul événement atomique.
DuskDS offre une finalité déterministe, tandis que Phoenix fournit des transferts protégés et une divulgation sélective ; les smart contracts et les modèles d’identité peuvent appliquer l’éligibilité et coordonner les volets actif/paiement.
Mais voici la distinction à laquelle je n’ai cessé de revenir : Dusk peut prouver que les règles du protocole ont été exécutées correctement ; il ne peut pas prouver que la règle juridique, les données externes ou la configuration institutionnelle étaient correctes.
Une politique d’éligibilité mal configurée pourrait autoriser une transaction valide, et la cryptographie ne saurait pas faire la différence.
Je ne dis pas que c’est uniquement le cas de Dusk. La tokenisation réglementée hérite des hypothèses juridiques, d’identité, de garde (custody) et opérationnelles effectuées en dehors de la chaîne.
Le mainnet de Dusk est en ligne, mais la préparation du workflow est une question plus importante que la préparation de la chaîne.
Je ne sais toujours pas comment chaque couche se comporte sous pression adversariale. L’onglet de documentation est ouvert, et « tokenisation » ressemble désormais à la première couche, pas à toute la pile.
@Dusk $DUSK #dusk
Un lecteur pourrait entendre « règlementation encadrée » et supposer que Dusk résout qui peut détenir un actif,... lorsque la propriété change,... et si le paiement et la livraison deviennent un seul événement atomique.
DuskDS offre une finalité déterministe, tandis que Phoenix fournit des transferts protégés et une divulgation sélective ; les smart contracts et les modèles d’identité peuvent appliquer l’éligibilité et coordonner les volets actif/paiement.
Mais voici la distinction à laquelle je n’ai cessé de revenir : Dusk peut prouver que les règles du protocole ont été exécutées correctement ; il ne peut pas prouver que la règle juridique, les données externes ou la configuration institutionnelle étaient correctes.
Une politique d’éligibilité mal configurée pourrait autoriser une transaction valide, et la cryptographie ne saurait pas faire la différence.
Je ne dis pas que c’est uniquement le cas de Dusk. La tokenisation réglementée hérite des hypothèses juridiques, d’identité, de garde (custody) et opérationnelles effectuées en dehors de la chaîne.
Le mainnet de Dusk est en ligne, mais la préparation du workflow est une question plus importante que la préparation de la chaîne.
Je ne sais toujours pas comment chaque couche se comporte sous pression adversariale. L’onglet de documentation est ouvert, et « tokenisation » ressemble désormais à la première couche, pas à toute la pile.
@Dusk $DUSK #dusk