#dusk $DUSK
J’ai une question que je n’arrive pas à comprendre au sujet de DUSK !
Le pont de Dusk et les ponts de transfert inter-chaînes “classiques” ne sont tout simplement pas de la même espèce.
La logique des deux registres qu’il synchronise est totalement différente : du côté DuskDS, c’est un registre de règlement axé sur la confidentialité ; tous les soldes et toutes les transactions sont enveloppés dans du chiffrement, donc de l’extérieur, on ne voit que du charabia. Du côté DuskEVM, on exécute des smart contracts de XSC Securities, qui exigent transparence et auditabilité.
Le rôle du pont est le suivant : vous mettez en gage une certaine quantité d’un actif XSC au niveau de la confidentialité, puis vous passez à une transaction au niveau EVM. Avant cela, le pont doit d’abord vérifier que cet actif existe réellement, qu’il n’a pas été falsifié ni réutilisé.
Mais il y a un nœud gordien. Comme le registre de confidentialité chiffre les données, comment le pont peut-il “voir” que l’actif existe réellement ? Il ne peut pas. Du coup, il faut que l’utilisateur soumette lui-même une preuve ZK : prouver que je détiens bien cette quantité de XSC dans le registre de confidentialité et que la transition d’état est valide.
La génération de la preuve effectue un calcul ZK une fois, puis lors de la vérification le pont refait le calcul une deuxième fois — donc une double exécution ZK. La sécurité du pont dépend entièrement de ce système de preuve.
Ensuite, OtterSec a découvert une faille dans dusk-plonk. Le vérificateur a sauté une vérification clé, et une fausse preuve a été acceptée directement. En pratique, sur une seule couche, c’est comme “fabriquer de la monnaie” : 60 millions de dollars ont été bloqués ; c’est corrigé.
Mais en parcourant tous les documents publics, personne ne répond à ceci : la logique de vérification du pont natif est-elle exactement la même “circuit” que dusk-plonk ?
Si ce n’est pas le cas, alors c’est une bonne nouvelle. Si c’est le cas, ou si des paramètres et un modèle de circuit sont partiellement réutilisés, le problème passe d’une simple création de monnaie sur une couche à une création de monnaie inter-couches : vous contrefaites une position en XSC qui n’existe pas au niveau de la confidentialité, en utilisant une fausse preuve pour tromper le pont, puis vous faites libérer l’actif correspondant côté EVM et vous l’utilisez pour faire chuter le prix.
L’attaquant n’a même pas besoin de toucher à la logique du contrat du pont : il lui suffit qu’il y ait une brèche dans le système de preuves, et le pont devient une machine de retrait.
Soyons justes : il est possible que la vérification du pont soit implémentée de manière indépendante, avec des audits supplémentaires, mais sans que cela ait été publié. Je ne peux pas prouver qu’il n’est pas sûr, mais je n’ai pas non plus trouvé de preuve qu’il est sûr.
À ce jour, l’official n’a pas divulgué le rapport d’audit indépendant du pont natif, ni expliqué si la vérification inter-couches et dusk-plonk ont un code isolé.
Avant que NPEX n’ait migré des titres pour des centaines de millions d’euros, cette question doit recevoir une réponse claire et directe.
Ce n’est pas “La faille a été corrigée” qui peut suffire. Le pont ne relie pas seulement deux chaînes : il relie le monde de la confidentialité et le monde public, c’est une seule porte. La porte a-t-elle des verrous ? Ne l’apprenez pas seulement une fois que quelqu’un est entré.
@Dusk
J’ai une question que je n’arrive pas à comprendre au sujet de DUSK !
Le pont de Dusk et les ponts de transfert inter-chaînes “classiques” ne sont tout simplement pas de la même espèce.
La logique des deux registres qu’il synchronise est totalement différente : du côté DuskDS, c’est un registre de règlement axé sur la confidentialité ; tous les soldes et toutes les transactions sont enveloppés dans du chiffrement, donc de l’extérieur, on ne voit que du charabia. Du côté DuskEVM, on exécute des smart contracts de XSC Securities, qui exigent transparence et auditabilité.
Le rôle du pont est le suivant : vous mettez en gage une certaine quantité d’un actif XSC au niveau de la confidentialité, puis vous passez à une transaction au niveau EVM. Avant cela, le pont doit d’abord vérifier que cet actif existe réellement, qu’il n’a pas été falsifié ni réutilisé.
Mais il y a un nœud gordien. Comme le registre de confidentialité chiffre les données, comment le pont peut-il “voir” que l’actif existe réellement ? Il ne peut pas. Du coup, il faut que l’utilisateur soumette lui-même une preuve ZK : prouver que je détiens bien cette quantité de XSC dans le registre de confidentialité et que la transition d’état est valide.
La génération de la preuve effectue un calcul ZK une fois, puis lors de la vérification le pont refait le calcul une deuxième fois — donc une double exécution ZK. La sécurité du pont dépend entièrement de ce système de preuve.
Ensuite, OtterSec a découvert une faille dans dusk-plonk. Le vérificateur a sauté une vérification clé, et une fausse preuve a été acceptée directement. En pratique, sur une seule couche, c’est comme “fabriquer de la monnaie” : 60 millions de dollars ont été bloqués ; c’est corrigé.
Mais en parcourant tous les documents publics, personne ne répond à ceci : la logique de vérification du pont natif est-elle exactement la même “circuit” que dusk-plonk ?
Si ce n’est pas le cas, alors c’est une bonne nouvelle. Si c’est le cas, ou si des paramètres et un modèle de circuit sont partiellement réutilisés, le problème passe d’une simple création de monnaie sur une couche à une création de monnaie inter-couches : vous contrefaites une position en XSC qui n’existe pas au niveau de la confidentialité, en utilisant une fausse preuve pour tromper le pont, puis vous faites libérer l’actif correspondant côté EVM et vous l’utilisez pour faire chuter le prix.
L’attaquant n’a même pas besoin de toucher à la logique du contrat du pont : il lui suffit qu’il y ait une brèche dans le système de preuves, et le pont devient une machine de retrait.
Soyons justes : il est possible que la vérification du pont soit implémentée de manière indépendante, avec des audits supplémentaires, mais sans que cela ait été publié. Je ne peux pas prouver qu’il n’est pas sûr, mais je n’ai pas non plus trouvé de preuve qu’il est sûr.
À ce jour, l’official n’a pas divulgué le rapport d’audit indépendant du pont natif, ni expliqué si la vérification inter-couches et dusk-plonk ont un code isolé.
Avant que NPEX n’ait migré des titres pour des centaines de millions d’euros, cette question doit recevoir une réponse claire et directe.
Ce n’est pas “La faille a été corrigée” qui peut suffire. Le pont ne relie pas seulement deux chaînes : il relie le monde de la confidentialité et le monde public, c’est une seule porte. La porte a-t-elle des verrous ? Ne l’apprenez pas seulement une fois que quelqu’un est entré.
@Dusk