Yksikkö 6 / 11

DeFi- ja protokolla-analyysi: Likviditeetti, MEV ja taloudelliset hyökkäykset

Voitot:

  • Kyky ymmärtää DeFin rakennuspalikoita, kuten AMM, likviditeettipooli, oraakkeli ja flash-laina sekä käyttää tekoälyä mekanismien selittämisessä ja skenaarioiden laatimisessa
  • Kyky erottaa, että useimmat DeFi-riskit ovat taloudellisia/liiketoimintalogiikan haavoittuvuuksia, eivät koodivirheitä, ja että tekoäly on heikko alkuperäisessä taloudellisessa haavoittuvuudessa
  • Kyky ymmärtää, että taloudellinen turvallisuus todistetaan simuloinnilla, ei ajattelulla, ja että oraakkeliriippuvuus on haurain kohta.

DeFi (Decentralized Finance) on Web3:n arvokkain ja hyökätyin verkkotunnus. Pörssit, lainausprotokollat, likviditeettipoolit – kaikki toimivat koodina ja kaikki siirtävät miljoonia dollareita vihamielisessä ympäristössä. Tässä yksikössä käytämme tekoälyä protokolla-analyysin avustajana; Opimme ymmärtämään likviditeettiä, hinnoittelua, MEV- ja taloudellisia hyökkäyksiä ja sitä, missä tekoäly on hyödyllinen ja riittämätön tällä kontekstuaalisella alueella.

DeFin perusrakennuspalikoita

  • AMM (Automated Market Maker): Vaihtomekanismi, joka asettaa hinnat kaavalla (esim. x·y=k) ostajien ja myyjien yhdistämisen sijaan.
  • Likviditeettipooli: Sijoitusrahasto, jossa käyttäjät tallettavat tokeneita ja jossa käydään kauppaa.
  • Lainausprotokolla: Lainaus vakuuksia vastaan; Likvidaatio tapahtuu, kun vakuuden arvo laskee.
  • Oracle: Tietolähde, joka tuo protokollaan ulkomaailman hinnan – DeFin kriittisin ja haurain riippuvuus.
  • Flash-laina: Laina, joka on otettu ilman vakuuksia yhdessä kaupassa ja palautettu samassa kaupassa; Sillä on sekä laillisia käyttötarkoituksia että hyökkäystyökalu.

MEV ja taloushyökkäykset

MEV (Maximal Extractable Value – arvo, jonka valtuudet tilata/lisätä/poistaa tapahtumia) poimii, on DeFille oma riskiluokka. Odottavat tapahtumat näkyvät julkisessa poolissa (mempool); Tämä näkyvyys avaa oven seuraaville hyökkäyksille:

  • Etukäteistyö: Kannattavan tapahtuman näkeminen ja oman tapahtuman lisääminen sen eteen.
  • Sandwich-hyökkäys: Tapahtumien sijoittaminen ennen ja jälkeen uhrin oston ja hintaeron hyötyminen.
  • Oraakkelin manipulointi: Protokollan huijaaminen muuttamalla välittömästi poolin hintaa, yleensä pikalainalla.

Nämä hyökkäykset eivät johdu koodin "virheestä", vaan taloudellisen suunnittelun hyödynnettävyydestä. Tässä tekoälyllä on eniten vaikeuksia: teknisen koodin skannaamiseen perehtynyt tekoäly ei useinkaan pysty havaitsemaan protokollakohtaista taloudellista haavoittuvuutta.

Huomio: Suurin osa DeFi-haavoittuvuuksista ei ole "koodivirheitä", vaan talouden/liiketoiminnan logiikan haavoittuvuuksia. Tekoälyn standardikoodiskannaus jättää nämä huomiotta; Tämä on ala, joka vaatii eniten inhimillistä asiantuntemusta, simulointia ja mallintamista.

Tekoälyn rooli DeFi-analyysissä

1. Mekanismin kuvaus. AI on tehokas selittämään selkeällä kielellä, kuinka monimutkainen protokolla (esim. käyräpohjainen AMM) toimii. Tämä mahdollistaa nopean pääsyn analyysiin.

2. Skenaarion/vastahypoteesin luominen. "Millä hintaliikkeellä tämä velkapöytäkirja joutuu likvidaatiokriisiin?" AI tuottaa skenaarioluonnoksia, joissa on kysymyksiä, kuten; nämä testataan simuloinnilla.

3. Tunnettujen hyökkäysmallien muistuttaminen. Tekoäly herättää aiempien DeFi-hyökkäysten mallit (oraakkelin manipulointi, palautus, likvidaatiospiraali) kuin tarkistuslista.

4. Simulaatiosuunnitelmaluonnos. Tekoäly voi laatia suunnitelman, mitä skenaarioita testataan; mutta itse simulointi tehdään työkalulla (Foundry, Tenderly).

Heikko kehote / Vahva kehote

Heikko kehote:

Onko tämä DeFi-protokolla turvallinen?

Tehokas kehotus:

Roolisi: DeFi-protokollaanalyytikko. Tutki alla olevaa protokollamekanismia. Harkitse seuraavia taloudellisia hyökkäysvektoreita yksitellen: oraakkelin manipulointi (flash-lainalla), sandwich/front-running, likvidaatiospiraali, likviditeetin poistovaikutus. Jokaiselle vektorille: miten laukaista, mikä ehto vaaditaan, mahdollinen vaikutus. Nämä ovat hypoteeseja, jotka testataan SIMULAATIIN; Älä sano "turvallinen/turvaton" varmasti. LUO Todellinen hyökkäyskoodi; Kuvaa riski vain puolustustarkoituksessa.

Neljä kopioitavaa mallia

1) Mekanismin kuvaus:

Selitä selkeällä kielellä askel askeleelta tämän protokollan hinnoittelu-/likviditeettimekanismi: mitä tapahtuu, kun käyttäjä tekee tapahtuman, miten hinta määritetään, mitä ulkoisia riippuvuuksia on olemassa? Merkitse se osa, jota et ymmärrä tai jätä epäselväksi.

2) Taloudellinen hyökkäyspinta:

Kartoita tämän pöytäkirjan taloudellinen hyökkäyspinta: mitä oletuksia voidaan hyödyntää oraakkelissa, likviditeetissä, vakuuksissa, selvitystilassa ja hallinnossa? Kirjoita jokainen riski ehdolla ("mitä jos"). Esitä se hypoteesina, joka vahvistetaan simuloinnilla.

3) Stressitilanne:

Harkitse seuraavia skenaarioita: jos vakuustunnus putoaa 50 %, jos oraakkelin hinta poikkeaa 30 % hetkellisesti, jos 80 % likviditeetistä nostetaan, mikä on protokolla? Kirjoita muistiin kunkin skenaarion knock-on-vaikutus. Älä vaadi numeerista tarkkuutta; Ilmoita, että simulointi vaaditaan.

4) Historiallinen hyökkäysmallin vastaavuus:

Onko tämän protokollan suunnittelussa samanlaisia ehtoja kuin missä tunnetuista DeFi-hyökkäysmalleista (esim. yhden lähteen oraakkeli, flash-lainan avoin hinta)? Osoita yhtäläisyyksiä puolustustarkoituksessa; Älä ota hyväksikäyttöaskelta, se tuottaa vain huomion.

Kolme minikoteloa (numeroina)

Tapaus 1 – Oracle-riski havaittiin varhain. Ryhmä suunnitteli uutta velkaprotokollaa. YZ merkitsi mekanismin selityksessä hypoteesin, että "hinta on otettu yhdestä poolista ja sitä voidaan manipuloida pikalainoilla". Tiimi vahvisti tämän simulaatiossa ja siirtyi TWAP + monilähteeseen. Arvioitu häviö vältetty: protokollan koko lukittu arvo. Oppitunti: AI on arvokas tunnettujen kuvioiden herättämisessä.

Tapaus 2 – AI menetti alkuperäisen haavoittuvuuden. Toisessa protokollassa haavoittuvuus oli ainutlaatuinen taloudellinen virhe, joka johtui kahden mekanismin vuorovaikutuksesta (palkkio + likvidaatio). Tekoäly havaitsi jokaisen mekanismin "virheettömiksi" yksitellen; Vuorovaikutusta ei näkynyt. Ihmisen mallinnus ja simulaatio kuvattu. Oppitunti: Vaikka komponentit ovat oikein, kokonaisuuden talous on AI:n sokea piste.

Tapaus 3 – Simulaatiosuunnitelma säästää aikaa. Yksi analyytikko laati tekoälyyn 15 erilaista stressiskenaariota sen sijaan, että olisi suunnitellut niitä käsin; sitten juoksi sitä valimossa. Suunnittelu lyheni yhdestä päivästä 2 tuntiin; mutta tulosten tulkinta ja päätös oli ihmisen. Oppitunti: AI-suunnitelmat, ajoneuvojen mittaukset, ihminen päättää.

Simuloinnin välttämättömyys

DeFissä turvallisuutta ei todisteta "ajattelulla"; Se testataan simuloinnilla. Protokollan taloudellinen kestävyys voidaan ymmärtää ajamalla numeerisesti erilaisia ​​hinta-, likviditeetti- ja hyökkäysskenaarioita. Tekoäly voi suunnitella ja laatia näiden simulaatioiden koodin; mutta työkalut ja ihmiset tuottavat ja tulkitsevat tuloksia. Tekoälyn tuottama väite "todennäköisesti kestävä" ei ole simulaatiotulos, eikä sitä voida sellaisenaan esittää.

Vinkki: Kun saat DeFi-riskiarvioinnin tekoälyltä, sinun tulee kysyä jokaiselta hypoteesilta "millä simulaatiolla testaan ​​tätä?" Muuta se kysymykseksi. Turvavaatimus, jota ei voida testata, ei ole takuu DeFissä.

Yleisiä virheitä

  • Talouden alijäämän skannaus kuin koodivirhe. DeFi-riskit ovat enimmäkseen liiketoimintalogiikassa.
  • Luotetaan tekoälyyn sanomaan "turvallinen" ja ohitetaan simulaatio. Testaus vaaditaan.
  • Komponenttien vahvistaminen yksitellen ja vuorovaikutuksen ohittaminen. Koko talous on kriittinen.
  • Oracleen luottaminen yhdestä lähteestä. Yleisin DeFi-katastrofi.
  • Ohitetaan MEV/edussa. Julkisen mempoolin tosiasian unohtaminen.
  • Luodaan hyväksikäyttökoodia. Vain puolustava analyysi on oikeutettua.

Yhteenvetona

  • DeFi on arvokas ja vihamielinen tila; Riskit ovat enimmäkseen talouden/liiketoiminnan logiikassa.
  • MEV, front-running, sandwich ja oracle manipulointi ovat DeFille ominaisia ​​hyökkäyksiä.
  • AI on vahva mekanismien selityksessä ja skenaarioiden laatimisessa; Alkuperäinen talousalijäämä on heikko.
  • Taloudellinen turvallisuus todistetaan simuloinnilla, ei ajattelulla; Tekoälysuunnitelmat, ajoneuvotoimenpiteet.
  • Oracle-riippuvuus on DeFin haavoittuvin kohta; tarvitaan useita resursseja ja TWAP.

Sovellustehtävä

Valitse AMM tai lainausprotokolla (selkeillä asiakirjoilla). Käytä "mekanismin kuvaus" ja "taloudellinen hyökkäyspinta" -kehotteita tekoälyyn. Tekoäly tuottaa jokaiselle riskihypoteesille "millä simulaatiolla testaisin tätä?" Vastaa kysymykseen. Etsi sitten kyseisen protokollan varsinainen tarkastusraportti ja vertaa todellisia löydöksiä tekoälyn ilmoittamiin riskeihin: Mitä tekoäly sai kiinni, mitä se jäi huomaamatta?

tarkistuslista

  • [ ] Keskustelin riskeistä kahdessa ulottuvuudessa: koodi + talous.
  • [ ] Arvioin MEV/edussa.
  • [ ] Tutkin myös Oracle-riippuvuutta.
  • [ ] Kyseenalaistan komponenttien vuorovaikutuksen (koko talouden).
  • [ ] Yhdistin jokaisen hypoteesin simulaatiosuunnitelmaan.
  • [ ] Korvasin tekoälyn "turvallisen" simulaatiolla.
  • [ ] Analysoin vain puolustustarkoituksessa.