主网暂停修复原子性漏洞：MultiversX 面临回滚两难

据 Woofun AI 消息， 主网运行已全面暂停，直接诱因是虚拟机层遭受针对原子性缺陷的漏洞攻击，导致区块链状态出现异常。此次事件的核心矛盾在于，如何在保留已确认合法交易的前提下，精准修复被篡改的账户余额与智能合约数据，而非简单粗暴地回滚整个网络。攻击者利用软件漏洞试图改变记录着 token 持有情况与合约数据的底层状态，迫使开发团队在追踪状态变化并准备补丁期间，紧急停止区块生成以防止错误扩散。目前尚未公布具体的损失金额，但暂停操作旨在阻止基于错误记录的后续交易，并为工程师争取时间以确定受影响的余额或合约条目范围。

值得注意的是，此次暂停并未撤销网络已接受的变更，这些记录仍作为钱包、应用程序及跨链桥在制定恢复方案前的起始依据，凸显了修复工作的复杂性与紧迫性。

从技术原理层面解构，此次危机的根源在于交易原子性的执行失效。在理想的智能合约执行环境中，一个包含多个关联操作（如账户余额增减、流动性池更新）的交易，必须确保所有步骤按序完成且全部成功，变更才会成为永久性结果；若任一步骤失败，所有变更均不应被确认。

然而，MultiversX 面临的原子性缺陷意味着，即便某项操作失败，此前的状态变更依然有效，导致网络记录下本不应存在的部分结果。这种状态异常可能表现为账户余额、token 供应量或合约记录与预期不符，但 MultiversX 尚未透露具体数据类型，因此无法确定攻击者是创造了新 token、抽走特定合约资金，还是窃取了特定数额资产。更深层的困境在于共识机制与软件漏洞的错位：区块链的最终确认性仅意味着验证者就区块及其状态达成一致，但这并不能证明计算这些状态的软件无缺陷。当所有节点执行相同的存在漏洞的协议规则时，验证者会一致认同某种本不应被允许的结果。安装修正后的软件虽能防止错误路径再次触发，却无法自动解决已记录变更的处理问题，必须通过可重复的操作方式，让验证者确认无关活动未受变动，这构成了修复的技术壁垒。

截至 9 月 20 日，MultiversX 的状态页面显示系统处于部分降级状态，公共 API、、浏览器界面、钱包应用、跨链桥、 以及 等功能表现均有所下降，而网关和索引功能仍正常运行。

Woofun AI 整理数据显示，这些服务标签仅描述独立服务状态，并不代表正常交易处理功能已恢复，即便接口恢复也无法解决根本账务问题。为应对这一局面，团队已在隔离环境中准备好用于测试的补丁，该环境复制了主网历史数据与状态，使工程师能在不影响真实账户余额的情况下重现网络状况。测试流程包括应用补丁、重新模拟受影响操作流程、测试拟定恢复方案，最后由验证者在主网部署。

这一流程旨在确保协同配合，因为部署工作仍需验证者、交易所、跨链桥及基础设施提供商共同参与。即便通过测试，并非所有服务都会自动恢复，因为修复方案需在不撤销合法交易的前提下，仅处理与事件相关的变更，保留已完成最终确认的交易记录及合法用户账户信息。

目前，MultiversX 尚未说明具体实施方法，仅强调只有受影响账户余额、合约存储数据或其他相关记录会被修复，无关交易仍保留在已完成交易记录中，这要求极高的精准度与透明度。

修复方案的难点在于平衡针对性恢复与大规模回滚的风险， 网络的案例提供了重要参照。在 漏洞攻击后，Cronos 验证者删除了近 2 小时内的约 11,000 个区块，这一大规模回滚虽纠正了大部分借贷记录，但也撤销了同期无关交易，展示了回滚共享账本的附带成本。MultiversX 正考虑采用范围更小的修复方案，旨在避免删除原有区块，保持交易历史可见，仅通过协调统一的协议更改，确定系统重启后应用程序和验证者认可的状态。