#GIWA #链上安全 L’ID d’une chaîne semble être le bon… et les actifs peuvent-ils alors traverser en toute sécurité ? L’affaire GIWA d’aujourd’hui fournit un contre-exemple saisissant : l’étape la plus dangereuse n’est peut-être pas l’avertissement qui s’affiche quand le portefeuille s’ouvre, mais plutôt le moment où l’utilisateur et l’application pensent, à tort, avoir déjà vérifié l’identité du réseau.
D’abord, remettions la chronologie dans l’ordre. Le 27 septembre à 15 h 18 (heure de Pékin), l’annonce officielle de GIWA indique clairement que le réseau principal n’est pas en fonctionnement à l’heure actuelle. Toute publication affirmant maîtriser le RPC du réseau principal GIWA est donc inexacte, et GIWA invite à vérifier le contrat d’interaction. À 16 h 06, DyorSwap publie un avis d’incident de sécurité : le prétendu « réseau principal GIWA » qu’il avait identifié auparavant était en réalité une fausse chaîne montée par des escrocs. L’annonce indique que le faux réseau a utilisé l’ID de chaîne 9134, ce qui rendait une validation initiale crédible ; grâce à un pont inter-chaînes correspondant, des pertes importantes auraient déjà eu lieu. Ces pertes proviennent de DyorSwap ; le montant exact, les adresses et la chaîne de responsabilité restent à vérifier de manière indépendante.
Ce qui doit vraiment alerter ici n’est pas de savoir si un chiffre a été correctement saisi. L’ID de chaîne ne dit que quel réseau numéroté le portefeuille pense utiliser ; il ne prouve pas que le RPC appartient à l’équipe officielle du projet, et ne garantit pas non plus les contrats du pont, le front-end ni l’acheminement effectif des fonds. Les escrocs peuvent parfaitement copier une configuration apparemment correcte, puis pousser les utilisateurs à traverser l’inter-chaînes avec un récit du type « le réseau principal est déjà ouvert ». La documentation officielle de GIWA indique aujourd’hui publiquement le testnet Sepolia ; la page principale est toujours marquée en cours de développement. Avoir un testnet utilisable et pouvoir recevoir en toute sécurité des actifs réels sur le réseau principal sont deux choses différentes.
Mon avis est que cette affaire révèle une « réduction de la responsabilité de vérification » à un contrôle unique : l’état officiel du projet, le réseau fourni par le front-end de l’application, le contrat du pont inter-chaînes et la page de confirmation du portefeuille. S’ils ne correspondent pas entre eux de manière indépendante, alors le déblocage ne repose que sur une formalité : la vérification n’est qu’une mise en scène. DyorSwap a déjà indiqué qu’il contacterait l’équipe sécurité pour retracer les fonds, conserver les preuves et préparer une étude sur l’utilisation d’une compensation depuis le trésor ; ce n’est qu’un plan de traitement, et cela ne signifie pas que l’éligibilité, le montant ou le calendrier de l’indemnisation soient déjà confirmés.
La prochaine étape à regarder n’est donc pas qui s’excuse en premier, mais plutôt : les adresses vérifiables, les transactions, l’étendue des dommages, les règles de compensation et l’exécution réelle. Si le traçage on-chain montre que les chemins affectés ne correspondent pas à ce qui est décrit dans l’annonce, je corrigerai mon analyse du mécanisme de l’incident ; si un processus de vérification complet, vérifiable et réplicable est publié, cela modifiera aussi mon évaluation des risques liés à la suite. Selon vous, avant la mise en ligne d’un produit inter-chaînes sur un nouveau réseau, qu’est-ce qu’on ne doit surtout pas supprimer : la vérification de l’origine du réseau officiel, ou l’audit indépendant du contrat du pont et du parcours des fonds ?
D’abord, remettions la chronologie dans l’ordre. Le 27 septembre à 15 h 18 (heure de Pékin), l’annonce officielle de GIWA indique clairement que le réseau principal n’est pas en fonctionnement à l’heure actuelle. Toute publication affirmant maîtriser le RPC du réseau principal GIWA est donc inexacte, et GIWA invite à vérifier le contrat d’interaction. À 16 h 06, DyorSwap publie un avis d’incident de sécurité : le prétendu « réseau principal GIWA » qu’il avait identifié auparavant était en réalité une fausse chaîne montée par des escrocs. L’annonce indique que le faux réseau a utilisé l’ID de chaîne 9134, ce qui rendait une validation initiale crédible ; grâce à un pont inter-chaînes correspondant, des pertes importantes auraient déjà eu lieu. Ces pertes proviennent de DyorSwap ; le montant exact, les adresses et la chaîne de responsabilité restent à vérifier de manière indépendante.
Ce qui doit vraiment alerter ici n’est pas de savoir si un chiffre a été correctement saisi. L’ID de chaîne ne dit que quel réseau numéroté le portefeuille pense utiliser ; il ne prouve pas que le RPC appartient à l’équipe officielle du projet, et ne garantit pas non plus les contrats du pont, le front-end ni l’acheminement effectif des fonds. Les escrocs peuvent parfaitement copier une configuration apparemment correcte, puis pousser les utilisateurs à traverser l’inter-chaînes avec un récit du type « le réseau principal est déjà ouvert ». La documentation officielle de GIWA indique aujourd’hui publiquement le testnet Sepolia ; la page principale est toujours marquée en cours de développement. Avoir un testnet utilisable et pouvoir recevoir en toute sécurité des actifs réels sur le réseau principal sont deux choses différentes.
Mon avis est que cette affaire révèle une « réduction de la responsabilité de vérification » à un contrôle unique : l’état officiel du projet, le réseau fourni par le front-end de l’application, le contrat du pont inter-chaînes et la page de confirmation du portefeuille. S’ils ne correspondent pas entre eux de manière indépendante, alors le déblocage ne repose que sur une formalité : la vérification n’est qu’une mise en scène. DyorSwap a déjà indiqué qu’il contacterait l’équipe sécurité pour retracer les fonds, conserver les preuves et préparer une étude sur l’utilisation d’une compensation depuis le trésor ; ce n’est qu’un plan de traitement, et cela ne signifie pas que l’éligibilité, le montant ou le calendrier de l’indemnisation soient déjà confirmés.
La prochaine étape à regarder n’est donc pas qui s’excuse en premier, mais plutôt : les adresses vérifiables, les transactions, l’étendue des dommages, les règles de compensation et l’exécution réelle. Si le traçage on-chain montre que les chemins affectés ne correspondent pas à ce qui est décrit dans l’annonce, je corrigerai mon analyse du mécanisme de l’incident ; si un processus de vérification complet, vérifiable et réplicable est publié, cela modifiera aussi mon évaluation des risques liés à la suite. Selon vous, avant la mise en ligne d’un produit inter-chaînes sur un nouveau réseau, qu’est-ce qu’on ne doit surtout pas supprimer : la vérification de l’origine du réseau officiel, ou l’audit indépendant du contrat du pont et du parcours des fonds ?
