近日 Sui 公链也面临了暂时停止出块的窘境，在经历两个半小时的停止出块后，Sui 官方也发布了针对此事件的报告。不过主打高性能公链的 Sui 历经停止出块，也让人联想到先前几年的 Solana。比较两者，尽管在程式语言丶架构上都大大不同，但同样主打高性能公链，却也被诟病不够去中心化等。
Table of Contents
Toggle为何一段拥堵控制代码引发了所有验证者的崩溃
报告中指出 2024 年 11 月 21 日凌晨，Sui 主网在太平洋时间约凌晨 1:15 至 3:45 经历了一次全面停摆。所有验证者进入崩溃循环，导致整个网路无法处理任何交易。此次事件突显了高性能公链在提升性能同时，稳定性仍需高度关注。
而根据官方声明，此次停摆的原因在于 Sui 网路的拥堵控制 (congestion control) 代码中的一段「assert!」触发了验证者的崩溃。具体而言，当以下条件同时满足时，会导致网络崩溃：
- 拥堵控制启用 TotalGasBudgetWithCap 模式。
- 接收到包含以下特征的交易：一个可变共享物件作为输入丶没有任何 MoveCall 指令
当这样的交易进入网络，所有验证者同时崩溃，网络陷入停摆。
拥堵控制是什么？
Sui 主网的物件导向架构允许大量交易并行处理，这是其实现高性能的方式。然而若多笔交易需写入同一共享物件，仍需依序执行，且此类交易的处理速度受到限制。为避免共享物件造成的拥堵，Sui 引入拥堵控制机制以限制单个共享物件的交易速率。笔者补充：先前 Sui Foundation 在与 XueDAO 合作的线下读书会中，提及其逻辑是将有因果关系的交易打包一同执行。
而近期 Sui 升级了拥堵控制系统，引入 TotalGasBudgetWithCap 模式以更精准地评估交易复杂度。不过，此模式的代码中出现了导致本次事件的漏洞。Sui 团队表示这次发现问题后即迅速采取行动，通过代码修复(PR #20365)推出了主网 v1.37.4 和测试网 v1.38.1 版本更新。验证者社群展现了极高的响应效率，从修复发布到网络恢复仅用了 15 分钟。
Typus 协议：Sui 的停止出块与 Solana 完全不同
Sui 的停止出块不免让人联想到 Solana 甚至今年的 TON，对此 Sui 上的 DeFi 协议 Typus 的 CGO Kyrie 也在推特上分享团队成员对此的看法，他直接地指出这与 Solana 的停止出块是完全不同的事。因为 Solana 的问题是网路拥塞导致系统崩溃，要解决需要大规模架构改善，而这也表示 Solana 的问题短期内难以根本解决。而 Sui 这次是明确的技术问题，不影响系统基础架构。
Kyrie 表示这次当机问题出在计算交易成本时的数值溢位 (overflow)。简单来说，就像计算机显示位数不够，数字太大时会归零重新计算。系统在这种情况下陷入无限循环，最终导致整个网路停摆。
当系统计算的数值超过可以储存的范围时，原本的设计是超过范围时会计算错误，导致系统一直重复运算。而 PR #20365 修正后设定了正确的计算上限，避免这种状况发生。他也指出这次事件的关键在于：问题发生在交易成本计算的程式逻辑上，而不是 Sui 的共识机制或系统架构设计。这也解释了为什么修复能这么快速且直接。
Franklin Templeton 与 Sui 宣布合作关系
在截稿前传来一个消息，在停止出块的隔天，Sui Foundation 宣布了与 Franklin Templeton 的合作关系。在声明中 Franklin Templeton 点名了 Deepbook丶Karrier One 及 ika 这三个协议及基础设施。不过根据 Franklin Templeton 在区块链的操作，或许可以期待 Sui 这个物件导向，最注重安全性的公链与 RWA 的结合。
