Katsoin eilen illalla koodia, joka oli vialla Cetusissa, ja ensimmäinen asia, jota epäilin get_delta_b, oli se, miksi tämä toiminto muuntaa u256:n u64:ksi, mikä aiheutti tarkkuuden sieppausongelman. Tekoälyltä kysymisen jälkeen on todennäköistä, että kun cetus siirsi kaikki uniswap v3 -kaavat, koska uni käyttää kiinteää lukua, se on muunnettava liukuluvuksi ilman huolellista turvallisuusharkintaa. Tällaista algoritmitasolle kuuluvaa liiketoimintalogiikkaa on vaikea havaita kooditarkastuksissa, ellei tarkastuslaitoksessa ole myös tutkijoita, jotka tuntevat sekä algoritmit että koodin. Tässä on logiikka, miksi tekoäly analysoi koodia niin kuin se tekee: Koodipohjan analyysini perusteella voin nyt selittää, miksi kirjoittaja päätti toteuttaa sen tällä tavalla get_delta_b Toiminnot ja mahdolliset syyt: Miksi funktion tekijä toteuttaa get_delta_b tavalla Suorituskyvyn optimointi: ) ja bittimaski käsittelevät suoraan U256-tyyppejä. Tämä todennäköisesti parantaa suorituskykyä ja vähentää laskennallisia yleiskustannuksia. DeFi-sovelluksissa, erityisesti korkean taajuuden kaupankäyntiskenaarioissa, suorituskyky on kriittinen. Kommentoitu koodi käyttää u256::get ,u256::shrw Nykyinen toteutus käyttää bittioperaatioita (>> 64 Säästä kaasumaksuja: Sui-lohkoketjun toimintojen on maksettava kaasumaksuja, ja monimutkaisemmat toiminnot kuluttavat enemmän kaasua. Matematiikan yksinkertaistaminen voi vähentää transaktiokustannuksia erityisesti usein käytettävien AMM-ydintoimintojen osalta. Vähentyneet riippuvuudet: Moduulifunktiot, ja nykyinen toteutus vähentää näiden funktioiden kutsuja, ehkä vähentääkseen riippuvuuksia ulkoisista kirjastoista tai välttääkseen ongelmia joidenkin ulkoisten funktioiden kanssa. Kommenttien koodi käyttää enemmän u256:ta Solidity to Move -siirto: Koodityylin kannalta tämä voisi olla siirto Ethereumin Solidity-koodista Suin Move-kieleen. Tämä bittikäsittelyn ja peittämisen käyttö on yleistä Solidityssä, erityisesti AMM-toteutuksissa, kuten Uniswap V3. Kiinteän pisteen matematiikan käsittely: Tuloksena oleva 256-bittinen tulos on käsiteltävä oikein, ja 64 bitin siirtäminen oikealle on yleinen tapa saada oikea desimaalipilkku. Kiinteän pisteen matematiikkaa käytetään usein AMM:issä desimaaliarvojen käsittelyyn. full_math_u128::full_mul Mahdolliset ongelmat Tämä toteutus tuo kuitenkin mukanaan useita ongelmia: Huono koodin luettavuus: Kovakoodattujen maskien ja siirtotoimintojen käyttö vaikeuttaa koodin ymmärtämistä ja tarkastamista. Täyden rajojen tarkistuksen puute: Bittioperaatioista ja tyyppimuunnosoperaatioista puuttuu kattava rajojen tarkistus, mikä voi johtaa odottamattomaan toimintaan äärimmäisissä tapauksissa. Kommentointikoodi on olemassa rinnakkain toteutuskoodin kanssa: Kommentoidun koodin vanhempien versioiden säilyttäminen tarkoittaa, että koodi voi olla siirtymävaiheessa tai sitä ei ole testattu riittävästi, mikä on vaarallista rahoitusvaroja käsittelevälle kriittiselle koodille. Kokonaislukujen ylivuotoriski: Suuria arvoja käsiteltäessä bittioperaatiot ja muunnokset voivat johtaa kokonaislukujen ylivuotoon, ja yksinkertaistetuissa toteutuksissa ei välttämättä ole riittäviä suojausmekanismeja. yhteenveto On todennäköistä, että kirjoittajan tärkein syy tämän koodin toteuttamiseen on suorituskyvyn optimointi ja kaasukustannusten vähentäminen samalla kun käsitellään kiinteän pisteen matemaattisia laskelmia AMM:issä. Tämä optimointi voi kuitenkin koodin turvallisuuden ja luettavuuden kustannuksella tarjota hyökkääjille hyödynnettävissä olevia haavoittuvuuksia, kuten voit nähdä toimittamastasi Cetus-varkaustapauksesta. DeFi-projekteissa turvallisuuden tulisi aina olla etusijalla suorituskyvyn optimointiin nähden, erityisesti ydintoiminnoissa, jotka käsittelevät käyttäjän omaisuutta. On parempi käyttää hyväksi havaittuja kirjastotoimintoja, lisätä kattavia rajatarkistuksia ja suorittaa riittävät tietoturvatarkastukset.