Binance soutient la migration de Zilliqa vers l'EVM alors que le réseau ZIL historique est abandonné

ZIL
Vulnérabilité Ledgersignature Schnorrincident de sécuritémigration EVMZilliqa
il y a 2 heuresSource: crypto.news
Binance soutient la migration de Zilliqa vers l'EVM alors que le réseau ZIL historique est abandonné

Binance a pris des mesures pour prendre en charge le réseau EVM de Zilliqa pour les dépôts et retraits de ZIL, alors que la blockchain abandonne son système de transactions hérité à la suite d'un incident de sécurité qui a exposé des milliers de comptes.

Résumé

  • Binance migrera les ZIL du réseau Zilliqa hérité vers Zilliqa EVM selon un ratio de 1:1 et gérera le processus pour les utilisateurs.
  • Zilliqa abandonne son système de transactions hérité après qu'une faille de l'application Ledger a exposé 6 772 comptes et conduit au vol d'au moins 683,13 millions de ZIL.
  • Le trading de ZIL sur Binance restera inchangé, tandis que les futurs dépôts et retraits seront traités via Zilliqa EVM.
  • Les détenteurs en auto-conservation sont transférés via un processus de migration distinct basé sur des preuves à divulgation nulle de connaissance, conçu pour abandonner les clés héritées exposées.

Binance a déclaré que les ZIL seront migrés des adresses du réseau principal Zilliqa hérité vers le réseau Zilliqa EVM selon un ratio de 1:1, la plateforme gérant le processus technique pour les utilisateurs qui détiennent le token sur sa plateforme.

Les dépôts et retraits via le réseau Zilliqa hérité sont restés suspendus sur Binance depuis le 5 août à 01h00 UTC. Une fois sa migration terminée, la plateforme ouvrira les dépôts et retraits de ZIL via Zilliqa EVM sans publier d'annonce séparée.

Les dépôts et retraits sur le Zilliqa hérité ne seront plus pris en charge après la migration. Le trading au comptant, le trading sur marge, les contrats à terme et les produits Binance Earn impliquant des ZIL resteront disponibles pendant le processus.

La décision de Binance s'inscrit dans le cadre des efforts continus de Zilliqa pour migrer les plateformes d'échange, les dépositaires et les détenteurs individuels hors de son système de transactions hérité basé sur Schnorr, après qu'une faille dans l'application Zilliqa Ledger a laissé certaines clés privées vulnérables.

La migration de Zilliqa fait suite à une faille de signature Ledger

La migration découle d'une vulnérabilité dans l'application Ledger de Zilliqa qui affectait les transactions natives non EVM signées à l'aide d'appareils Ledger.

Comme crypto.news l'a précédemment rapporté, le problème concernait la manière dont l'application générait les signatures Schnorr. Chaque signature nécessite un nombre secret aléatoire, appelé nonce, mais l'application affectée copiait incorrectement les données générées dans le tampon de signature.

L'analyse post-mortem de Zilliqa du 20 août a révélé que l'erreur laissait les 64 bits supérieurs de chaque nonce fixés à zéro, réduisant l'aléatoire nécessaire pour protéger une clé privée. Un attaquant pouvait utiliser plusieurs signatures publiques du même compte pour reconstruire sa clé privée.

Le défaut était présent dans toutes les versions publiées de l'application Zilliqa Ledger entre 2019 et 2026. Zilliqa a déclaré que le premier vol prouvé a eu lieu le 4 mars, plusieurs mois avant la détection du problème.

L'activité s'est intensifiée en juillet, et KuCoin a notifié Zilliqa le 19 juillet après avoir découvert des transactions sortantes inhabituelles depuis l'un de ses portefeuilles froids. Zilliqa a désactivé les transactions héritées le 20 juillet avant d'identifier la cause profonde le lendemain.

Le projet a ensuite confirmé qu'au moins 683,13 millions de ZIL avaient été volés sur 66 transactions. Au total, 6 772 comptes ont été identifiés comme exposés, tandis que 51 comptes ont été vidés. Zilliqa a décrit ces deux chiffres comme des totaux minimaux confirmés, car d'autres comptes exposés pourraient encore être identifiés.

Les détails initiaux étaient bien plus limités lorsque les transferts de ZIL ont été suspendus en juillet. À l'époque, Zilliqa avait divulgué qu'un partenaire de plateforme d'échange avait subi un vol de portefeuille froid, mais n'avait pas identifié la méthode d'attaque ni le montant impliqué.

Les transactions Zilliqa EVM n'ont pas été affectées par la vulnérabilité. Le projet a déclaré que les portefeuilles logiciels utilisant ses SDK pris en charge généraient correctement les nonces, tandis que la phrase de récupération stockée sur les appareils Ledger n'était pas exposée.

Les soldes ZIL sont transférés vers des adresses EVM

Corriger l'application Ledger pourrait empêcher de nouvelles signatures faibles, mais Zilliqa a déclaré qu'il ne pouvait pas sécuriser les clés privées déjà exposées via des signatures stockées de manière permanente onchain.

Le projet a par conséquent choisi d'abandonner le système de transactions hérité non EVM et de déplacer les utilisateurs vers Zilliqa EVM. Les adresses héritées sont abandonnées au fur et à mesure que les soldes sont réattribués au niveau du protocole à des adresses EVM.

Les migrations d'échanges ont été effectuées par lots, car chaque plateforme participante doit fournir et vérifier ses adresses de portefeuille EVM avant que les soldes puissent être réattribués.

Le premier hard fork de migration d'échange a eu lieu le 2 septembre, transférant les soldes détenus dans les anciens portefeuilles basés sur Schnorr vers des adresses EVM fournies par les échanges participants.

KuCoin, MEXC, OKCoin, Binance US, Bitvavo, Korbit, Indodax, Bitrue, WhiteBIT, CoinSpot et CoinSwitch ont été inclus dans le premier lot. Les utilisateurs détenant du ZIL sur les échanges participants n'ont pas eu à prendre de mesures.

Un deuxième hard fork était prévu pour le 22 septembre et couvrait CoinEx, HTX, Bitkub, GOPAX, Coinone, OKX, LBank, Crypto.com, Gate, Paribu, CEX.IO et Bitget.

Binance était resté en dehors des lots précédents. Sa dernière annonce confirme désormais que l'échange cessera de prendre en charge l'ancien réseau et transférera son infrastructure de dépôt et de retrait ZIL vers Zilliqa EVM.

Les détenteurs en auto-conservation ont une voie de migration ZIL distincte

Les clients des échanges ne sont pas les seuls détenteurs touchés par la mise hors service des anciennes adresses.

Zilliqa a développé un système de migration basé sur une preuve à divulgation nulle de connaissance pour les utilisateurs qui détiennent du ZIL dans leurs propres portefeuilles hérités. Le système est conçu pour permettre à un détenteur de prouver la propriété d'une ancienne adresse et de transférer le solde associé vers une adresse EVM sans fournir à Zilliqa une phrase de récupération ou une clé privée.

L'audit de l'outil de migration ZKP a été achevé, selon une mise à jour de septembre de Zilliqa, avec des tests internes suivant l'examen de sécurité. Son déploiement était prévu pour le 22 septembre, parallèlement à l'activation d'un contrat d'entiercement requis pour le processus de migration.

Le projet a mis en garde les utilisateurs contre toute tentative de déplacer des fonds via des clés héritées exposées. Une fois qu'un attaquant reconstruit une clé privée à partir d'anciennes signatures, le détenteur légitime et l'attaquant peuvent tous deux signer des transactions depuis le compte.

Les transactions héritées ont donc été désactivées pour tous les détenteurs, y compris les comptes qui n'ont jamais été exposés. Zilliqa a déclaré que le gel de l'ancien système de transactions empêchait les attaquants disposant de clés reconstruites de déplacer des fonds pendant que le processus de migration était en préparation.

Les soldes liés au ZIL déjà volés lors de l'incident sont traités séparément et ne sont pas automatiquement restaurés via les hard forks de migration des échanges.

Zilliqa a travaillé avec des échanges et les forces de l'ordre pour tracer les actifs volés. Son post-mortem indique qu'un compte d'échange utilisé pour liquider une partie des fonds volés a été identifié et gelé, tandis que le projet collaborait avec la police de Singapour et un cabinet d'avocats sur le processus de récupération.

L'équipe a séparément proposé un vote communautaire sur des modifications de la tokenomics de ZIL qui pourraient inclure la frappe de jetons pour indemniser les détenteurs affectés. Zilliqa a déclaré que les détails couvrant l'éligibilité, les montants et les mécanismes seraient publiés avec la proposition de gouvernance, car toute nouvelle émission modifierait l'offre de ZIL.

Zilliqa EVM devient l'environnement de production du réseau

La transition de Zilliqa vers une infrastructure EVM a commencé avant l'incident Ledger.

La blockchain est passée à Zilliqa 2.0 en juin 2025, apportant une compatibilité complète avec la machine virtuelle Ethereum ainsi qu'un système de consensus de preuve d'enjeu et des changements à l'architecture du réseau.

Sa période de test de six mois a impliqué 21 validateurs externes, le proto-mainnet traitant 7,5 millions de blocs et complétant 15 mises à niveau de clients avant la transition.

La prise en charge des transactions héritées s'est poursuivie après la mise en service de Zilliqa 2.0, laissant la blockchain avec à la fois l'ancienne infrastructure de transactions native et son environnement EVM.

Zilliqa a déclaré que l'incident Ledger a accéléré une décision qu'il envisageait déjà de retirer complètement l'ancienne infrastructure. Le projet a décrit la pile héritée comme une responsabilité croissante en matière de développement et de sécurité et a déclaré que Zilliqa EVM deviendrait son unique environnement de production.

L'incident de sécurité est survenu après plusieurs problèmes techniques antérieurs impliquant la blockchain, bien que Zilliqa n'ait pas lié ces pannes à la vulnérabilité Ledger. Une panne réseau de janvier 2025 a été attribuée à des problèmes impliquant des nœuds de recherche, tandis qu'un bug distinct en septembre 2024 avait arrêté la production de blocs.

Le post-mortem de Zilliqa indique que le correctif pour l'application Ledger a été soumis le 24 juillet et fusionné par un ingénieur de Ledger le 27 juillet. La version corrigée restaure la génération complète de nonce pour les nouvelles signatures, tandis que les clés privées déjà exposées par les signatures héritées antérieures doivent être retirées.