Starknet又宕机了：执行层与证明层打架，18分钟活动被回滚

以太坊L2网络Starknet在本周一发生主网宕机，根据1月11日发布的事后分析报告，这次事故源于执行层(blockifier)与证明层之间的状态不一致。在特定的跨函数调用与回滚组合场景下，执行层错误记录了已被回滚的状态写入，导致交易执行异常。虽然相关交易未获得L1最终性确认，但事件触发了区块重组，约18分钟的链上活动被回滚。更值得关注的是，这已经是Starknet在2025年以来第二次重大中断事件。

技术细节：执行层vs证明层的"不同步"

事故的根本原因

这次宕机的技术原因相对复杂。Starknet的架构涉及两个关键层级：执行层负责处理交易逻辑，证明层负责生成零知识证明并提交到以太坊主网。在这次事故中，当特定的函数调用和回滚操作组合出现时，执行层(blockifier)错误地记录了一个本应被回滚的状态写入，这导致了两个层级之间的状态冲突。

好消息是证明层正确地识别了这个错误，拒绝了这笔有问题的交易，未将其提交到账本。这个"自我纠正"机制防止了错误状态被永久化到以太坊主网。

为什么需要重组

由于执行层和证明层的不一致，网络被迫进行区块重组来恢复正常状态。这次重组导致约18分钟的网络活动被回滚，用户需要重新提交交易。对于非时间敏感的交易影响较小，但对于频繁交易者或需要快速执行的操作（比如紧急平仓）来说，可能造成实际损失。

历史对比：问题越来越频繁

虽然这次回滚时间更短（18分钟vs1小时），但频率问题开始显现。从9月到1月，Starknet在不到半年内经历了两次重大中断，且故障类型不同，反映出系统在不同层级都存在潜在风险。

团队的应对与承诺

立即行动

Starknet团队在发布事后分析报告的同时，做出了几项承诺：

• 加强代码测试流程，特别是针对边界条件和复杂场景的测试
• 强化代码审计机制，防止类似的状态不一致问题
• 根据相关资讯，Starknet计划推出v0.14.1版本，包含哈希函数升级和更快出块等优化

这些措施表明团队在主动改进系统稳定性，但能否有效防止未来的故障仍需时间验证。

对生态的影响评估

用户层面

这次事故的实际影响相对有限，因为：

• 回滚时间较短（18分钟），受影响的交易数量相对较少
• 交易未获L1最终性确认，所以没有资金真正丢失
• 用户主要需要重新提交交易，而不是面临资产损失

生态层面

但从更大的视角看，频繁的宕机事件对Starknet的生态发展构成挑战：

• 降低用户对网络稳定性的信心
• 可能影响DeFi应用的部署意愿
• 与其他L2项目（如Arbitrum、Optimism）的竞争中处于劣势

值得注意的是，根据相关资讯，Starknet正在积极拓展应用场景，比如与Noon合作推出比特币Vault、与AlchemyPay等项目合作。这些生态建设能否抵消稳定性问题带来的负面影响，是接下来需要观察的重点。

总结

Starknet的这次宕机事故反映了L2网络在复杂场景下的技术挑战。与其说这是一个严重的安全漏洞，不如说是系统在边界条件处理上的不足。证明层的"自我纠正"机制有效防止了资金损失，但频繁的中断问题不能忽视。

关键是看Starknet的改进措施是否真正有效。加强测试和审计是必要的，但能否从根本上解决这类问题，还要看后续版本的表现。对于生态参与者来说，在信任Starknet的同时，也需要关注其稳定性的改善进展。