昨天晚上研究了一下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專案中，安全性應該始終優先於性能優化，特別是對於處理用戶資產的核心功能。 更好的做法是使用經過驗證的庫函數，增加全面的邊界檢查，並進行充分的安全審計。