Eu olhei para o código que estava errado com o Cetus ontem à noite, e a primeira coisa que fiquei muito desconfiado get_delta_b foi por que essa função converteria u256 em u64, o que causou o problema de interceptação de precisão. Depois de perguntar à IA, é provável que, quando o cetus migrou todas as fórmulas do uniswap v3, como o uni usa um ponto fixo, ele precise 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 detectar em auditorias de código, a menos que a instituição de auditoria também tenha pesquisadores 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 em minha análise da base de código, agora posso explicar por que o autor optou por implementá-la dessa maneira 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 os tipos U256. É mais provável que isso melhore o desempenho e reduza a sobrecarga computacional. Em aplicativos DeFi, especialmente em 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 bits (>> 64 Economize taxas de gás: as operações na blockchain Sui precisam pagar taxas de gás e operações mais complexas consumirão mais gás. A simplificação da matemática pode reduzir os custos de transação, especialmente para funções principais do AMM operadas com frequência. Dependências reduzidas: funções de módulo e a implementação atual reduzem chamadas para essas funções, talvez para reduzir dependências de 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 de Sui. Esse uso de manipulação e mascaramento de bits é comum no Solidity, especialmente em implementações de AMM, como o 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 correta do ponto decimal. A matemática de ponto fixo é frequentemente usada em AMMs para lidar com valores decimais. full_math_u128::full_mul Problemas potenciais No entanto, essa implementação apresenta vários problemas: Baixa 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 abrangente de limites, o que pode levar a um comportamento inesperado em casos extremos. O código de comentários 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 testado adequadamente, o que é perigoso para códigos críticos que lidam com ativos financeiros. Risco de estouro de inteiro: ao lidar com valores grandes, as operações e transformações de bits podem levar ao estouro de inteiros e as 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, às custas da segurança e legibilidade do código, pode fornecer aos invasores vulnerabilidades exploráveis, como você pode ver no incidente de roubo da 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 comprovadas da biblioteca, adicionar verificações abrangentes de limites e realizar auditorias de segurança adequadas.