Jag tittade på koden som var fel med Cetus igår kväll, och det första jag var väldigt misstänksam mot get_delta_b var varför den här funktionen skulle konvertera u256 till u64, vilket orsakade problemet med noggrannhetsavlyssning. Efter att ha frågat AI:n är det troligt att när cetus migrerade alla uniswap v3-formler, eftersom uni använder en fast punkt, måste det konverteras till ett flyttal utan noggrann säkerhetshänsyn. En sådan affärslogik, som hör till algoritmnivån, är svår att upptäcka vid kodauditeringar, om det inte också finns forskare som är förtrogna med både algoritmer och kod i revisionsinstitutet. Här är logiken för varför AI analyserar koden på det sätt som den gör: Baserat på min analys av kodbasen kan jag nu förklara varför författaren valde att implementera den på detta sätt get_delta_b funktioner och möjliga orsaker: Varför författaren till funktionen implementerar get_delta_b sättet Prestandaoptimering: ) och bitmask hanterar direkt U256-typer. Detta kommer med största sannolikhet att förbättra prestanda och minska beräkningskostnaderna. I DeFi-applikationer, särskilt högfrekventa handelsscenarier, är prestanda avgörande. Den utkommenterade koden använder u256::get ,u256::shrw Även om den nuvarande implementeringen använder bitoperationer (>> 64 Spara gasavgifter: Verksamheter på Sui-blockkedjan måste betala gasavgifter, och mer komplexa operationer kommer att förbruka mer gas. Förenklad matematik kan minska transaktionskostnaderna, särskilt för AMM-kärnfunktioner som används ofta. Minskade beroenden: Modulfunktioner, och den aktuella implementeringen minskar anrop till dessa funktioner, kanske för att minska beroenden av externa bibliotek eller för att undvika problem med vissa externa funktioner. Koden i kommentarerna använder mer u256 Solidity to Move-portering: När det gäller kodstil kan detta vara en portering från Ethereums Solidity-kod till Suis Move-språk. Denna användning av bitmanipulation och maskering är vanlig i Solidity, särskilt i AMM-implementeringar som Uniswap V3. Hantera matematik med fasta punkter: Det resulterande 256-bitarsresultatet måste bearbetas korrekt, och att flytta 64 bitar till höger är ett vanligt sätt att få rätt decimalpunktsposition. Fixpunktsmatematik används ofta i AMM för att hantera decimalvärden. full_math_u128::full_mul Potentiella problem Den här implementeringen medför dock flera problem: Dålig kodläsbarhet: Användningen av hårdkodade masker och förskjutningsåtgärder gör koden svår att förstå och granska. Brist på fullständig gränskontroll: Bitåtgärder och typkonverteringsåtgärder saknar omfattande gränskontroll, vilket kan leda till oväntat beteende i extrema fall. Kommentarkod samexisterar med implementeringskoder: Att behålla äldre versioner av kommenterad kod indikerar att koden kan vara i ett övergångstillstånd eller inte testad tillräckligt, vilket är farligt för kritisk kod som hanterar finansiella tillgångar. Risk för heltalsspill: När du hanterar stora värden kan bitåtgärder och transformeringar leda till heltalsspill, och förenklade implementeringar kan sakna tillräckliga skyddsmekanismer. sammanfattning Det är troligt att författarens främsta anledning till att implementera den här koden är att optimera prestanda och minska gaskostnaderna, samtidigt som matematiska beräkningar med fast punkt hanteras i AMM:er. Den här optimeringen, på bekostnad av kodsäkerhet och läsbarhet, kan dock ge angripare sårbarheter som kan utnyttjas, vilket du kan se i den Cetus-stöldincident som du angav. I DeFi-projekt bör säkerhet alltid ha företräde framför prestandaoptimering, särskilt för kärnfunktioner som hanterar användartillgångar. Det är bättre att använda beprövade biblioteksfunktioner, lägga till omfattande gränskontroller och genomföra adekvata säkerhetsrevisioner.