Jeg så på koden som var feil med Cetus i går kveld, og det første jeg var veldig mistenksom om get_delta_b var hvorfor denne funksjonen ville konvertere u256 til u64, noe som forårsaket nøyaktighetsavskjæringsproblemet. Etter å ha spurt AI, er det sannsynlig at når cetus migrerte alle uniswap v3-formlene, fordi uni bruker et fikspunkt, må det konverteres til et flyttall uten nøye sikkerhetshensyn. Denne typen forretningslogikk, som tilhører algoritmenivået, er vanskelig å oppdage i koderevisjoner, med mindre revisjonsinstitusjonen også har forskere som er kjent med både algoritmer og kode. Her er logikken i hvorfor AI analyserer koden på den måten den gjør: Basert på min analyse av kodebasen kan jeg nå forklare hvorfor forfatteren valgte å implementere den på denne måten get_delta_b funksjoner, og mulige årsaker: Hvorfor forfatteren av funksjonen implementerer get_delta_b måte Ytelsesoptimalisering: ) og bitmaske håndterer U256-typer direkte. Dette vil mest sannsynlig forbedre ytelsen og redusere beregningskostnader. I DeFi-applikasjoner, spesielt høyfrekvente handelsscenarier, er ytelsen avgjørende. Den kommenterte koden bruker u256::get ,u256::shrw mens den nåværende implementeringen bruker bitoperasjoner (>> 64 Spar gassavgifter: Operasjoner på Sui-blokkjeden må betale gassavgifter, og mer komplekse operasjoner vil forbruke mer gass. Forenkling av matematikk kan redusere transaksjonskostnadene, spesielt for ofte opererte AMM-kjernefunksjoner. Reduserte avhengigheter: Modulfunksjoner, og den nåværende implementeringen reduserer kall til disse funksjonene, kanskje for å redusere avhengigheter av eksterne biblioteker, eller for å unngå problemer med enkelte eksterne funksjoner. Koden i kommentarfeltet bruker mer u256 Solidity to Move-portering: Når det gjelder kodestil, kan dette være en portering fra Ethereums Solidity-kode til Suis Move-språk. Denne bruken av bitmanipulasjon og maskering er vanlig i Solidity, spesielt i AMM-implementeringer som Uniswap V3. Håndtere fastpunktmatematikk: Det resulterende 256-biters resultatet må behandles riktig, og å flytte 64 biter til høyre er en vanlig måte å få riktig desimalposisjon på. Fastpunktmatematikk brukes ofte i AMM-er for å håndtere desimalverdier. full_math_u128::full_mul Potensielle problemer Denne implementeringen introduserer imidlertid flere problemer: Dårlig kodelesbarhet: Bruken av hardkodede masker og forskyvningsoperasjoner gjør koden vanskelig å forstå og revidere. Mangel på full grensekontroll: Bitoperasjoner og typekonverteringsoperasjoner mangler omfattende grensekontroll, noe som kan føre til uventet oppførsel i ekstreme tilfeller. Kommenterende kode eksisterer side om side med implementeringskode: Å beholde eldre versjoner av kommentert kode indikerer at koden kan være i en overgangstilstand eller ikke tilstrekkelig testet, noe som er farlig for kritisk kode som omhandler finansielle eiendeler. Risiko for heltallsoverflyt: Når du arbeider med store verdier, kan bitoperasjoner og transformasjoner føre til heltallsoverflyt, og forenklede implementeringer kan mangle tilstrekkelige beskyttelsesmekanismer. sammendrag Det er sannsynlig at forfatterens hovedårsak til å implementere denne koden er å optimalisere ytelsen og redusere gasskostnadene, samtidig som han håndterer matematiske beregninger med fast punkt i AMM-er. Imidlertid kan denne optimaliseringen, på bekostning av kodesikkerhet og lesbarhet, gi angripere sårbarheter som kan utnyttes, som du kan se fra Cetus-tyverihendelsen du oppga. I DeFi-prosjekter bør sikkerhet alltid ha forrang over ytelsesoptimalisering, spesielt for kjernefunksjoner som håndterer brukerressurser. Det er bedre å bruke velprøvde bibliotekfunksjoner, legge til omfattende grensekontroller og gjennomføre tilstrekkelige sikkerhetsrevisjoner.