出典: Beosin

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はユーザーに金庫機能を提供し、 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であるウラジミール・ノヴァコフスキー氏は、「Lighterは当初、最近の暴落の週末にデータベースをアップグレードし、取引需要の増加に対応する予定でした」と回答しました。このインシデントは、この「不適切なアップグレード時期」が、市場リスクに対するチームの準備不足に起因することを示唆しています。プラットフォームの急速な拡大において、彼らはインフラのアップグレードをタイムリーに完了することができず、最終的には極端な市場環境下でシステム障害に至りました。

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

https://www.beosin.com/audits/Surf%20Protocol%20V2_202403281200.pdf

さらに、Perp Dexプロジェクトチームは、アーキテクチャの冗長性と緊急対応メカニズムを考慮する必要があります。将来的には、マルチシーケンサーや動的リソーススケジューリングなどの技術を適用することで、Perp Dexは現在のボトルネックを解消し、より多くのユーザーにサービスを提供し、暗号金融の中核インフラとなることが期待されます。