Sui公链首次停摆复盘：拥堵代码致验证者崩溃，次日官宣Franklin Templeton合作

高性能公链Sui，在最近经历了一次罕见的网络中断。整整两个半小时的停摆，让市场捏了一把汗。事后，Sui官方迅速发布了事故复盘报告。虽然Sui在代码架构上与Solana截然不同，但这次事件还是不可避免地引发了关于其去中心化程度与稳定性的讨论。有意思的是，就在停摆的第二天，Sui Foundation便宣布与华尔街资管巨头Franklin Templeton达成合作，在机构级应用拓展上又迈出了一大步。

拥堵控制代码引发验证者崩溃循环

根据官方披露的报告，时间线很清晰：2026年11月21日凌晨（太平洋时间1:15至3:45），Sui主网全面停摆。简单说，就是所有的验证节点集体“罢工”，陷入了一个崩溃重启的循环里，网络完全无法处理任何交易。这再次提醒我们，对于追求极致TPS的高性能公链来说，系统稳定性始终是悬在头顶的核心挑战。

官方指出，事故的根源在拥堵控制（Congestion Control）模块中的一段代码逻辑异常。具体来说，当网络同时满足两个条件时，就会触发这场“完美风暴”：

• 拥堵控制机制启用了

  TotalGasBudgetWithCap
  模式；
• 网络接收到包含特定特征的交易：即以可变共享对象（Mutable Shared Object）为输入，且不包含任何MoveCall指令。

一旦这种交易进入网络，所有验证者会同时崩溃，整个网络自然也就停摆了。

深度解析：Sui的拥堵控制机制

Sui的核心优势在于它的对象导向架构，这允许大量交易并行处理，从而实现高性能。但有个问题在于，当多笔交易试图写入同一个共享对象时，就必须串行执行，这就会产生拥堵。为此，Sui引入了拥堵控制机制，来限制单个共享对象的处理速率，防止网络过载。

近期，Sui对拥堵控制系统进行了升级，引入了

模式，希望能更精准地评估交易复杂度。然而，这个新模式的代码中存在一个未被充分测试的漏洞。发现问题后，Sui团队的反应速度很快，通过代码修复（PR#20365）发布了主网v1.37.4和测试网v1.38.1版本更新。验证者社区的配合也不错，从修复发布到网络恢复，只用了15分钟。

Typus协议观点：此次事故与Solana宕机本质不同

Sui的停摆，难免让人联想到Solana甚至TON近期的网络问题。对于这种“同病相怜”的联想，Sui生态DeFi协议Typus的CGO Kyrie在社交媒体上做了澄清，他认为这次事件与Solana的宕机有本质区别。

Kyrie说的很直接：Solana的问题源于网络拥堵导致的系统级崩溃，往往需要大规模架构调整才能根治。而Sui这次事故，属于明确的技术逻辑缺陷，不触及系统的基础架构。他用一个比喻来解释：问题出在计算交易成本时的数值溢出（Overflow），简单说，就是计算数值超过了系统能存储的范围，导致系统陷入无限循环。而PR#20365通过设定正确的计算上限，直接解决了这个问题。他强调，这个bug只存在于交易成本计算的程序逻辑中，并非Sui的共识机制或架构设计出了问题，这也是为什么修复能如此迅速。

Franklin Templeton携手Sui，布局RWA赛道

停摆事件的第二天，Sui Foundation就宣布了与全球知名的资产管理公司Franklin Templeton的合作。Franklin Templeton在声明中特别提到了Deepbook、Karrier One及ika这三个协议及基础设施。

考虑到Franklin Templeton在区块链领域，尤其是现实世界资产（RWA）代币化上的深耕，这次合作或许预示着Sui正凭借其对象导向架构和对安全性的极致追求，成为机构级RWA应用的重要承载平台。