Lighter宕机4小时全复盘：190亿爆仓夜，PerpDex缘何“熄火”？

原文来源：Beosin

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优化、潜在漏洞发现和修复等多个方面， 成功帮助项目团队修复多个中高风险漏洞。

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

此外，Perp Dex项目团队还需要将架构冗余和应急机制纳入考虑范围 。未来，随着多排序器、动态资源调度等技术的应用，Perp Dex有望解决当前的这一瓶颈，服务更多用户并成为加密金融的核心基础设施。