昨天晚上研究了一下cetus出问题的代码，首先非常疑虑的是get_delta_b这个函数为什么要将 u256 转换为 u64，而导致精度截取问题。问了AI，cetus大概率是把uniswap v3 公式全部迁移过来时，因为uni用的是定点数，需要转变成浮点数过程没做仔细的安全思考，而做了转换。这种属于算法层面的业务逻辑，在代码审计中很难察觉出来，除非审计机构也有算法和代码都熟悉的研究员。以下是AI分析为何这么写代码的逻辑： 基于我对代码库的分析，我现在可以解释为什么作者选择以这种方式实现 get_delta_b 函数，以及可能的原因： 函数为什么作者这样实现get_delta_b 性能优化：)和位掩码直接处理u256类型。这很可能是为了提高性能，减少计算开销。在DeFi应用中，特别是高频交易场景，性能至关重要。 注释掉的代码使用了u256::get ,u256::shrw 等操作，而当前实现使用位操作(>> 64 节省Gas费用：Sui区块链上的操作需要支付Gas费用，更复杂的操作会消耗更多Gas。简化数学运算可以降低交易成本，特别是对于频繁操作的AMM核心函数。 减少依赖：模块函数，而当前实现减少了对这些函数的调用，可能是为了减少对外部库的依赖，或避免某些外部函数的问题。 注释中的代码使用了更多的u256 Solidity到Move的移植：从代码风格看，这可能是从Ethereum的Solidity代码移植到Sui的Move语言。这种位操作和掩码的使用在Solidity中很常见，特别是在Uniswap V3等AMM实现中。 处理固定点数学：产生的256位结果需要正确处理，右移64位是获取正确小数点位置的常用方法。 AMM中经常使用固定点数学来处理小数值。full_math_u128::full_mul 潜在的问题 然而，这种实现方式引入了几个问题： 代码可读性差：使用硬编码掩码和位移操作使代码难以理解和审计。 缺乏完整的边界检查：位运算和类型转换操作缺乏全面的边界检查，可能导致在极端情况下出现意外行为。 注释代码与实现代码并存：保留旧版本的注释代码表明代码可能处于过渡状态或未经充分测试，这对于处理金融资产的关键代码来说是危险的。 整数溢出风险：在处理大数值时，位运算和转换可能导致整数溢出，而简化的实现可能缺少足够的保护机制。 总结 作者实现这段代码的主要原因很可能是为了优化性能和降低Gas成本，同时处理AMM中的固定点数学计算。然而，这种优化以牺牲代码安全性和可读性为代价，可能为攻击者提供了可利用的漏洞，正如您提供的Cetus被盗事件所示。 在DeFi项目中，安全性应该始终优先于性能优化，特别是对于处理用户资产的核心功能。更好的做法是使用经过验证的库函数，增加全面的边界检查，并进行充分的安全审计。