Starknet详解周一主网中断背后的故障原因

什么导致了Starknet主网的短暂中断？

Starknet开发团队发布了一份故障分析报告，解释了本周一发生的短暂主网中断的根源。报告指出，问题源于网络两个核心组件间的状态不一致：负责交易执行的区块处理器，与在最终确认前验证执行正确性的证明层。在一个涉及跨函数调用、状态写入及回滚的特定边缘案例中，区块处理器错误地保留了本应被丢弃的状态变更，导致某些本不应通过验证的交易在执行层被错误执行。

“在跨函数调用、变量写入、回滚及异常捕获的特定组合下，区块处理器记住了发生在已回滚函数内部的状态写入操作，从而引发了错误的交易执行。”开发团队在报告中解释道。关键的是，此问题从未触及以太坊最终确认阶段。Starknet的证明层检测到了状态不一致，阻止了错误交易被提交至账本，网络随之启动了区块重组，回退了约18分钟的活动记录。

投资者启示

本次事件未危及用户资金或以太坊最终性，但表明即使安全检查机制正常运行，执行层漏洞仍可能对第二层网络造成干扰。

漏洞为何未影响以太坊最终确认？

Starknet的架构将交易执行与证明验证分离。区块处理器处理交易时，证明层会在任何结果提交至以太坊前独立核验执行过程是否符合协议规则。此次事件中，证明层起到了安全网的作用：它标记出错误执行并阻止其最终化，转而强制启动重组机制。团队强调：“得益于证明层的设计，这次错误执行从未获得第一层最终确认。”代价是暂时的服务中断而非永久性损害。

网络回退了近期区块，受影响的用户需在链恢复有效状态后重新提交交易。Starknet表示网络现已恢复正常运行。团队承诺将扩大测试覆盖范围与审计强度，以降低类似问题重现的可能性，特别将重点关注执行逻辑与回滚机制间的边缘案例交互。

与既往中断事件相比有何异同？

周一的宕机并非Starknet在2025年首次面临可靠性挑战。最严重的事件发生在九月，当时网络刚完成名为Grinta的重大协议升级。那次中断持续超五小时，根源被追溯至排序器漏洞。排序器负责在交易被执行和证明前对其进行排序。在九月事件中，区块生产完全停滞，恢复过程需要两次链重组，回退约一小时网络活动。

受影响的用户被迫重新提交交易，这对部分用户而言尚属可处理的不便，但对操作时间敏感的交易者或应用程序则构成严重问题。相较之下，周一仅18分钟的回退时间更短、影响范围更有限，但其恢复模式与前者相似。

这对现代第二层网络设计有何启示？

这些事件共同揭示了先进第二层网络面临的广泛挑战。Starknet及类似系统依赖多层技术栈，包括执行引擎、证明系统、排序器以及与以太坊的跨层协调。每层设计都提升了安全性与扩展性，但也增加了潜在漏洞的暴露面。最新中断表明，当执行逻辑与回滚处理出现偏差时，即使高度孤立的边缘案例也可能触发链重组。虽然Starknet的安全机制如期生效，用户体验仍不可避免地涉及服务中断与交易回退。

对开发者和用户而言，应认识到第二层系统并非不安全，而是仍处于持续成熟阶段。零知识证明与定制执行引擎等功能虽能提供强大保障，但需要对难以穷举的组合场景进行广泛测试。

投资者启示

频繁的短暂中断或许不会威胁协议安全，但对基于第二层基础设施的交易者、去中心化金融用户及应用程序而言，运行时间与可预测性仍是关键指标。

Starknet后续将采取哪些措施？

Starknet表示已全面恢复系统功能，正在审查内部流程以加强对执行-回滚逻辑的测试。团队将此次事件视为其证明层按设计运行的佐证，同时承认需降低重组发生的概率。