免费的交易所推荐：
公链Sui近期经历了一次难得一见的网络中断。在长达两个半小时的服务停顿后，Sui官方发布了详细的事故调查报告。尽管Sui在代码设计上与Solana有本质区别，但这次事件仍然引起了对网络去中心化程度以及稳定性的关注。同时，在停摆的第二天，Sui Foundation就宣布与华尔街资产管理公司Franklin Templeton联手，展现其在机构级应用方向上的积极布局。
拥堵控制代码导致验证者陷入崩溃循环
根据官方公布的报告内容，2024年11月21日凌晨（太平洋时间1:15至3:45），Sui主网出现了全面中断。所有验证节点都陷入了崩溃后不断重启的循环，这让整个网络无法处理任何交易。这件事再次说明，对于追求极高TPS的高性能公链来说，系统稳定性始终是个需要认真对待的课题。
官方调查指出，问题的根源在于拥堵控制（Congestion Control）模块中的一段代码存在逻辑异常。具体来说，当网络同时满足以下两个条件时，验证者就会发生崩溃：
- 拥堵控制机制开启了TotalGasBudgetWithCap模式；
- 网络收到带有特定特征的交易：这些交易以可变共享对象（Mutable Shared Object）为输入，但没有包含任何MoveCall指令。
一旦这种交易进入网络，所有验证者会同时触发崩溃，最终导致全网停摆。
深入理解：Sui的拥堵控制机制是怎么一回事？
Sui采用对象导向的架构，可以让大量交易并行处理，这是它实现高性能的关键。但是，当大量交易都想往同一个共享对象写入数据时，就必须按顺序执行，这时就会产生拥堵。为了应对这一情况，Sui引入了拥堵控制机制，目的是限制单个共享对象的处理速度，避免网络过载。
最近，Sui对拥堵控制系统进行了升级，引入了TotalGasBudgetWithCap模式，希望能更准确地评估交易的复杂度。然而这个模式的代码中存在一个没有被充分测试的漏洞。发现问题之后，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通过设定正确的计算上限解决了这个问题。他强调，这个问题只出现在交易成本计算的程序逻辑中，跟Sui的共识机制或整体架构设计无关，这也是修复速度这么快的原因。
Franklin Templeton与Sui联手，布局RWA赛道
在停摆事件发生的第二天，Sui Foundation就宣布与全球知名的资产管理公司Franklin Templeton达成合作。Franklin Templeton在声明中特别提到了Deepbook、Karrier One和ika这三个协议以及相关基础设施。
考虑到Franklin Templeton在区块链领域的深入参与，特别是它在现实世界资产（RWA）代币化方面的布局，这次合作也许意味着Sui打算利用自己的对象导向架构以及对安全性的专注，成为机构级RWA应用的重要承载平台。