190億爆倉夜,Lighter緣何「熄火」?

2025年10月11日,加密貨幣市場經歷了史上最大規模的爆倉事件,總清算金額高達約190億美元。在這次極端行情中,多個去中心化永續合約交易平台出現服務中斷,其中Lighter的宕機情況最為嚴重,導致其流動性提供者資金池(LLP)損失約5.35%。

Beosin透過技術與鏈上資料分析,指出Lighter宕機的主要原因包括:

  • 系統架構瓶頸:Lighter採用單一排序器處理交易排序與打包,雖然透過零知識證明確保交易驗證,但排序器的中心化設計在交易量激增時成為單點故障源,導致資料庫索引損壞與事務阻塞,前端服務中斷。

  • 證明產生延遲:在市場劇烈波動期間,交易量暴增至平常的16倍以上,ZK-SNARK證明產生節點與資料庫協同處理能力不足,未能為高優先級的清算操作預留資源,造成清算流程延遲,放大用戶損失。

  • 營運準備不足:Lighter團隊原計劃在事件發生當週進行資料庫升級,但未能及時完成基礎設施擴容,面對急速增長的交易需求,系統無法負荷。

此次事件突顯了去中心化永續合約交易平台在極端市場條件下面臨的運作挑戰,並呼籲相關項目應加強系統架構設計與進行全面安全審計,以提升系統韌性與用戶資產保障。

總結

10月11日,加密貨幣市場經歷了史上最大爆倉事件,總清算金額約190億美元。在這場極端市場考驗中,多個去中心化永續合約交易平台(Perp Dex)出現宕機,其中Lighter因宕機事故最為嚴重,流動性提供者資金池(LLP)出現虧損引起了市場對PerpDex平台的廣泛討論。

作為審計了Surf Protocol、Tifo.trade等多家Perp Dex的Web3安全公司,Beosin在本文將透過多年累積的技術與鏈上資料分析經驗,幫助大家深入了解本次Lighter宕機事件的原因。

Lighter技術框架

Lighter透過零交易手續費的特色在PerpDex的熱潮中脫穎而出,吸引了眾多用戶在其平台進行交易。 Lighter建構在zkLight這一特定的ZK Rollup L2之上,以提高交易表現和訂單簿的撮合效率。其核心運作機制如下圖所示:

排序器:作為使用者互動的第一站,負責接收交易指令,並將交易進行排序並打包成Batch(交易的批次資料包)。

撮合引擎:接收來自排序器的Batch,並嚴格遵循"價格優先、時間優先" 的撮合邏輯。每次成功的撮合都會為產生零知識證明準備好數據,確保任何人都能事後驗證撮合過程的公平性,避免了操縱的可能。

證明者(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各Batch提交時間點處理交易數的統計圖:

由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提供安全審計服務,涵蓋智慧合約程式碼的安全性、業務實現邏輯(槓桿交易、清算、流動性池管理等)的正確性、合約程式碼的安全性、業務實現邏輯(槓桿交易、清算、流動性池管理等)的正確性、合約程式碼優化漏洞。

分享至:

作者:Beosin

本文為PANews入駐專欄作者的觀點,不代表PANews立場,不承擔法律責任。

文章及觀點也不構成投資意見

圖片來源:Beosin如有侵權,請聯絡作者刪除。

關注PANews官方賬號,一起穿越牛熊
推薦閱讀
11分鐘前
2小時前
3小時前
3小時前
3小時前
3小時前

熱門文章

行業要聞
市場熱點
精選讀物

精選專題

App内阅读