【长推】通俗解释 Cetus 黑客攻击事件：暴露了什么问题？

Chainfeeds 导读：

这次攻击暴露的是一个经典的整数溢出问题，具体表现为类型转换过程中的数据截断。

文章来源：

https://x.com/tmel0211/status/1925568933794632163

文章作者：

Haotian

观点：

Haotian：技术细节拆解：1）漏洞定位：问题出现在 get_amount_by_liquidity 函数的类型转换机制中，从 u256 到 u64 的强制转换导致高位数据丢失。2）攻击流程：攻击者通过 add_liquidity 函数传入极大的流动性数量参数；系统调用 get_delta_b 函数计算所需的 B 代币数量；在计算过程中，两个 u128 类型数据相乘，理论结果应为 u256 类型。关键缺陷：函数返回时将 u256 结果强制转换为 u64，导致高位 128 位数据被截断。3）利用效果：原本需要大量代币才能铸造的流动性额度，现在仅需极少量代币即可完成。攻击者以极低成本获得巨额流动性份额，随后通过销毁部分流动性实现资金池套利。 需要明确一点：这次漏洞与 Sui 的底层安全架构无关，属于 Move 语言的安全性「荣光」暂时还可信。Why？Move 语言在资源管理和类型安全方面确实具备显著优势，能够有效防范双重支付、资源泄露等底层安全问题。但此次 Cetus 协议出现的是应用逻辑层面的数学计算错误，并非 Move 语言本身的设计缺陷。具体而言，Move 的类型系统虽然严格，但对于显式类型转换（explicit casting）操作，仍需依赖开发者的正确判断。当程序主动执行 u256 到 u64 的类型转换时，编译器无法判断这是有意设计还是逻辑错误。 此外，这次安全事件与 Sui 的共识机制、交易处理、状态管理等核心底层功能完全无关。Sui Network 只是忠实执行了 Cetus 协议提交的交易指令，漏洞源于应用层协议本身的逻辑缺陷。说白了，再先进的编程语言也无法完全杜绝应用层的逻辑错误。Move 能够防范大部分底层安全风险，但无法代替开发者进行业务逻辑的边界检查和数学运算的溢出保护。