Včera večer jsem se podíval na kód, který byl špatný v Cetusu, a první věc, která mi byla velmi podezřelá ohledně get_delta_b, bylo, proč tato funkce převádí u256 na u64, což způsobilo problém s přesností zachycení. Po dotazu na umělou inteligenci je pravděpodobné, že když společnost cetus migrovala všechny vzorce uniswap v3, protože uni používá pevnou čárku, je třeba ji převést na číslo s plovoucí desetinnou čárkou bez pečlivého zvážení zabezpečení. Tento druh obchodní logiky, která patří na úroveň algoritmu, je obtížné odhalit při auditech kódu, pokud auditorská instituce nemá také výzkumníky, kteří jsou obeznámeni jak s algoritmy, tak s kódem. Zde je logika, proč umělá inteligence analyzuje kód tak, jak to dělá: Na základě mé analýzy kódové základny nyní mohu vysvětlit, proč se autor rozhodl ji implementovat tímto způsobem get_delta_b Funkce a možné příčiny: Proč autor funkce implementuje get_delta_b způsobem Optimalizace výkonu: ) a bitová maska přímo pracují s typy U256. To s největší pravděpodobností zlepší výkon a sníží výpočetní režii. V aplikacích DeFi, zejména ve scénářích vysokofrekvenčního obchodování, je výkon kritický. Zakomentovaný kód používá u256::get ,u256::shrw zatímco současná implementace používá bitové operace (>> 64 Ušetřete poplatky za plyn: Operace na blockchainu Sui musí platit poplatky za plyn a složitější operace spotřebují více plynu. Zjednodušení matematiky může snížit transakční náklady, zejména u často provozovaných základních funkcí AMM. Snížené závislosti: Funkce modulu a současná implementace snižuje volání těchto funkcí, možná aby se snížila závislost na externích knihovnách nebo aby se předešlo problémům s některými externími funkcemi. Kód v komentářích používá více u256 Portování Solidity to Move: Pokud jde o styl kódu, mohlo by se jednat o portování z kódu Solidity Etherea do jazyka Move společnosti Sui. Toto použití manipulace s bity a maskování je v Solidity běžné, zejména v implementacích AMM, jako je Uniswap V3. Řešení matematiky s pevnou desetinnou čárkou: Výsledný 256bitový výsledek je třeba správně zpracovat a posunutí o 64 bitů doprava je běžný způsob, jak získat správnou desetinnou čárku. Matematika s pevnou desetinnou čárkou se často používá v AMM pro práci s desetinnými hodnotami. full_math_u128::full_mul Potenciální problémy Tato implementace však přináší několik problémů: Špatná čitelnost kódu: Použití pevně zakódovaných masek a operací přemístění ztěžuje pochopení a audit kódu. Nedostatek kontroly úplných rozsahů: Bitové operace a operace převodu typu postrádají komplexní kontrolu rozsahu, což může v extrémních případech vést k neočekávanému chování. Komentování kódu existuje společně s implementačním kódem: Zachování starších verzí komentovaného kódu znamená, že kód může být v přechodném stavu nebo není dostatečně otestován, což je nebezpečné pro kritický kód pracující s finančními aktivy. Riziko přetečení celých čísel: Při práci s velkými hodnotami mohou bitové operace a transformace vést k přetečení celých čísel a zjednodušené implementace mohou postrádat adekvátní ochranné mechanismy. shrnutí Je pravděpodobné, že hlavním důvodem autora pro implementaci tohoto kódu je optimalizace výkonu a snížení nákladů na plyn při zpracování matematických výpočtů s pevnou řádovou čárkou v AMM. Tato optimalizace však může na úkor zabezpečení a čitelnosti kódu poskytnout útočníkům zneužitelné zranitelnosti, jak můžete vidět z incidentu krádeže Cetus, který jste poskytli. V projektech DeFi by bezpečnost měla mít vždy přednost před optimalizací výkonu, zejména u základních funkcí, které zpracovávají uživatelská aktiva. Je lepší používat osvědčené funkce knihovny, přidat komplexní kontroly hranic a provádět adekvátní bezpečnostní audity.