#dusk Je suis passé en revue et remis dans le bon ordre le document d’architecture de @Dusk . La première difficulté qui m’a bloqué n’a pas été la preuve à divulgation nulle (zéro connaissance), mais plutôt la raison pour laquelle, pour un même réseau, il faudrait conserver à la fois deux chemins de transfert : un public et un privé. Beaucoup de projets traitent la confidentialité comme un simple interrupteur : quand il est activé, on ne voit plus rien ; quand il est désactivé, tout devient entièrement transparent. En revanche, une fois qu’on entre dans un scénario financier réel, ce choix “soit l’un, soit l’autre” ne suffit plus : l’initiateur veut protéger son solde, l’émetteur doit parfois vérifier son éligibilité, et l’auditeur doit aussi obtenir des preuves sur un périmètre précis.
À la couche inférieure, Dusk a implémenté Moonlight comme un modèle de compte public, et Phoenix comme un modèle d’UTXO orienté confidentialité. Les deux peuvent transférer $DUSK , payer le Gas, et servir de point d’entrée pour l’exécution des contrats. Au-dessus, on distingue DuskVM pour exécuter directement des contrats Rust/WASM, et DuskEVM pour les outils de la chaîne Solidity. L’intérêt réel de ce duo n’est pas le terme “chaîne de confidentialité” : c’est plutôt le fait que le règlement public, les transferts privés et la compatibilité applicative portent chacun des responsabilités différentes.
Mais un découpage en couches clair ne signifie pas que la frontière utilisateur soit naturellement claire. À quel moment les fonds passent du solde public au solde privé, qui dispose d’une permission de divulgation sélective, si l’application passe par DuskVM ou DuskEVM, si l’état entre couches peut être vérifié par n’importe qui : tout cela augmente la charge de compréhension. En particulier dans les actifs soumis à la réglementation, la confidentialité ne consiste pas à refuser de divulguer, mais à borner l’objet, le contenu et le moment de la divulgation. Si la conception des permissions est ambiguë, elle risque au final de devenir une autre forme de boîte noire.
Donc, quand je regarde Dusk maintenant, je ne me contente pas de me demander s’il est capable de cacher un transfert. Ce qui m’importe davantage, c’est : quand il faut du public, peut-on fournir des preuves suffisantes ? quand il faut de la confidentialité, peut-on limiter les fuites d’informations sans rapport ? et après la commutation entre les deux chemins, est-ce que la logique reste compréhensible et nette ? La direction d’architecture est valable ; le vrai défi, c’est de laisser la complexité dans le protocole, et non de la refiler à l’utilisateur.
$SNXXB $BTC
À la couche inférieure, Dusk a implémenté Moonlight comme un modèle de compte public, et Phoenix comme un modèle d’UTXO orienté confidentialité. Les deux peuvent transférer $DUSK , payer le Gas, et servir de point d’entrée pour l’exécution des contrats. Au-dessus, on distingue DuskVM pour exécuter directement des contrats Rust/WASM, et DuskEVM pour les outils de la chaîne Solidity. L’intérêt réel de ce duo n’est pas le terme “chaîne de confidentialité” : c’est plutôt le fait que le règlement public, les transferts privés et la compatibilité applicative portent chacun des responsabilités différentes.
Mais un découpage en couches clair ne signifie pas que la frontière utilisateur soit naturellement claire. À quel moment les fonds passent du solde public au solde privé, qui dispose d’une permission de divulgation sélective, si l’application passe par DuskVM ou DuskEVM, si l’état entre couches peut être vérifié par n’importe qui : tout cela augmente la charge de compréhension. En particulier dans les actifs soumis à la réglementation, la confidentialité ne consiste pas à refuser de divulguer, mais à borner l’objet, le contenu et le moment de la divulgation. Si la conception des permissions est ambiguë, elle risque au final de devenir une autre forme de boîte noire.
Donc, quand je regarde Dusk maintenant, je ne me contente pas de me demander s’il est capable de cacher un transfert. Ce qui m’importe davantage, c’est : quand il faut du public, peut-on fournir des preuves suffisantes ? quand il faut de la confidentialité, peut-on limiter les fuites d’informations sans rapport ? et après la commutation entre les deux chemins, est-ce que la logique reste compréhensible et nette ? La direction d’architecture est valable ; le vrai défi, c’est de laisser la complexité dans le protocole, et non de la refiler à l’utilisateur.
$SNXXB $BTC
