Вчера вечером я изучал код Cetus, который вызвал проблемы, и первое, что вызвало у меня сомнения, это функция get_delta_b, почему она преобразует u256 в u64, что приводит к проблемам с потерей точности. Я спросил AI, и Cetus, вероятно, перенес все формулы Uniswap V3, потому что Uniswap использует фиксированные числа, и процесс преобразования в числа с плавающей точкой не был тщательно продуман с точки зрения безопасности, что привело к преобразованию. Это относится к бизнес-логике на уровне алгоритма, которую трудно обнаружить при аудите кода, если только аудиторская организация не имеет исследователей, знакомых как с алгоритмами, так и с кодом. Вот анализ AI, почему код написан именно так: На основе моего анализа кодовой базы, я сейчас могу объяснить, почему автор выбрал именно такой способ реализации get_delta_b функции, а также возможные причины: Почему автор реализовал функцию get_delta_b таким образом Оптимизация производительности: ) и битовая маска напрямую обрабатывают тип u256. Это, вероятно, сделано для повышения производительности и снижения вычислительных затрат. В приложениях DeFi, особенно в сценариях высокочастотной торговли, производительность имеет решающее значение. Закомментированный код использует операции u256::get ,u256::shrw и другие, а текущая реализация использует битовые операции (>> 64 Экономия Gas: Операции на блокчейне Sui требуют оплаты Gas, более сложные операции потребляют больше Gas. Упрощение математических вычислений может снизить стоимость транзакций, особенно для часто используемых основных функций AMM. Снижение зависимости: модульные функции, а текущая реализация снижает вызовы этих функций, возможно, для уменьшения зависимости от внешних библиотек или избежания проблем с некоторыми внешними функциями. Закомментированный код использует больше u256 Перенос из Solidity в Move: По стилю кода это может быть перенос кода из Solidity Ethereum в язык Move Sui. Использование битовых операций и масок в Solidity очень распространено, особенно в реализации AMM, таких как Uniswap V3. Обработка фиксированной точки: Полученный 256-битный результат требует правильной обработки, сдвиг вправо на 64 бита является обычным методом получения правильного положения десятичной точки. В AMM часто используется математика фиксированной точки для обработки малых значений. full_math_u128::full_mul Потенциальные проблемы Однако такой способ реализации вводит несколько проблем: Плохая читаемость кода: Использование жестко закодированных масок и операций сдвига делает код трудным для понимания и аудита. Отсутствие полного контроля границ: Операции с битами и преобразования типов не имеют полного контроля границ, что может привести к неожиданному поведению в экстремальных случаях. Сосуществование закомментированного кода и реализованного кода: Сохранение старой версии закомментированного кода указывает на то, что код может находиться в переходном состоянии или недостаточно протестирован, что опасно для ключевого кода, обрабатывающего финансовые активы. Риск переполнения целых чисел: При обработке больших значений битовые операции и преобразования могут привести к переполнению целых чисел, а упрощенная реализация может не иметь достаточных механизмов защиты. Заключение Основная причина, по которой автор реализовал этот код, вероятно, заключается в оптимизации производительности и снижении затрат на Gas, одновременно обрабатывая математические вычисления фиксированной точки в AMM. Однако такая оптимизация идет в ущерб безопасности и читаемости кода, что может предоставить уязвимости для атак, как показано в случае кражи Cetus. В проектах DeFi безопасность всегда должна быть приоритетом перед оптимизацией производительности, особенно для основных функций, обрабатывающих пользовательские активы. Лучшей практикой является использование проверенных библиотечных функций, добавление полного контроля границ и проведение тщательного аудита безопасности.