190亿爆仓夜,Lighter缘何“熄火”?

  • 事件概述:2025年10月11日,加密货币市场遭遇历史性爆仓,总清算金额约190亿美元。去中心化永续合约交易平台Lighter因严重宕机事故导致用户无法操作仓位,其流动性提供者资金池(LLP)亏损约5.35%,引发市场对PerpDex平台稳定性的广泛关注。

  • 技术框架分析

    • Lighter基于zkLight的ZK Rollup L2构建,核心组件包括排序器、撮合引擎、证明者及主网合约,通过零知识证明确保交易公平性与可验证性。
    • LLP机制结合流动性提供、报价生成与风险承接,但在极端行情下暴露出系统脆弱性。
  • 宕机原因

    • 技术瓶颈:单一排序器中心化架构无法承载突发负载(交易量激增至平常的79.8倍),导致数据库索引损坏与事务阻塞。
    • 资源竞争:ZK-SNARK证明生成节点未设置清算操作优先级,普通交易与清算请求资源竞争加剧延迟,清算流程未能及时执行。
    • 运营失误:团队未及时完成基础设施升级,对市场风险准备不足,升级窗口选择错误进一步放大故障。
  • 行业启示:PerpDex需加强智能合约安全审计与系统抗压能力,优化资源分配机制以应对极端行情。Beosin作为安全审计方,已为多家PerpDex平台提供漏洞修复与逻辑验证服务。

总结

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提供安全审计服务,涵盖智能合约代码的安全性、 业务实现逻辑(杠杆交易、清算、流动性池管理等)的正确性、合约代码gas优化、潜在漏洞发现和修复等多个方面,成功帮助项目团队修复多个中高风险漏洞。

分享至:

作者:Beosin

本文为PANews入驻专栏作者的观点,不代表PANews立场,不承担法律责任。

文章及观点也不构成投资意见

图片来源:Beosin如有侵权,请联系作者删除。

关注PANews官方账号,一起穿越牛熊
推荐阅读
22分钟前
2小时前
3小时前
3小时前
3小时前
4小时前

热门文章

行业要闻
市场热点
精选读物

精选专题

App内阅读