#dusk $DUSK @Dusk ............ Je m’attendais à ce que les problèmes de sécurité du portefeuille viennent d’un mécanisme complexe. En recherchant Dusk, j’ai trouvé l’inverse : de minuscules détails peuvent avoir des conséquences bien plus importantes.....
Pensez à un mémo de pont comme à une étiquette de livraison. La transaction peut réussir, mais si l’étiquette manque ou renvoie à la mauvaise adresse BSC, le pont ne peut pas acheminer correctement le DUSK.
C’est pourquoi le flux BEP20 de Dusk a attiré mon attention....
Vous envoyez le DUSK au compte officiel du pont, puis vous indiquez votre adresse de portefeuille BSC dans le champ Memo. Le pont déduit des frais fixes de 1 DUSK, et la documentation officielle actuelle indique que le traitement prend normalement environ une heure.
Ça s’est approfondi..................
Dusk avertit explicitement qu’un mémo manquant ou invalide peut rendre un transfert irrécupérable. Le portefeuille a aussi, historiquement, ajouté une validation d’adresse et repensé l’affichage des adresses afin d’aider les utilisateurs à mieux vérifier le début et la fin d’une adresse.
Et maintenant, le Web Wallet va plus loin....
L’activité publique sur GitHub montre la PR #954, « Normalize BEP20 bridge memos before submission », qui est passée à ready_for_review. L’objectif est de supprimer les divergences liées aux espaces avant que la transaction du pont ne soit soumise.....
Ce dernier détail a capté mon attention..
Ce n’est pas seulement un problème de Dusk. Le 9 août, un autre pont a perdu près de 200 000 XRP après que la logique du relayer a accepté de fausses dépôts, car elle s’appuyait sur les données du mémo sans vérifier correctement la destination..
Pont différent, bug différent, même leçon....
Un mémo peut sembler être de simples métadonnées inoffensives, mais une fois qu’il fait partie du routage ou de la vérification, il devient une infrastructure critique pour la sécurité.
Pour un réseau qui gère des règlements à valeur réelle, combien de « petits » détails liés aux portefeuilles faut-il considérer comme des limites de sécurité avant que les utilisateurs ne les remarquent ?....
$BMT $EDEN
Pensez à un mémo de pont comme à une étiquette de livraison. La transaction peut réussir, mais si l’étiquette manque ou renvoie à la mauvaise adresse BSC, le pont ne peut pas acheminer correctement le DUSK.
C’est pourquoi le flux BEP20 de Dusk a attiré mon attention....
Vous envoyez le DUSK au compte officiel du pont, puis vous indiquez votre adresse de portefeuille BSC dans le champ Memo. Le pont déduit des frais fixes de 1 DUSK, et la documentation officielle actuelle indique que le traitement prend normalement environ une heure.
Ça s’est approfondi..................
Dusk avertit explicitement qu’un mémo manquant ou invalide peut rendre un transfert irrécupérable. Le portefeuille a aussi, historiquement, ajouté une validation d’adresse et repensé l’affichage des adresses afin d’aider les utilisateurs à mieux vérifier le début et la fin d’une adresse.
Et maintenant, le Web Wallet va plus loin....
L’activité publique sur GitHub montre la PR #954, « Normalize BEP20 bridge memos before submission », qui est passée à ready_for_review. L’objectif est de supprimer les divergences liées aux espaces avant que la transaction du pont ne soit soumise.....
Ce dernier détail a capté mon attention..
Ce n’est pas seulement un problème de Dusk. Le 9 août, un autre pont a perdu près de 200 000 XRP après que la logique du relayer a accepté de fausses dépôts, car elle s’appuyait sur les données du mémo sans vérifier correctement la destination..
Pont différent, bug différent, même leçon....
Un mémo peut sembler être de simples métadonnées inoffensives, mais une fois qu’il fait partie du routage ou de la vérification, il devient une infrastructure critique pour la sécurité.
Pour un réseau qui gère des règlements à valeur réelle, combien de « petits » détails liés aux portefeuilles faut-il considérer comme des limites de sécurité avant que les utilisateurs ne les remarquent ?....
$BMT $EDEN
