Lorsqu'on évoque Dusk, la plupart des gens pensent immédiatement à « transactions privées ». Mais en examinant de près la conception de ce système par la Dusk Foundation, on réalise que leur véritable enjeu dépasse la simple exécution de la transaction — l’essentiel réside dans la capacité du système à fournir une « explication auditable » lorsque la transaction est rejetée.

Dans le monde des actifs réglementés, ce n’est pas un bonus, mais une exigence fondamentale.

Le processus de transaction de Dusk n’est pas aussi simple qu’une signature suivie d’une mise à jour d’état. Il doit suivre toute une chaîne de processus : vérification des règles, génération de preuves à divulgation zéro, validation sur la chaîne. Cela semble logique, mais le problème se cache ici — dès qu’une transaction est rejetée, cela peut être dû à un non-respect des critères, à une période de verrouillage non levée, à un plafond atteint, ou même à un problème avec un certain état. Ces raisons peuvent provenir de n’importe quelle règle.

Si le système ne renvoie qu’un simple « preuve échouée », les institutions financières et les auditeurs seront furieux. Ils veulent savoir précisément quelle règle a bloqué la transaction, s’il est possible d’ajuster les paramètres, ou si une intervention humaine est nécessaire. Un rejet vague est inacceptable.

Le défi technique auquel Dusk est confronté est le suivant : comment garder les détails des règles confidentiels sans les rendre publics, tout en assurant que le fait d’être « rejeté » soit lui-même vérifiable. En d’autres termes, le rejet ne doit pas être une boîte noire, mais un état prouvable sur la chaîne, pouvant être vérifié par un tiers. Le système doit prouver que « j’ai rejeté conformément aux règles établies » et que « tout le processus de rejet est conforme ».

En observant les progrès de Dusk, je me concentre sur trois points :

1. Le rejet correspond-il à une contrainte de preuve claire, plutôt qu’à un échec vague ?
2. Sans divulguer les paramètres des règles, la preuve peut-elle supporter une vérification par un auditeur ?
3. La couche applicative peut-elle, à partir de ces informations précises de rejet, concevoir un processus permettant à l’utilisateur de corriger ses erreurs ?

Si Dusk parvient réellement à rendre le « chemin de rejet » explicable, cela lui conférera la capacité de gérer des transactions conformes. Sinon, peu importe la puissance de son exécution de la confidentialité, il échouera face aux exigences du vrai monde des affaires.