Beaucoup de gens regardent Dusk et se concentrent uniquement sur la confidentialité, mais pour la finance réglementée, la confidentialité n’est qu’un billet d’entrée. Ce qui crée la vraie différence, c’est de savoir si les règles peuvent être appliquées de manière contraignante au moment même où la transaction a lieu, plutôt que de s’en remettre, après coup, aux avocats, aux dépositaires ou à l’ajout d’une formalité par la bourse. L’architecture de Dusk mérite d’être disséquée davantage que celle de la plupart des blockchains axées sur la confidentialité.
@Dusk
Phoenix utilise des preuves à divulgation nulle pour masquer les montants et les adresses, Moonlight conserve des parcours de compte transparents, Citadel fait une divulgation sélective, et XSC intègre directement dans la logique de la transaction des seuils d’éligibilité, des restrictions de transfert et des obligations de reporting. En comparaison, pour les jetons de titres sur Ethereum, l’ERC-3643 repose souvent sur des contrats autorisés et une oracle d’identité hors chaîne : les détails de transaction restent alors publics et analysables on-chain ; Zcash ne cache que les montants, et Tornado Cash a été traqué par les régulateurs en raison d’un manque d’identité conforme. Dusk veut résoudre simultanément « ne pas être visible » et « être contrôlé ».

C’est la complexité du produit qui fait vraiment la différence. Un actif avec droit de vote, procédure de restauration, divulgation hiérarchisée et période de verrouillage : un seul transfert peut déclencher en même temps plus de cinq contraintes. Par exemple : le détenteur est-il encore dans la liste blanche la plus récente ? Le nombre de détenteurs investisseurs qualifiés après le transfert est-il passé la limite ? La période de verrouillage est-elle terminée ? Le nœud de régulation peut-il déchiffrer le hachage correspondant ? Le poids du droit de vote se gèle-t-il en fonction des positions détenues ? Les preuves PLONK peuvent prouver que ces conditions sont respectées sans exposer le graphe de transactions, à condition toutefois que la lecture de l’état du contrat n’entre pas en concurrence. PLONK n’exige aucun setup de confiance ; il convient bien à des circuits multi-contrainte comme ceux de XSC. Mais si l’on ne règle pas correctement les priorités entre les dépendances d’état, on risque soit une « confidentialité » qui passe sans que la conformité soit respectée, soit deux modules de conformité qui se recouvrent mutuellement.

Prenons un scénario vérifiable : une PME européenne émet des obligations tokenisées, en utilisant XSC pour définir que seuls les organismes de la liste blanche peuvent les détenir. Si le nombre de détenteurs dépasse 100, le marché secondaire est automatiquement suspendu ; et pour chaque transfert, un hachage d’audit est obligatoirement envoyé au nœud de régulation. Ces restrictions ne peuvent pas être imposées par de simples boutons côté front-end : elles doivent être validées de façon rigide par le circuit de preuve. L’argument de vente de Dusk tient justement à cela : la conformité n’est pas un reporting a posteriori, mais une condition préalable pour que la transaction puisse être emballée.
$BTC
Lorsque les actions de l’entreprise déclenchent un rachat obligatoire, qu’en même temps un actionnaire demande la restauration après le vol de la clé, et que le régulateur exige une divulgation immédiate : Rusk VM peut-il clarifier l’ordre des actions sans exposer le graphe des transactions ? Un blueprint est raisonnable, ce n’est pas difficile ; le difficile, c’est quand les processus se désordonnent : le système de contraintes peut-il encore tenir ses limites ? #dusk $DUSK