Popularna wersja: Proste "tłumaczenie" na interpretację analizy @CetusProtocol hakera przez szefa technologicznego: Ten atak uwidacznia klasyczny problem z przepełnieniem liczb całkowitych, który objawia się obcinaniem danych podczas konwersji typów. Szczegóły techniczne po rozłożeniu: 1) Lokalizacja luki: Problem występuje w mechanizmie konwersji typów funkcji get_amount_by_liquidity, a konwersja rzutowania z U256 na U64 powoduje utratę danych wysokiego poziomu. 2) Proces ataku: 1. Atakujący przekazuje dużą ilość parametrów płynności przez funkcję add_liquidity; 2. Liczba tokenów B wymaganych do obliczenia funkcji wywołania systemowego get_delta_b; 3. W procesie obliczeniowym mnoży się dwa dane typu U128, a teoretyczny wynik powinien być typu U256; Wada klucza: Wynik u256 jest rzutowany na u64 po zwróceniu funkcji, co powoduje obcięcie danych 128-bitowych wysokiego poziomu. 3) Efekt wykorzystania: Limit płynności, który pierwotnie wymagał dużej liczby tokenów do wybicia, może teraz zostać zrealizowany przy użyciu tylko bardzo małej liczby tokenów. Atakujący uzyskuje ogromny udział w płynności przy bardzo niskich kosztach, a następnie realizuje arbitraż puli poprzez zniszczenie części płynności. Prosta analogia: tak jak przy użyciu kalkulatora, który może wyświetlić tylko 8 cyfr do obliczenia 1 miliarda × 1 miliarda, wynik 20-cyfrowego obliczenia może wyświetlić tylko ostatnie 8 cyfr, a pierwsze 12 cyfr znika bezpośrednio. Osoba atakująca wykorzystuje tę lukę. Żeby było jasne: ta luka nie ma nic wspólnego z podstawową architekturą bezpieczeństwa @SuiNetwork, a "chwała" bezpieczeństwa języka Move jest na razie nadal wiarygodna. Dlaczego? Język Move ma znaczące zalety w zakresie zarządzania zasobami i bezpieczeństwa typów, a także może skutecznie zapobiegać problemom z bezpieczeństwem niskiego poziomu, takim jak podwójne wydatki i wycieki zasobów. Tym razem jednak protokół Cetus jest matematycznym błędem na poziomie logiki aplikacji, a nie wadą projektową w samym języku Move. W szczególności system typów Move, choć rygorystyczny, nadal opiera się na właściwej ocenie programisty w przypadku wyraźnego rzucania. Gdy program aktywnie wykonuje konwersję typu z U256 na U64, kompilator nie może stwierdzić, czy jest to zamierzone, czy błąd logiczny. Ponadto ten incydent związany z bezpieczeństwem nie ma nic wspólnego z podstawowymi funkcjami Sui, takimi jak mechanizm konsensusu, przetwarzanie transakcji i zarządzanie stanem. Sui Network jedynie wiernie wykonuje instrukcje transakcyjne złożone przez protokół Cetus, a luka w zabezpieczeniach wynika z wad logicznych samego protokołu warstwy aplikacji. Mówiąc wprost, żadna ilość zaawansowanych języków programowania nie jest w stanie całkowicie wyeliminować błędów logicznych w warstwie aplikacji. Move może zapobiec większości podstawowych zagrożeń bezpieczeństwa, ale nie może zastąpić programistów sprawdzaniem granic logiki biznesowej i ochroną przed przepełnieniem operacji matematycznych.