#dusk $DUSK Trad DUSK的 dépôts GitHub sont bien plus intéressants que de lire le livre blanc. D’avril à juin 2026, dans le dépôt rusk, un mot-clé revient sans cesse : « revocation ». Trois versions minor release consécutives viennent compléter des cas limites liés à la révocation des identifiants Citadel : que faire des jetons « d’investisseur qualifié » signés après la faillite d’une institution ? comment synchroniser des listes de révocation entre juridictions ? et, après une révocation, faut-il annuler rétroactivement les preuves ZK déjà générées ?
Ce point correspond précisément à la faiblesse la plus facile à ignorer chez DUSK. Tout le monde se focalise sur le privacy UTXO de Phoenix et sur la divulgation sélective côté Hedger, en se disant que le modèle « obscurité par défaut + audit autorisé » résout déjà les tensions entre conformité et confidentialité. Mais dans la couche d’identité de Citadel, le point d’ancrage de la confiance n’est pas le circuit ZK : c’est l’émetteur lui-même. Si l’émetteur fait faillite ou si ses licences sont révoquées, tous les credentials qu’il a historiquement signés deviennent, sur le plan juridique, instantanément du papier sans valeur ; en revanche, les preuves générées en chaîne à partir de ces credentials ne s’invalident pas automatiquement.
On retombe alors sur un vieux problème : « je remplissais les conditions à l’époque » et « je les remplis encore » sont deux choses différentes. La seconde nécessite une vérification de révocation en temps réel ; cette vérification en temps réel passe soit par la chaîne (coûteux en gas), soit par un oracle (dégradation du modèle de confiance). La documentation actuelle de DUSK dit peu de choses sur la fenêtre de latence de révocation, l’assurance responsabilité de l’émetteur, ou le mappage des credentials entre juridictions — or ce sont précisément des paramètres de gouvernance qui viennent en premier dans la due diligence des institutions licenciées.
Le code peut résoudre « comment prouver », mais il ne peut pas résoudre « qui a le dernier mot ». Si DUSK, dans la prochaine année, n’inscrit pas le cadre de gouvernance de Citadel dans des accords annexes juridiquement contraignants, et n’exige pas qu’un acteur licencié comme NPEX ou 21X assume par contrat la responsabilité de la délivrance des credentials, alors, aux yeux des institutions, DUSK restera à jamais une « preuve de concept technique », et non une infrastructure financière gérée et digne de confiance.
#dusk @Dusk
Ce point correspond précisément à la faiblesse la plus facile à ignorer chez DUSK. Tout le monde se focalise sur le privacy UTXO de Phoenix et sur la divulgation sélective côté Hedger, en se disant que le modèle « obscurité par défaut + audit autorisé » résout déjà les tensions entre conformité et confidentialité. Mais dans la couche d’identité de Citadel, le point d’ancrage de la confiance n’est pas le circuit ZK : c’est l’émetteur lui-même. Si l’émetteur fait faillite ou si ses licences sont révoquées, tous les credentials qu’il a historiquement signés deviennent, sur le plan juridique, instantanément du papier sans valeur ; en revanche, les preuves générées en chaîne à partir de ces credentials ne s’invalident pas automatiquement.
On retombe alors sur un vieux problème : « je remplissais les conditions à l’époque » et « je les remplis encore » sont deux choses différentes. La seconde nécessite une vérification de révocation en temps réel ; cette vérification en temps réel passe soit par la chaîne (coûteux en gas), soit par un oracle (dégradation du modèle de confiance). La documentation actuelle de DUSK dit peu de choses sur la fenêtre de latence de révocation, l’assurance responsabilité de l’émetteur, ou le mappage des credentials entre juridictions — or ce sont précisément des paramètres de gouvernance qui viennent en premier dans la due diligence des institutions licenciées.
Le code peut résoudre « comment prouver », mais il ne peut pas résoudre « qui a le dernier mot ». Si DUSK, dans la prochaine année, n’inscrit pas le cadre de gouvernance de Citadel dans des accords annexes juridiquement contraignants, et n’exige pas qu’un acteur licencié comme NPEX ou 21X assume par contrat la responsabilité de la délivrance des credentials, alors, aux yeux des institutions, DUSK restera à jamais une « preuve de concept technique », et non une infrastructure financière gérée et digne de confiance.
#dusk @Dusk
Citadel的凭证吊销到底多难解决
0%
ZK证明的"时间差"风险有多大?
100%
签发方倒闭后链上凭证怎么办?
0%
1 Votes • Vote fermé