Eu olhei para o código que estava errado com o Cetus ontem à noite, e a primeira coisa que eu estava muito desconfiado sobre get_delta_b era por que essa função iria converter u256 para u64, o que causou o problema de intercetação de precisão. Depois de perguntar à IA, é provável que quando o cetus migrou todas as fórmulas uniswap v3, porque uni usa um ponto fixo, ele precisa ser convertido em um número de ponto flutuante sem uma consideração cuidadosa de segurança. Esse tipo de lógica de negócios, que pertence ao nível do algoritmo, é difícil de detetar em auditorias de código, a menos que a instituição de auditoria também tenha pesquisadores que estejam familiarizados com algoritmos e código. Aqui está a lógica de por que a IA analisa o código da maneira que faz: Com base na minha análise da base de código, posso agora explicar por que o autor optou por implementá-la desta forma get_delta_b funções e possíveis causas: Por que o autor da função implementa get_delta_b maneira Otimização de desempenho: ) e bitmask lidam diretamente com tipos U256. É mais provável que isso melhore o desempenho e reduza a sobrecarga computacional. Em aplicações DeFi, especialmente cenários de negociação de alta frequência, o desempenho é crítico. O código comentado usa u256::get ,u256::shrw enquanto a implementação atual usa operações de bit (>> 64 Economize taxas de gás: as operações no blockchain Sui precisam pagar taxas de gás, e operações mais complexas consumirão mais gás. Simplificar a matemática pode reduzir os custos de transação, especialmente para funções principais AMM operadas com frequência. Dependências reduzidas: Funções de módulo, e a implementação atual reduz chamadas para essas funções, talvez para reduzir dependências em bibliotecas externas, ou para evitar problemas com algumas funções externas. O código nos comentários usa mais u256 Portabilidade Solidity to Move: Em termos de estilo de código, isso pode ser uma portabilidade do código Solidity do Ethereum para a linguagem Move da Sui. Este uso de manipulação de bits e mascaramento é comum no Solidity, especialmente em implementações AMM como Uniswap V3. Lidando com matemática de ponto fixo: O resultado resultante de 256 bits precisa ser processado corretamente, e deslocar 64 bits para a direita é uma maneira comum de obter a posição decimal correta. A matemática de ponto fixo é frequentemente usada em AMMs para lidar com valores decimais. full_math_u128::full_mul Problemas potenciais No entanto, esta aplicação introduz vários problemas: Má legibilidade do código: O uso de máscaras codificadas e operações de deslocamento torna o código difícil de entender e auditar. Falta de verificação de limites completos: as operações de bit e as operações de conversão de tipo não têm verificação de limites abrangente, o que pode levar a um comportamento inesperado em casos extremos. O código de comentário coexiste com o código de implementação: Manter versões mais antigas do código comentado indica que o código pode estar em um estado de transição ou não ser adequadamente testado, o que é perigoso para o código crítico que lida com ativos financeiros. Risco de estouro de inteiro: ao lidar com valores grandes, operações de bit e transformações podem levar a estouro de inteiro, e implementações simplificadas podem não ter mecanismos de proteção adequados. Resumo É provável que a principal razão do autor para implementar este código seja otimizar o desempenho e reduzir os custos de gás, enquanto lida com cálculos matemáticos de ponto fixo em AMMs. No entanto, essa otimização, em detrimento da segurança e legibilidade do código, pode fornecer aos invasores vulnerabilidades exploráveis, como você pode ver no incidente de roubo Cetus que você forneceu. Em projetos DeFi, a segurança deve sempre ter precedência sobre a otimização de desempenho, especialmente para funções principais que lidam com ativos do usuário. É melhor usar funções de biblioteca comprovadas, adicionar verificações de limites abrangentes e realizar auditorias de segurança adequadas.