Pourquoi PerpDex est-il "éteint" ? Revue complète de la panne de 4 heures de Lighter.

Le 11 octobre, le marché des cryptoactifs a connu le plus grand événement de liquidation de l'histoire, avec un montant total de liquidation d'environ 19 milliards de dollars. Lors de cette épreuve extrême du marché, plusieurs plateformes de Trading Futures Perpétuel décentralisées (Perp Dex) ont rencontré des pannes, dont Lighter, qui a subi la plus grave, entraînant des pertes dans le fonds des Fournisseurs de liquidité (LLP) et suscitant de larges discussions sur la plateforme PerpDex.

En tant qu'entreprise de sécurité Web3 ayant audité plusieurs Dex Perp tels que Surf Protocol et Tifo.trade, Beosin, dans cet article, utilisera ses années d'expérience en analyse technique et de données on-chain pour aider à mieux comprendre les raisons de l'incident de panne de Lighter.

Cadre technologique Lighter

Lighter se distingue dans la frénésie de PerpDex grâce à ses caractéristiques de zéro frais de transaction, attirant de nombreux utilisateurs à trader sur sa plateforme. Lighter est construit sur zkLight, un L2 spécifique basé sur ZK Rollup, afin d'améliorer la performance des transactions et l'efficacité de l'appariement du carnet de commandes. Son mécanisme de fonctionnement central est illustré ci-dessous :

Ordonnanceur : en tant que première étape d'interaction utilisateur, il est responsable de la réception des ordres de trading et de l'organisation et de l'emballage des transactions en Batch (package de données de traitement par lot des transactions).

Moteur de correspondance : reçoit des lots du tri, et suit strictement la logique de correspondance “priorité au prix, priorité au temps”. Chaque correspondance réussie prépare des données pour générer une preuve à zéro connaissance, garantissant que quiconque peut vérifier a posteriori l'équité du processus de correspondance, évitant ainsi la possibilité de manipulation.

Prover : Générer l'opération du moteur de mise en relation en une preuve ZK-SNARK concise, utilisée pour valider ultérieurement la justesse de l'exécution de la mise en relation et des transitions d'état.

Contrat de la chaîne principale : responsable de la vérification des preuves à divulgation nulle soumises par les validateurs. Une fois la vérification réussie, l'état racine sera mis à jour, et ainsi le résultat de la transaction obtiendra une confirmation finale sur Ethereum.

En plus de la conception ci-dessus, Lighter offre aux utilisateurs une fonction de coffre-fort, permettant aux utilisateurs de déposer des fonds dans le Lighter Liquidity Pool (LLP). Ce pool de liquidité remplit trois fonctions : Fournisseur de liquidité, génération de prix et prise en charge des risques. Les participants au LLP peuvent partager les bénéfices de la plateforme ainsi que les bénéfices générés par les pertes des contreparties, tout en prenant une partie des risques en cas d'Être liquidé de l'utilisateur, en collaboration avec le système de liquidation de Lighter, formant ainsi un mécanisme de tampon contre les risques.

Revue de l'incident de Lighter

Le 11 octobre 2025, la taille des liquidations de contrats sur le marché des cryptoactifs a atteint un niveau record. Lors de cette situation extrême, Lighter a connu plusieurs heures d'interruption de service, empêchant les utilisateurs d'opérer sur leurs positions, et les Fournisseurs de liquidité ont perdu environ 5,35 %.

Beosin a découvert, grâce à l'analyse des données on-chain pendant la période principale de cet événement (heure de Pékin, du 11 octobre 2025 à 00:17 à 05:08), que Lighter avait perdu 3 Batchs depuis le Batch #55661, et a commencé à récupérer la production de Batch à 00:17 (à 00:23, Lighter a publié un communiqué indiquant que les commandes des utilisateurs ne pouvaient pas être traitées ou exécutées).

La plateforme Lighter traitait normalement un volume de transactions d'environ 4005 transactions/minute avant la panne. À partir de 00:17, le volume des transactions a explosé, le Batch#55665 contenant 560 blocs, avec un volume de transactions traité de 196913, nécessitant en moyenne de traiter environ 65638 transactions par minute, ce qui est environ 16 fois le volume habituel.

Voici le graphique des statistiques du nombre de transactions traitées pour chaque point de soumission Batch entre 00h17 et 05h08 le 11 octobre.

Réalisé par Beosin

Le 11 octobre à 04:56, le Batch#55743 a atteint le nombre maximum de transactions traitées, avec 639370 transactions complétées en 2 minutes, soit 79,8 fois le nombre de transactions traitées par minute en période normale. En analysant les données de l'événement Lighter, nous avons découvert que le Batch de Lighter peut contenir jusqu'à 1600 blocs, chaque bloc pouvant contenir jusqu'à 500 transactions, ce qui donne une capacité théorique de traitement de 800000 transactions par Batch, tandis que le maximum mesuré était de 639370.

Les transactions ci-dessus ont été traitées avec succès par la plateforme Lighter, et de nombreux utilisateurs n'ont pas pu enregistrer de données sur la chaîne en raison de l'échec de la soumission des transactions et de l'incapacité à ajuster leurs positions (panne). D'un point de vue technique, cette panne et les pertes de LLP ont principalement deux raisons :

1. En dehors des problèmes d'accès aux pages frontales et de soumission de commandes, le ZK Rollup de Lighter dépend d'un seul ordonnanceur pour le tri et l'emballage des transactions. Bien que la validation des résultats soit réalisée par le biais de ZK Proof, la centralisation de l'ordonnanceur entraîne un risque de point de défaillance unique. Pendant les périodes de forte chute, l'ordonnanceur et la base de données ne peuvent pas supporter une charge soudaine, et la base de données peut subir des dommages d'index et des blocages de transactions, ce qui entraîne directement une interruption de la connexion entre le moteur d'appariement et l'interface utilisateur. 2. La génération de preuves ZK-SNARK et le processus de soumission deviennent un goulot d'étranglement lorsque le volume des transactions augmente rapidement. Dans des conditions extrêmes, les opérations d'appariement et de liquidation des transactions qui explosent simultanément envoient des demandes au nœud de génération de preuves ZK. La plateforme n'a peut-être pas mis en place de mécanisme de réservation de ressources pour des opérations de haute priorité comme la liquidation, ce qui entraîne une concurrence pour les ressources entre les demandes de génération de preuves pour les transactions ordinaires et celles de liquidation, aggravant ainsi le délai de réponse du système et empêchant l'exécution rapide du processus de liquidation, amplifiant les pertes des utilisateurs. Au niveau opérationnel, selon la réponse du PDG de Lighter, Vladimir Novakovski, “Lighter prévoyait initialement de procéder à une mise à jour de la base de données durant le week-end de la chute afin de s'adapter à la demande croissante de transactions”. Cet événement montre que ce “choix d'erreur de fenêtre de mise à niveau” est dû à une préparation insuffisante de son équipe face aux risques du marché, et que dans le cadre de l'expansion rapide de la plateforme, elle n'a pas pu réaliser une mise à niveau d'infrastructure en temps voulu, entraînant finalement une défaillance systémique de la plateforme dans des conditions extrêmes. Cet événement met en lumière un défi central auquel PerpDex est confronté : comment maintenir le fonctionnement normal de la plateforme dans des conditions extrêmes. En ce qui concerne la sécurité des contrats intelligents, les équipes de projets dans le domaine de Perp Dex devraient procéder à un audit complet et professionnel de la sécurité des contrats. Beosin a précédemment fourni des services d'audit de sécurité à Surf Protocol, Tifo.trade et d'autres Perp Dex, couvrant plusieurs aspects tels que la sécurité du code des contrats intelligents, la justesse de la logique d'implémentation des affaires (trading à effet de levier, liquidation, gestion des pools de liquidité, etc.), l'optimisation des gas du code des contrats, la découverte et la réparation de vulnérabilités potentielles, aidant avec succès les équipes de projets à corriger plusieurs vulnérabilités de risque moyen à élevé.

De plus, l'équipe du projet Perp Dex doit également prendre en compte la redondance de l'architecture et les mécanismes d'urgence. À l'avenir, avec l'application de technologies telles que les multiples ordonnancers et la planification dynamique des ressources, Perp Dex devrait être en mesure de résoudre le goulot d'étranglement actuel, de servir davantage d'utilisateurs et de devenir une infrastructure fondamentale du chiffrement financier.