PerpDexはなぜ「停止」したのか？ Lighterは4時間のダウンタイムを経て全復盤

10月11日、暗号資産市場は史上最大の清算事件を経験し、総清算額は約190億ドルに達しました。この極端な市場試練の中で、いくつかの分散化無期限先物取引プラットフォーム（Perp Dex）がダウンし、その中でもLighterのダウン事故が最も深刻で、流動性プロバイダー資金プール（LLP）の損失がPerpDexプラットフォームに対する市場の広範な議論を引き起こしました。

Surf Protocol、Tifo.tradeなどの複数のPerp Dexを監査してきたWeb3セキュリティ企業であるBeosinは、本記事で長年にわたる技術とオンチェーンデータ分析の経験を通じて、今回のLighterダウン事件の原因を深く理解する手助けをします。

より軽量な技術フレームワーク

Lighterは、PerpDexの熱潮の中で、ゼロ取引手数料の特徴によって目立ち、多くのユーザーをそのプラットフォームに引き寄せています。Lighterは、取引性能とオーダーブックのマッチング効率を向上させるために、特定のZK Rollup L2であるzkLightの上に構築されています。そのコア運用メカニズムは、以下の図に示されています：

!

ソート機：ユーザーインタラクションの最初のステップとして、取引指示を受け取り、取引をソートしてバッチ（取引のバッチ処理データパッケージ）にパッケージ化する役割を担います。

マッチングエンジン：ソーターからのバッチを受け取り、「価格優先、時間優先」のマッチングロジックに厳密に従います。毎回成功したマッチングは、ゼロ知識証明を生成するためのデータを準備し、誰でも後からマッチングプロセスの公平性を検証できるようにし、操作の可能性を避けます。

証明者（Prover）：マッチングエンジンの操作を簡潔なZK-SNARK証明に生成し、マッチングの実行と状態遷移の正しさを後続で検証するために使用します。

メインネット契約：証明者が提出するゼロ知識証明を検証する責任があります。検証が通過すると、状態ルートが更新され、これにより取引結果はイーサリアム上で最終的な確認の最終性を得ます。

上記の設計に加えて、Lighterはユーザーに金庫機能を提供しており、ユーザーは資金をLighter Liquidity Pool（LLP）に預けることができます。この流動性プールは、流動性提供、価格生成、リスク承受の三重の機能を担っています。LLPの参加者は、プラットフォームの収益と対手方の損失から生じる収益を共有でき、同時にユーザーの清算時に一部のリスクを引き受け、Lighterの清算体系と連携してリスクバッファー機構を形成します。

Lighterダウンタイム復盤

2025年10月11日、暗号資産市場の先物清算規模が歴史的な記録を樹立しました。この極端な市場環境の中で、Lighterは数時間のサービス中断が発生し、ユーザーがポジションを操作できなくなり、LLPは約5.35%の損失を被りました。

Beosinは、今回の事件の主要な時間帯（北京時間2025年10月11日00:17-05:08）のオンチェーンデータ分析を通じて、LighterがBatch＃55661から3つのBatchを失っており、00:17からBatchの生産を再開したことを発見しました（00:23にLighterがユーザーの注文は処理または実行できないと発表）。

Lighterプラットフォームはダウンする前に正常に処理していた取引量は約4005件/分で、00:17から取引量が急増し、Batch#55665には560のブロックが含まれ、処理された取引量は196913件で、平均して毎分約65638件の取引を処理する必要があり、通常の時期の約16倍です。

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

!

Beosinによって統計されたもの

10月11日04:56に、Batch#55743の処理取引数が最大値に達し、2分間で639370件の取引が完了しました。これは通常の時間帯の毎分処理取引数の79.8倍です。Lighterの今回の事件のデータを統計すると、LighterのBatchは最大で1600のブロックを収容でき、そのブロックは最大で500件の取引を収容できるため、理論上の処理取引数は800000/Batchですが、実測では最高639370件でした。

以上はLighterプラットフォームが成功裏に処理した取引であり、まだ多くのユーザーが取引の提出に失敗し、ポジションを調整できず（ダウンタイム）により、チェーン上に記録されていないデータがあります。技術アーキテクチャの観点から見ると、今回のダウンタイムとLLPの損失を引き起こした主な理由は2つあります：

1. フロントエンドページへのアクセスと注文提出に問題が発生したことを除いて、LighterのZK Rollupは単一のソートエンジンに依存して取引のソートとパッケージングを行っています。ZK Proofを通じて結果検証を実現していますが、ソートエンジンの中央集権化は単一障害点のリスクを引き起こします。暴落の期間中、ソートエンジンとデータベースは突発的な負荷を処理できず、データベースはインデックスの破損やトランザクションのブロックが発生する可能性があり、これが直接的にマッチングエンジンとユーザー側の接続中断を引き起こします。2. ZK-SNARKの証明生成と提出プロセスは取引量が急増した際に、証明生成ノードとデータベースの協調処理能力がボトルネックとなります。極端な状況下で、同期して増加する取引のマッチングと清算操作が同時にZK証明生成ノードにリクエストを送ります。プラットフォームは清算のような高優先度の操作に対してリソースの予約メカニズムを設定していない可能性があり、通常の取引と清算の証明生成リクエストがリソース競争を引き起こし、システムの応答遅延を悪化させ、清算プロセスがタイムリーに実行できず、ユーザーの損失を拡大させます。運用面では、LighterのCEOであるVladimir Novakovskiが「Lighterは本来、今回の暴落が発生した週末にデータベースのアップグレードを行う計画でした。これは継続的に増加する取引需要に適応するためです。」と述べています。この事件から見ると、「アップグレードウィンドウの選択ミス」は、チームが市場リスクに対する準備が不十分であったために発生し、プラットフォームの急速な拡張の過程で、タイムリーなインフラのアップグレードを完了できず、最終的に極端な状況下でプラットフォームのシステム的な故障を引き起こしました。この事件は、PerpDexが直面している核心的な課題を明らかにしました：極端な状況下でプラットフォームの正常な運用をどのように維持するかです。スマートコントラクトの安全性に関して、Perp Dexのプロジェクトチームは包括的かつ専門的な契約の安全監査を実施する必要があります。Beosinは以前にSurf Protocol、Tifo.tradeなどのPerp Dexに安全監査サービスを提供しており、スマートコントラクトコードの安全性、ビジネス実現ロジック（レバレッジ取引、清算、流動性プール管理など）の正確性、契約コードのgas最適化、潜在的な脆弱性の発見と修正など、多くの側面をカバーしており、プロジェクトチームが中高リスクの脆弱性を修正するのを成功裏に支援しました。

さらに、Perp Dexプロジェクトチームは、アーキテクチャの冗長性と緊急対策を考慮に入れる必要があります。将来的には、多重オーダー処理や動的リソーススケジューリングなどの技術の導入により、Perp Dexは現在のこのボトルネックを解決し、より多くのユーザーにサービスを提供し、暗号金融のコアインフラストラクチャとなることが期待されています。