9-28 @Dusk Après la deuxième moitié de cet article, un détail vraiment “salissant” est caché : les transferts inter-chaînes doivent passer par deux étapes de contrôle. Une obligation émise nativement sur DuskEVM doit être déplacée de l’autre côté, du côté d’Ethereum. Envoyer simplement la commande ne suffit pas : de l’autre côté, il faut refaire une vérification des droits. Il ne faut pas non plus s’épargner des efforts en utilisant un vieux justificatif de transfert pour faire l’affaire. Ce sont ces deux lignes : pour un transfert classique, un ensemble de contrôles ; pour une émission supplémentaire, un autre ensemble. La nouvelle frappe (mint) et le transfert ne sont pas le même code, ils ne peuvent pas tourner ensemble.
Le coût exact de cette étape où l’on se piège : sur la chaîne A, on brûle 100 unités prévues pour être frappées sur la chaîne B. Si le justificatif côté destinataire a déjà expiré, la frappe sur la chaîne B échoue, mais les 100 unités ont déjà été brûlées sur la chaîne A. Ces 100 unités restent alors en attente, jusqu’à ce que le justificatif soit réactivé ou que l’opérateur fasse un rollback et une remise à zéro. C’est précisément pourquoi, dans l’architecture de Dusk, cette couche Citadel doit être écrite dans le contrat natif, pas ajoutée après coup : le justificatif est lié au cycle de vie de l’actif, pas à une vérification effectuée “au moment du transfert”.
En passant de l’angle ingénierie à l’angle produit, la question que l’organisation reçoit aujourd’hui n’est pas “combien peut-on économiser sur la chaîne”, mais plutôt trois véritables problèmes : “combien d’unités faut-il annuler en cas d’échec”, “qui signe ce rollback”, et “comment le côté régulation consigne cela”. Le vrai concurrent de l’émission native n’est pas un token enveloppé, mais l’ancien processus de rapprochement fait à partir de tableurs.
@Dusk Cette approche n’a rien de nouveau, le mérite est d’avoir connecté Citadel et DuskVM directement à la couche du contrat natif. $DUSK n’est pas très spectaculaire aujourd’hui, mais le coût de l’échec inter-chaînes sur un marché conforme, c’est la somme que les institutions finissent vraiment par payer.
#dusk #原生发行 #跨链失败案例 $DUSK @Dusk
Le coût exact de cette étape où l’on se piège : sur la chaîne A, on brûle 100 unités prévues pour être frappées sur la chaîne B. Si le justificatif côté destinataire a déjà expiré, la frappe sur la chaîne B échoue, mais les 100 unités ont déjà été brûlées sur la chaîne A. Ces 100 unités restent alors en attente, jusqu’à ce que le justificatif soit réactivé ou que l’opérateur fasse un rollback et une remise à zéro. C’est précisément pourquoi, dans l’architecture de Dusk, cette couche Citadel doit être écrite dans le contrat natif, pas ajoutée après coup : le justificatif est lié au cycle de vie de l’actif, pas à une vérification effectuée “au moment du transfert”.
En passant de l’angle ingénierie à l’angle produit, la question que l’organisation reçoit aujourd’hui n’est pas “combien peut-on économiser sur la chaîne”, mais plutôt trois véritables problèmes : “combien d’unités faut-il annuler en cas d’échec”, “qui signe ce rollback”, et “comment le côté régulation consigne cela”. Le vrai concurrent de l’émission native n’est pas un token enveloppé, mais l’ancien processus de rapprochement fait à partir de tableurs.
@Dusk Cette approche n’a rien de nouveau, le mérite est d’avoir connecté Citadel et DuskVM directement à la couche du contrat natif. $DUSK n’est pas très spectaculaire aujourd’hui, mais le coût de l’échec inter-chaînes sur un marché conforme, c’est la somme que les institutions finissent vraiment par payer.
#dusk #原生发行 #跨链失败案例 $DUSK @Dusk
