拥有相当程度知名度的公链Sui，在北京时间14 号深夜传出网络停滞状况。官方指出，主网目前一度无法正常处理交易，部分去中心化应用（dApp）与区块浏览器服务，包括Slush、SuiScan 等，可能出现暂时无法连线或交易延迟的情形。 Sui Core 团队已即刻介入处理，并承诺将在问题厘清后对外公布进一步进展。
Sui 出现网络停滞状况
北京时间14 号深夜，Sui 主网出现网络停滞（network stall）状况，官方指出，主网目前一度无法正常处理交易，部分去中心化应用（dApp）与区块浏览器服务，包括Slush、SuiScan 等，可能出现暂时无法连线或交易延迟的情形。 Sui Core 团队已即刻介入处理，并承诺将在问题厘清后对外公布进一步进展。
值得注意的是，这并非Sui 首次发生主网全面停摆。回顾2024 年11 月21 日，Sui 主网曾在太平洋时间凌晨约1:15 至3:45 间完全停止运作，当时所有验证者节点同时进入崩溃循环，导致整个网络无法处理任何交易。相关事件也引发市场对「高效能公链在追求吞吐量的同时，是否牺牲系统稳定性」的讨论。
回顾上次当机主因：拥堵控制程式码触发验证者崩溃
根据官方技术说明，2024 年11 月的停摆事件，源自Sui 拥堵控制（congestion control）模组中的一段assert! 检查逻辑。当特定条件同时成立时，会直接导致所有验证者节点崩溃，进而使整个网络陷入停滞。
触发条件包括：
- 拥堵控制机制启用TotalGasBudgetWithCap 模式
- 网络接收到一笔交易，具备「可变共享物件作为输入」
- 该交易未包含任何MoveCall 指令
- 在上述条件叠加下，验证者会于成本计算流程中发生异常，导致同步崩溃。
什么是拥堵控制？ Sui 高效能设计的必要配套
Sui 采用物件导向（object-centric）的帐本模型，允许大量交易并行执行，这也是其高吞吐量的重要基础。然而，若多笔交易同时尝试写入同一共享物件，仍必须依序处理，容易形成效能瓶颈。
因此，Sui 引入拥堵控制机制，限制单一共享物件在单位时间内可被处理的交易数量，以避免系统被少数高频共享物件拖慢。先前Sui Foundation 亦曾在与XueDAO 合作的线下读书会中说明，其核心逻辑是将具有因果关系的交易进行分组与批次执行。
近期Sui 对该机制进行升级，新增TotalGasBudgetWithCap 模式，用于更精准地评估交易计算成本与复杂度。不过，该模式中的程式逻辑漏洞，正是导致当次主网停摆的关键。
Sui 团队在确认问题后迅速提交修补程式（PR #20365），并推出主网v1.37.4 与测试网v1.38.1 更新版本。官方指出，在修复版本释出后，验证者社群高度配合升级，从修补发布到网络全面恢复，仅花费约15 分钟，展现相当高的协作效率。
本文链接地址：https://www.wwsww.cn/hqfx/36500.html
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
