Простой вариант: простая "перевод" интерпретация анализа технического специалиста о хакерской атаке на @CetusProtocol: Эта атака выявила классическую проблему переполнения целого числа, которая проявляется в виде обрезки данных при преобразовании типов. Разбор технических деталей: 1) Локализация уязвимости: проблема возникает в механизме преобразования типов функции get_amount_by_liquidity, где принудительное преобразование с u256 на u64 приводит к потере данных старших битов. 2) Процесс атаки: 1. Злоумышленник передает в функцию add_liquidity параметр с огромным количеством ликвидности; 2. Система вызывает функцию get_delta_b для расчета необходимого количества токенов B; 3. В процессе расчета два данных типа u128 перемножаются, теоретический результат должен быть типа u256; Ключевой недостаток: при возврате функции результат u256 принудительно преобразуется в u64, что приводит к обрезке данных старших 128 битов. 3) Эффект использования: изначально требовалось большое количество токенов для создания ликвидности, теперь это можно сделать с минимальным количеством токенов. Злоумышленник получает огромную долю ликвидности с минимальными затратами, затем реализует арбитраж пула путем уничтожения части ликвидности. Простая аналогия: как если бы использовать калькулятор, который может отображать только 8 цифр, для расчета 1 миллиард × 1 миллиард, 20-значный результат может отображать только последние 8 цифр, а первые 12 цифр просто исчезают. Злоумышленник использует именно такую "потерю точности вычислений". Важно отметить: эта уязвимость не связана с базовой архитектурой безопасности @SuiNetwork, безопасность языка Move временно остается надежной. Почему? Язык Move действительно обладает значительными преимуществами в управлении ресурсами и безопасности типов, эффективно предотвращая проблемы безопасности на уровне двойной оплаты, утечки ресурсов и т.д. Однако проблема в протоколе Cetus заключается в ошибке математических вычислений на уровне логики приложения, а не в недостатке самого языка Move. Конкретно, хотя система типов Move строгая, для операций явного преобразования типов (explicit casting) она все еще зависит от правильного суждения разработчика. Когда программа выполняет преобразование типа с u256 на u64, компилятор не может определить, является ли это намеренным дизайном или логической ошибкой. Кроме того, этот инцидент безопасности не связан с механизмом консенсуса, обработкой транзакций, управлением состоянием и другими основными функциями нижнего уровня Sui. Sui Network просто добросовестно выполняет команды транзакций, отправленные протоколом Cetus, уязвимость возникает из-за логической ошибки самого протокола приложения. Проще говоря, даже самый продвинутый язык программирования не может полностью исключить логические ошибки на уровне приложения. Move может предотвратить большинство рисков безопасности на нижнем уровне, но не может заменить разработчика в проверке границ бизнес-логики и защите от переполнения математических вычислений.