Scroll 这次事件，从一开始就是一场围绕以太坊主网合约的时间赛跑。作为部署在以太坊上的 Layer 2 网络，Scroll 的批次证明验证合约直接负责把 L2 的状态根和提款根“写进”主网安全边界。2025 年 11 月 3 日，团队通过漏洞赏金计划收到报告：这份报告指出，现有设计下，旧的“有效证明”可以被拿来给新的公共或公开输入做背书，在理论上打开了最终确认任意状态根和提款根的大门，用户资产安全被摆上了风险天平。Scroll 随后选择在治理论坛公开披露漏洞和处理方案，而不是完全内部消化，并同步启动面向以太坊主网的紧急升级流程，把时间窗口压缩在七天之内。到 11 月 10 日，Scroll 完成主网升级，为 Batch version 10 注册修复后的证明验证合约，阻断旧证明复用的路径；官方在对相关合约与状态核查后给出的结论是：在修复前未发现该漏洞在主网上被实际利用。这场潜在可以撼动状态根和提款根的风险，最终停留在“理论上可能”的层面，却也把 Layer 2 依赖的核心合约有多脆弱、以及项目方在压力下能否快速透明响应，鲜明地摆到了整个生态面前。

证明合约漏洞直指状态根

要理解这次事件的分量，必须回到 Scroll 的证明验证合约本身。作为一个以太坊 Layer 2 网络，Scroll 会把大量 L2 交易打包成批次，通过零知识证明等形式把“这一批次是合法的”这一事实提交给以太坊主网。部署在主网上的证明验证合约，就是整个过程的裁判：它接收证明和对应的公共输入，决定某个 L2 批次是否被视为有效，一旦验证通过，就为后续在主网上记录这一批次的 L2 状态根和提款根打开闸门。换句话说，这个合约是 Scroll 从二层世界回到一层结算时的关键关卡，负责把 L2 的最终状态和可提款余额，固化成以太坊主网认可的结果。

本次披露的漏洞，恰恰发生在这个关卡的“输入与证明绑定”环节。按设计，某个批次对应的证明只能用于那一组特定公共输入，一旦批次内容或状态变更，就必须重新生成新的证明。而漏洞的核心风险在于：旧的有效证明可以被用于新的公共或公开输入，这种解绑意味着，只要找到合约允许的组合方式，历史上曾被主网认可的某份证明，就有可能在理论上被伪装成“万能通行证”，为一组本不该通过的状态根和提款根盖章。Scroll 官方也据此指出，该漏洞在理论上可能被用于最终确认任意状态根和提款根，直接触及 L2 资产安全的根部——一旦被恶意利用，用户在二层看到的余额与主网记录的余额可能不再一致，提款根的可信度也会被动摇。虽然经核查这一风险没有在以太坊主网上被实际触发，但它暴露出的，是证明验证合约一旦失守，状态根和提款根这两道安全锚点就有被改写的可能。

Scroll 从赏金到治理公开危机

真正让这场危机浮出水面的是一条看似常规的赏金提交。2025 年 11 月 3 日，Scroll 通过其漏洞赏金计划收到了关于部署在以太坊主网的证明验证合约存在安全缺陷的报告，报告抓住的关键点，是旧的有效证明竟然可以被“迁移”到新的公共输入之上。这类赏金计划本意在于鼓励白帽在问题被恶意发现之前先一步发现它，而这一次，Scroll 的核心安全组件正是沿着这一负责任披露路径被推到聚光灯下。公开材料没有披露提交者身份和赏金金额，唯一被反复强调的，是这是一个理论上可以影响状态根和提款根的高风险技术漏洞。

更值得注意的是 Scroll 的后续选择：团队没有把整个事件锁在内部工单系统里，而是很快在治理论坛公开了漏洞的存在、潜在风险及处理方案，同时明确指出据当前排查，这一缺陷尚未在以太坊主网上被实际利用。从赏金渠道接收入站报告，再到在治理层面正面承认问题，Scroll 把一次可以悄然修补的技术危机，刻意变成一次面向社区的透明事件，以此让所有依赖这条 L2 的用户和开发者都能在同一信息面板上理解风险、观察应对。这种从赏金到治理公开的流程，既把负责任披露的原则贯彻到底，也在链上安全文化上释放出一个信号：当证明验证合约这类底层组件暴露出结构性隐患时，真正能维护信任的不是粉饰太平，而是让修复路径、时间线和风险边界对社区保持可见。

七日内升级替换 Batch v10 验证器

从 11 月 3 日收到漏洞赏金报告，到 11 月 10 日在以太坊主网完成批次证明验证合约的紧急升级，Scroll 把这场与时间的赛跑压缩在约七天内。治理论坛的公开披露之后，技术团队在主网上为 Batch version 10 注册了修复后的证明验证合约或验证器，核心目标很明确：在不打乱既有网络运行节奏的前提下，尽快让新的验证逻辑“接管”后续批次的最终确认路径。

这一步的具体意义在于，把漏洞描述中的理论风险切断在链上执行层面——新的验证器应当阻断旧证明在新公共或公开输入下被复用的可能，从而保护后续状态根和提款根的最终确认不被“挟持”。Scroll 一方面在事件处理中强调，经检查并未发现该漏洞在主网上被实际利用，另一方面又选择七日内完成版本替换而不是拖延到常规升级周期，这本身就是风险控制与连续运行之间的权衡：不贸然停摆整条 L2，但又通过快速更换 Batch v10 验证器，把可疑路径封死在未来块高之前。在公开材料仍未完整解释许可制证明者角色或“7 天未最终确认”等细节的情况下，这次选择用可验证的主网升级动作来回应不确定性，最终把潜在的系统性威胁压缩为一次可控的合约版本切换。

L2 安全闹钟：证明验证有多脆弱

把视角拉回更大的版图，Scroll 这次暴露出的并不是某个用户合约的 bug，而是部署在以太坊主网、为整条 Layer 2 网络批次“盖章”的证明验证合约本身出了问题。对于包括 Scroll 在内的所有以太坊 Layer 2 来说，这类合约负责最终确认 L2 状态根和提款根，它更像是安全闹钟而不是普通业务模块：一旦验证逻辑被绕过，风险不再局限于单一交易，而是可能在体系层面改写“链上真实发生了什么”。Scroll 官方的表述也非常直接——旧的有效证明在理论上可以被用于新的公共或公开输入，理论上可能被用于最终确认任意状态根和提款根，这等于在主网合约层打开了一条本不该存在的后门。

但“理论上可能”并不等同于“已经有人走了这条后门”。据 Scroll 的核查结论，这次漏洞在以太坊主网上没有被实际利用，也没有出现已经确认到主网的异常状态根或提款根，这一点需要与风险描述区分开来。真正值得在意的是，它把整个生态长期以来对证明验证合约的脆弱面暴露出来：我们习惯于把主网上的这层逻辑视作理所当然的安全基石，直到有人通过漏洞赏金计划指出，在形式化证明之外，代码仍可能允许旧证明与新输入的错配。公开材料曾片段提到许可制证明者角色、以及“7 天未最终确认”等可能相关条件，但这些技术细节目前并不完整，也不足以还原一条确定的攻击路径。在信息仍不充分的阶段，更审慎的做法，是承认这类合约的系统性重要性与潜在脆弱性，同时明确区分理论风险和已发生事实，让对 L2 安全的警惕建立在可验证的主网状态与公开修复动作之上。

这次被化解的危机为 L2 敲响警钟

回看整条时间线，Scroll 在收到 11 月 3 日的漏洞赏金报告后，用大约七天完成了从漏洞核查，到治理论坛披露细节，再到 11 月 10 日主网紧急升级并为 Batch version 10 注册修复后的证明验证合约或验证器的闭环处理，在官方确认漏洞未被实际利用的前提下，提前终结了一次理论上可能波及状态根和提款根的主网级安全事故。漏洞赏金让问题得以及早暴露，治理公开把风险评估和行动方案置于社区视野之下，而紧急升级则在关键的证明验证合约这一“最后防线”落下技术闸门，三者协同，构成了负责任披露与快速响应的正面示范。危机虽然已被化解，却为整个以太坊 Layer 2 的证明验证合约敲响了长久的警钟：后续值得关注的是，其他 L2 是否会据此强化这类合约的审计深度，设计更有激励和约束力的漏洞赏金机制，并在公开治理和应急预案中留下足够可验证的记录，让所谓“最后防线”真正能够在主网上经受住下一次突发风险的检验。

加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。