$DUSK $aDUSK #dusk — la couche conçue pour l’adoption par les développeurs a, par défaut, un paramètre transparent, et non privé.
La plupart des « chaînes privées » traitent la conformité comme un détail ajouté après coup à un registre public — des mixers, un masquage optionnel, une porte KYC posée en dehors du protocole. La proposition de Dusk était différente : la confidentialité intégrée directement au règlement lui-même. D’après la documentation de Dusk, DuskDS natif vous offre deux modèles de transaction — Moonlight (transparent, soldes visibles) ou Phoenix (notes protégées, confidentialité à base de preuves à divulgation nulle par défaut). @DuskFoundation a construit son récit de conformité à partir de ce défaut, et non comme un ajout.
Ensuite, j’ai examiné DuskEVM, la couche compatible avec Solidity, conçue pour attirer les développeurs. La documentation décrit Hedger, le module de confidentialité par chiffrement homomorphe / ZK, comme un outil vers lequel on se tourne « lorsque c’est approprié ». Des contrats simples sur DuskEVM se comportent comme des contrats EVM simples n’importe où — transparents, sauf si quelqu’un branche explicitement Hedger. Le modèle « ajouté par boulonnage » que Dusk critique sur d’autres chaînes apparaît sur sa propre surface de croissance.
Ce qui a changé pour moi : « la confidentialité dès la conception » n’est pas une seule propriété ici, mais deux valeurs par défaut cousues ensemble — et la couche que la plupart des créateurs vont réellement toucher hérite de la plus faible. Ce n’est pas mortel pour la thèse, ça la restreint simplement. À vérifier : les déploiements initiaux de DuskEVM intègrent-ils réellement Hedger, ou livrent-ils du transparent, comme n’importe quelle autre chaîne EVM ?
#dusk $DUSK @Dusk
La plupart des « chaînes privées » traitent la conformité comme un détail ajouté après coup à un registre public — des mixers, un masquage optionnel, une porte KYC posée en dehors du protocole. La proposition de Dusk était différente : la confidentialité intégrée directement au règlement lui-même. D’après la documentation de Dusk, DuskDS natif vous offre deux modèles de transaction — Moonlight (transparent, soldes visibles) ou Phoenix (notes protégées, confidentialité à base de preuves à divulgation nulle par défaut). @DuskFoundation a construit son récit de conformité à partir de ce défaut, et non comme un ajout.
Ensuite, j’ai examiné DuskEVM, la couche compatible avec Solidity, conçue pour attirer les développeurs. La documentation décrit Hedger, le module de confidentialité par chiffrement homomorphe / ZK, comme un outil vers lequel on se tourne « lorsque c’est approprié ». Des contrats simples sur DuskEVM se comportent comme des contrats EVM simples n’importe où — transparents, sauf si quelqu’un branche explicitement Hedger. Le modèle « ajouté par boulonnage » que Dusk critique sur d’autres chaînes apparaît sur sa propre surface de croissance.
Ce qui a changé pour moi : « la confidentialité dès la conception » n’est pas une seule propriété ici, mais deux valeurs par défaut cousues ensemble — et la couche que la plupart des créateurs vont réellement toucher hérite de la plus faible. Ce n’est pas mortel pour la thèse, ça la restreint simplement. À vérifier : les déploiements initiaux de DuskEVM intègrent-ils réellement Hedger, ou livrent-ils du transparent, comme n’importe quelle autre chaîne EVM ?
#dusk $DUSK @Dusk