190億ドルの清算の夜、ライターはなぜ「閉鎖」したのか？

10月11日、暗号資産市場は史上最大のマージンコールを経験し、総額約190億ドルの清算が行われました。この過酷な市場環境下で、複数の分散型永久スワップ取引プラットフォーム（PerpDex）がシステム障害に見舞われ、中でもLighterが最も深刻な影響を受けました。流動性プロバイダープール（LLP）における損失は、PerpDexプラットフォームに関する市場での広範な議論を巻き起こしました。

Surf ProtocolやTifo.tradeなど、複数のPerp Dexプラットフォームを監査してきたWeb3セキュリティ企業として、Beosinは長年蓄積してきた技術とオンチェーンデータ分析の経験を活かし、この記事で紹介したLighterの障害の原因について、皆様がより深く理解できるようお手伝いします。

軽量化テクノロジーフレームワーク

Lighterは、PerpDexブームの中で、取引手数料ゼロという特徴で際立ち、多くのユーザーをプラットフォーム上で取引に惹きつけました。Lighterは、ZK Rollup L2に特化したzkLightを基盤としており、取引パフォーマンスと注文帳のマッチング効率を向上させています。そのコアとなる動作メカニズムは以下に示すとおりです。

ソーター:ユーザーインタラクションの最初のストップとして、トランザクション指示を受信し、トランザクションをソートし、それらをバッチ (トランザクションのバッチデータパケット) にパッケージ化する役割を担います。

マッチングエンジンはシーケンサーからバッチを受け取り、「価格優先、時間優先」のマッチングロジックを厳格に遵守します。マッチングが成功するたびに、ゼロ知識証明を生成するためのデータが準備されます。これにより、誰でもマッチングプロセスの公平性を検証でき、不正操作を防止できます。

証明者:マッチングエンジンの操作を簡潔な ZK-SNARK 証明に生成し、その後のマッチング実行と状態遷移の正確性を検証します。

メインネットコントラクト：証明者によって提出されたゼロ知識証明の検証を担当します。検証が完了すると、ステートルートが更新され、トランザクション結果が最終的にイーサリアム上で承認されます。

上記の機能に加えて、LighterはユーザーにVault機能を提供し、Lighter流動性プール（LLP）に資金を預け入れることができます。この流動性プールは、流動性プロバイダー、価格ジェネレーター、そしてリスク管理プラットフォームとして機能します。LLP参加者は、プラットフォームの利益とカウンターパーティの損失を共有するとともに、ユーザーのマージンコール発生時にリスクの一部を負担することで、Lighterの清算システムと連携したリスクバッファーメカニズムを形成します。

より軽いダウンタイムのレビュー

2025年10月11日、暗号資産市場では記録的な契約清算が発生しました。この極端な市場状況の中、Lighterは数時間にわたるサービス停止に見舞われ、ユーザーはポジション操作ができなくなり、LLPは約5.35%の損失を被りました。

Beosinは、このインシデントの主な発生時間帯（北京時間2025年10月11日00:17～05:08）のオンチェーンデータを分析し、Lighterがバッチ番号55661から3つのバッチを失い、00:17にバッチ生産を再開したことを発見しました（00:23にLighterはユーザーの注文を処理または実行できなかったというアナウンスを出しました）。

障害発生前、Lighterプラットフォームは通常、1分あたり約4,005件のトランザクションを処理していました。00:17以降、トランザクション量が急増しました。バッチ#55665には560個のブロックが含まれ、196,913件のトランザクションが処理されました。平均では1分あたり約65,638件のトランザクションが処理され、これは通常の約16倍に相当します。

以下は、10 月 11 日の 00:17 から 05:08 までの各バッチ送信時点で処理されたトランザクションの数の統計チャートです。

 Beosin Statisticsによる作成

10月11日午前4時56分、バッチ番号55743はトランザクション数が最大に達し、2分間で639,370件のトランザクションを完了しました。これは1分あたりの平均トランザクションレートの79.8倍に相当します。このインシデントに関するLighterのデータを分析した結果、Lighterのバッチは最大1,600個のブロックを処理でき、各ブロックは最大500件のトランザクションを処理できることがわかりました。バッチあたりの理論上の最大トランザクション数は800,000件ですが、実際に処理されたトランザクションの最大数は639,370件でした。

上記はLighterプラットフォームによって正常に処理されたトランザクションです。しかし、トランザクション送信の失敗（ダウンタイム）により、多くのユーザーがポジション調整に失敗し、チェーンにデータが記録されませんでした。技術アーキテクチャの観点から見ると、このダウンタイムとそれに伴うLLP損失は、主に以下の2つの理由によるものです。

1. フロントエンドページへのアクセスと注文送信に関する問題に加え、LighterのZK Rollupは、トランザクションのソートとパッケージングを単一のシーケンサーに依存しています。結果の検証にはZK Proofが使用されていますが、シーケンサーの集中化により単一障害点のリスクが生じます。価格下落時には、シーケンサーとデータベースが急激な負荷に対応できず、データベースのインデックス破損やトランザクションのブロックが発生し、マッチングエンジンとクライアント間の接続が直接的に切断されます。

2. 取引量が急増すると、証明生成ノードとデータベースの協調処理能力がZK-SNARK証明生成・提出プロセスにおけるボトルネックとなります。極端な市場状況では、取引マッチングと決済処理の同時急増により、ZK証明生成ノードへのリクエストが同時に開始されます。プラットフォームは、決済処理のような優先度の高い処理のためのリソース予約メカニズムを実装していない可能性があります。これにより、通常の取引と決済証明生成リクエストの間でリソース競合が発生し、システム応答の遅延がさらに悪化し、決済処理が迅速に実行されず、ユーザーの損失が拡大します。

運用面では、LighterのCEOであるVladimir Novakovski氏は、「Lighterは当初、最近の暴落の週末にデータベースをアップグレードし、取引需要の増加に対応する予定でした」と回答しました。このインシデントは、この「不適切なアップグレード時期」が、市場リスクに対するチームの準備不足に起因することを示唆しています。プラットフォームの急速な拡大において、彼らはインフラのアップグレードをタイムリーに完了することができず、最終的には極端な市場環境下でシステム障害に至りました。

このインシデントは、PerpDexが直面する核心的な課題、すなわち、極端な市場環境下でもプラットフォームの正常な運用を維持する方法を浮き彫りにしました。スマートコントラクトのセキュリティに関しては、PerpDexプロジェクトチームは包括的かつ専門的なコントラクトセキュリティ監査を実施する必要があります。Beosinはこれまで、Surf ProtocolやTifo.tradeといったPerpDexプロジェクトに対し、セキュリティ監査サービスを提供してきました。これらの監査は、スマートコントラクトコードのセキュリティ、ビジネス実装ロジック（レバレッジ取引、清算、流動性プール管理など）の正確性、コントラクトコードのガス最適化、潜在的な脆弱性の発見と修復を網羅しています。Beosinは、プロジェクトチームが複数の中リスクおよび高リスクの脆弱性を解決するのを支援してきました。