DUSK que tu as entre les mains, sur quelle chaîne se trouve-t-il vraiment ?
Ne réponds pas tout de suite : cette question est plus difficile qu’elle n’en a l’air.
Le pont natif que DUSK pousse vise à acheminer les actifs directement sous leur forme native, avec pour seul rôle celui des validateurs d’exécuter les transferts inter-couches, sans tickets wrapped, et sans confier les jetons à un dépositaire tiers inconnu. Par rapport aux ponts inter-chaînes centralisés qui confient les actifs à un tiers en garde, c’est effectivement moins de confiance à transférer, et aussi moins de tracas liés à la “fragmentation” des wrappers.
Mais la phrase “sans wrap” ne s’applique pas à DUSK lui-même.
DUSK existe déjà sous trois formes : sur une chaîne native, une variante sous forme ERC20 sur Ethereum, et une autre en BEP20 sur la chaîne BNB. S’il se “dédouble”, c’est justement parce qu’il faut passer par un pont pour atteindre d’autres chaînes. À l’origine, un DUSK unique devait relier en continu ses trois couches. Mais dès qu’il franchit Ethereum et BNB, il devient un ticket sur la chaîne de l’autre, et cette inadéquation d’identité peut ne pas sauter aux yeux des nouveaux utilisateurs.
Or, le pont a justement connu des ennuis. Un soir de janvier 2026, le service de pont de Dusk a été compromis : de la première transaction, où 9 000 DUSK ont été volés, jusqu’à la dernière, où plus de 8,3 millions de DUSK n’ont pas pu être transférés parce que le pont a été arrêté d’urgence. Au total, environ 12 millions de DUSK ont été perdus sur la période. Il faut souligner que ce n’est pas une faille de la couche de consensus DuskDS : les signatures du portefeuille de l’équipe utilisé par le pont ont été prises. D’après les autorités officielles, aucun fonds utilisateur n’aurait été touché : les fonds transférés provenaient du portefeuille opérationnel de l’équipe.
J’ai mis cette affaire en parallèle avec la notion de “sans wrap” : ce n’est pas une contradiction, mais un rappel. Le pont natif résout la question de la confiance liée à la forme des actifs ; mais qui gère les clés, et comment elles sont gérées, de l’autre côté du pont… c’est cela qui a réellement été mis à l’épreuve ce soir-là. Après coup, l’équipe a reconstruit le pont : séparation entre signature et traitement des événements, réduction de l’exposition des portefeuilles “hot”, et bascule vers des recharges manuelles via un “cold wallet”.
Côté EVM, le réseau est encore, à ce jour, un réseau de test : le pont natif inter-couches peut s’entraîner sur DuskEVM, mais les flux d’actifs de niveau production devront attendre la maturation du réseau.
C’est pourquoi j’accorde davantage d’importance à la valeur réelle de “la réduction des fragments wrapped”, plutôt qu’aux slogans de “sans aucun wrapper”.
Ta première fois avec DUSK, c’était sur quelle chaîne ? Avec ces trois formes coexistantes, c’est plus simple pour toi… ou plus compliqué ?
@Dusk
#dusk $DUSK
Ne réponds pas tout de suite : cette question est plus difficile qu’elle n’en a l’air.
Le pont natif que DUSK pousse vise à acheminer les actifs directement sous leur forme native, avec pour seul rôle celui des validateurs d’exécuter les transferts inter-couches, sans tickets wrapped, et sans confier les jetons à un dépositaire tiers inconnu. Par rapport aux ponts inter-chaînes centralisés qui confient les actifs à un tiers en garde, c’est effectivement moins de confiance à transférer, et aussi moins de tracas liés à la “fragmentation” des wrappers.
Mais la phrase “sans wrap” ne s’applique pas à DUSK lui-même.
DUSK existe déjà sous trois formes : sur une chaîne native, une variante sous forme ERC20 sur Ethereum, et une autre en BEP20 sur la chaîne BNB. S’il se “dédouble”, c’est justement parce qu’il faut passer par un pont pour atteindre d’autres chaînes. À l’origine, un DUSK unique devait relier en continu ses trois couches. Mais dès qu’il franchit Ethereum et BNB, il devient un ticket sur la chaîne de l’autre, et cette inadéquation d’identité peut ne pas sauter aux yeux des nouveaux utilisateurs.
Or, le pont a justement connu des ennuis. Un soir de janvier 2026, le service de pont de Dusk a été compromis : de la première transaction, où 9 000 DUSK ont été volés, jusqu’à la dernière, où plus de 8,3 millions de DUSK n’ont pas pu être transférés parce que le pont a été arrêté d’urgence. Au total, environ 12 millions de DUSK ont été perdus sur la période. Il faut souligner que ce n’est pas une faille de la couche de consensus DuskDS : les signatures du portefeuille de l’équipe utilisé par le pont ont été prises. D’après les autorités officielles, aucun fonds utilisateur n’aurait été touché : les fonds transférés provenaient du portefeuille opérationnel de l’équipe.
J’ai mis cette affaire en parallèle avec la notion de “sans wrap” : ce n’est pas une contradiction, mais un rappel. Le pont natif résout la question de la confiance liée à la forme des actifs ; mais qui gère les clés, et comment elles sont gérées, de l’autre côté du pont… c’est cela qui a réellement été mis à l’épreuve ce soir-là. Après coup, l’équipe a reconstruit le pont : séparation entre signature et traitement des événements, réduction de l’exposition des portefeuilles “hot”, et bascule vers des recharges manuelles via un “cold wallet”.
Côté EVM, le réseau est encore, à ce jour, un réseau de test : le pont natif inter-couches peut s’entraîner sur DuskEVM, mais les flux d’actifs de niveau production devront attendre la maturation du réseau.
C’est pourquoi j’accorde davantage d’importance à la valeur réelle de “la réduction des fragments wrapped”, plutôt qu’aux slogans de “sans aucun wrapper”.
Ta première fois avec DUSK, c’était sur quelle chaîne ? Avec ces trois formes coexistantes, c’est plus simple pour toi… ou plus compliqué ?
@Dusk
#dusk $DUSK
省事
0%
添乱
100%
1 Votes • Vote fermé