$DUSK $aDUSK #dusk — la couche conçue pour l’adoption par les développeurs utilise par défaut la transparence, pas la confidentialité.
La plupart des chaînes « privées » traitent la conformité comme une réflexion après coup, greffée sur un registre public — des mixers, un masquage optionnel, un contrôle KYC placé en dehors du protocole. L’approche de Dusk était différente : la confidentialité est intégrée à même le règlement. D’après la documentation de Dusk, le DuskDS natif vous propose deux modèles de transaction — Moonlight (transparent, soldes visibles) ou Phoenix (notes chiffrées, confidentialité protégée par défaut avec la preuve à connaissance nulle). @DuskFoundation a construit son discours sur la conformité à partir de ce défaut, pas d’un ajout.
Ensuite, j’ai regardé DuskEVM, la couche compatible avec Solidity, conçue pour attirer des développeurs. La documentation décrit Hedger, le module de confidentialité par chiffrement homomorphe / ZK, comme un outil auquel on fait appel « le cas échéant ». Les contrats standards sur DuskEVM se comportent comme de simples contrats EVM partout — transparents, sauf si quelqu’un connecte explicitement Hedger. Le modèle « greffé » que Dusk critique chez d’autres chaînes apparaît aussi dans 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 défauts cousus ensemble — et la couche que la plupart des builders toucheront hérite de la version la plus faible. Ne détruit pas la thèse, mais en réduit le périmètre. À vérifier : les premières déploiements de DuskEVM intègrent-ils réellement Hedger, ou lancent-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 une réflexion après coup, greffée sur un registre public — des mixers, un masquage optionnel, un contrôle KYC placé en dehors du protocole. L’approche de Dusk était différente : la confidentialité est intégrée à même le règlement. D’après la documentation de Dusk, le DuskDS natif vous propose deux modèles de transaction — Moonlight (transparent, soldes visibles) ou Phoenix (notes chiffrées, confidentialité protégée par défaut avec la preuve à connaissance nulle). @DuskFoundation a construit son discours sur la conformité à partir de ce défaut, pas d’un ajout.
Ensuite, j’ai regardé DuskEVM, la couche compatible avec Solidity, conçue pour attirer des développeurs. La documentation décrit Hedger, le module de confidentialité par chiffrement homomorphe / ZK, comme un outil auquel on fait appel « le cas échéant ». Les contrats standards sur DuskEVM se comportent comme de simples contrats EVM partout — transparents, sauf si quelqu’un connecte explicitement Hedger. Le modèle « greffé » que Dusk critique chez d’autres chaînes apparaît aussi dans 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 défauts cousus ensemble — et la couche que la plupart des builders toucheront hérite de la version la plus faible. Ne détruit pas la thèse, mais en réduit le périmètre. À vérifier : les premières déploiements de DuskEVM intègrent-ils réellement Hedger, ou lancent-ils du transparent comme n’importe quelle autre chaîne EVM ?
#dusk $DUSK @Dusk
