Вчора ввечері я подивився на код, який був неправильним з Cetus, і перше, що мене дуже запідозрило в get_delta_b, це те, чому ця функція перетворює u256 в u64, що викликало проблему перехоплення точності. Після запитання ШІ, ймовірно, що коли cetus переніс усі формули uniswap v3, оскільки uni використовує фіксовану точку, його потрібно перетворити на число з плаваючою комою без ретельного міркування безпеки. Такого роду бізнес-логіку, яка відноситься до алгоритмічного рівня, важко виявити в аудиті коду, якщо тільки в аудиторській установі немає також дослідників, які знайомі як з алгоритмами, так і з кодом. Ось логіка того, чому штучний інтелект аналізує код саме так: Ґрунтуючись на моєму аналізі кодової бази, я тепер можу пояснити, чому автор вирішив реалізувати її саме так get_delta_b функції та можливі причини: Чому автор функції реалізує get_delta_b спосіб Оптимізація продуктивності: ) і бітова маска безпосередньо обробляють типи U256. Це, швидше за все, покращить продуктивність і зменшить обчислювальні витрати. У додатках DeFi, особливо в сценарії високочастотної торгівлі, продуктивність має вирішальне значення. У закоментованому коді використовується u256::get ,u256::shrw в той час як поточна реалізація використовує бітові операції (>> 64 Заощаджуйте комісію за газ: операції на блокчейні Sui повинні сплачувати комісію за газ, а складніші операції споживатимуть більше газу. Спрощення математики може знизити транзакційні витрати, особливо для часто використовуваних основних функцій AMM. Зменшення залежностей: функції модулів, і поточна реалізація зменшує виклики цих функцій, можливо, щоб зменшити залежності від зовнішніх бібліотек, або щоб уникнути проблем з деякими зовнішніми функціями. У коді в коментарях використовується більше u256 Перенесення Solidity to Move: З точки зору стилю коду, це може бути перенесення з коду Solidity Ethereum на мову Move Sui. Таке використання маніпуляцій зі бітами та маскування часто зустрічається в Solidity, особливо в реалізаціях AMM, таких як Uniswap V3. Робота з математикою з фіксованою комою: отриманий 256-бітний результат потрібно правильно обробити, а зсув на 64 біти вправо є поширеним способом отримати правильну позицію після коми. Математика з фіксованою комою часто використовується в AMM для роботи з десятковими значеннями. full_math_u128::full_mul Потенційні проблеми Однак така реалізація вносить кілька проблем: Погана читабельність коду: Використання жорстко закодованих масок та операцій переміщення ускладнює розуміння та аудит коду. Відсутність повної перевірки меж: Операції з бітами та операціями перетворення типів не мають всебічної перевірки меж, що може призвести до неочікуваної поведінки в екстремальних випадках. Коментування коду співіснує з кодом реалізації: збереження старих версій коментованого коду вказує на те, що код може бути в перехідному стані або недостатньо протестований, що небезпечно для критичного коду, що має справу з фінансовими активами. Ризик переповнення цілих чисел: При роботі з великими значеннями, бітові операції та перетворення можуть призвести до цілочисельного переповнення, а спрощені реалізації можуть не мати належних механізмів захисту. зведення Цілком ймовірно, що основна причина впровадження цього коду полягає в оптимізації продуктивності та зниженні витрат на газ, одночасно обробляючи математичні розрахунки з фіксованою комою в АММ. Однак ця оптимізація, за рахунок безпеки та читабельності коду, може надати зловмисникам вразливості, які можна експлуатувати, як ви можете бачити з наданого вами інциденту з крадіжкою Cetus. У проєктах DeFi безпека завжди має пріоритет над оптимізацією продуктивності, особливо для основних функцій, які обробляють активи користувачів. Краще використовувати перевірені бібліотечні функції, додати всебічну перевірку меж і провести адекватні аудити безпеки.