Gevinster:
- Evne til å forstå DeFi-byggesteiner som AMM, likviditetspool, orakel- og flashlån og bruke kunstig intelligens i mekanismeforklaring og scenarioutforming
- Å kunne skille at de fleste DeFi-risikoer er økonomiske/forretningslogiske sårbarheter, ikke kodefeil, og at kunstig intelligens er svak i den opprinnelige økonomiske sårbarheten
- Å kunne forstå at økonomisk sikkerhet bevises ved simulering, ikke ved å tenke, og at orakelavhengighet er det mest skjøre punktet.
DeFi (Decentralized Finance) er det høyeste verdi og mest angrepne domenet til Web3. Børser, utlånsprotokoller, likviditetspooler – alt kjøres som kode, og alle flytter millioner av dollar i et fiendtlig miljø. I denne enheten vil vi bruke AI som assistent for protokollanalyse; Vi vil lære å forstå likviditet, prissetting, MEV og økonomiske angrep og hvor AI er nyttig og utilstrekkelig i dette kontekstuelle området.
Grunnleggende byggeklosser i DeFi
- AMM (Automated Market Maker): En byttemekanisme som setter prisene etter en formel (f.eks. x·y=k) i stedet for å matche kjøpere og selgere.
- Likviditetspool: Et felles fond hvor brukere setter inn tokens og handel finner sted.
- Utlånsprotokoll: Lån mot sikkerhet; Likvidering skjer når panteverdien synker.
- Oracle: Datakilden som bringer omverdenens pris til protokollen — DeFis mest kritiske og mest skjøre avhengighet.
- Flashlån: Et lån tatt uten sikkerhet i en enkelt transaksjon og returnert i samme transaksjon; Den har både legitim bruk og et angrepsverktøy.
MEV og økonomiske angrep
MEV (Maximal Extractable Value — verdien som trekkes ut av myndigheten for å bestille/legge til/fjerne transaksjoner) er en risikoklasse spesifikk for DeFi. Ventende transaksjoner vises i den offentlige poolen (mempool); Denne synligheten åpner døren for følgende angrep:
- Front-running: Å se en lønnsom transaksjon og sette inn sin egen transaksjon foran den.
- Sandwichangrep: Plassering av transaksjoner før og etter offerets kjøp og tjene på prisforskjellen.
- Oracle-manipulasjon: Bedra protokollen ved å umiddelbart endre prisen på en pool, vanligvis med et flashlån.
Disse angrepene oppstår ikke fra "buggen" i koden, men fra utnyttelsen av det økonomiske designet. Det er her AI har det vanskeligste: AI som er flink til å skanne teknisk kode, kan ofte ikke oppdage en protokollspesifikk økonomisk sårbarhet.
Oppmerksomhet: Flertallet av DeFi-sårbarhetene er ikke "kodefeil", men økonomiske/forretningslogiske sårbarheter. AIs standard kodeskanning savner disse; Dette er feltet som krever mest menneskelig ekspertise, simulering og modellering.
Rollen til AI i DeFi-analyse
1. Mekanismebeskrivelse. AI er kraftig til å forklare i klartekst hvordan en kompleks protokoll (f.eks. en kurvebasert AMM) fungerer. Dette gir rask inngang til analyse.
2. Generere et scenario/mothypotese. "Til hvilken prisbevegelse vil denne gjeldsprotokollen gå inn i en avviklingskrise?" AI produserer scenarioutkast med spørsmål som; disse er testet ved simulering.
3. Påminnelse om kjente angrepsmønstre. AI fremkaller mønstrene fra tidligere DeFi-angrep (orakelmanipulasjon, reentrancy, likvidasjonsspiral) som en sjekkliste.
4. Utkast til simuleringsplan. AI kan komme opp med en plan for hvilke scenarier som skal testes; men selve simuleringen gjøres med verktøyet (Foundry, Tenderly).
Svak forespørsel / Sterk forespørsel
Svak melding:
Er denne DeFi-protokollen trygg?
Kraftig ledetekst:
Din rolle: DeFi-protokollanalytiker. Undersøk protokollmekanismen nedenfor. Vurder følgende økonomiske angrepsvektorer én etter én: orakelmanipulasjon (med flashlån), sandwich/front-running, likvidasjonsspiral, likviditetsuttakseffekt. For hver vektor: hvordan utløses, hvilken tilstand som kreves, mulig påvirkning. Dette er hypotesene som skal testes VED SIMULERING; Ikke si "sikkert/utrygt" helt sikkert. GENERER Faktisk angrepskode; Beskriv risiko kun for defensive formål.
Fire kopierbare maler
1) Mekanismebeskrivelse:
Forklar på enkelt språk, trinn for trinn, pris-/likviditetsmekanismen til denne protokollen: hva skjer når en bruker foretar en transaksjon, hvordan bestemmes prisen, hvilke eksterne avhengigheter er det? Merk delen du ikke forstår eller la være uklar.
2) Økonomisk angrepsoverflate:
Kartlegg den økonomiske angrepsoverflaten til denne protokollen: hvilke forutsetninger kan utnyttes i orakel, likviditet, sikkerhet, avvikling, styring? Skriv hver risiko med en betingelse ("hva hvis"). Presenter det som en hypotese som skal bekreftes ved simulering.
3) Stressscenario:
Tenk på følgende scenarier: hvis sikkerhetssymbolet faller med 50 %, hvis orakelprisen avviker med 30 % øyeblikkelig, hvis 80 % av likviditeten trekkes ut, hva vil protokollen være? Skriv ned virkningen av hvert scenario. Ikke hevder numerisk presisjon; Spesifiser at simulering er nødvendig.
4) Matching av historieangrepsmønster:
Har utformingen av denne protokollen lignende forhold som hvilke av de kjente DeFi-angrepsmønstrene (f.eks. orakel med én kilde, åpen pris for flashlån)? Pek på likheter for defensive formål; Ikke ta utnyttelsestrinnet, det vil bare gi et oppmerksomhetspunkt.
Tre minietuier (i antall)
Tilfelle 1 – Oracle-risiko oppdaget tidlig. Et team var i ferd med å utforme en ny gjeldsprotokoll. Under mekanismeforklaringen markerte YZ hypotesen om at "prisen er tatt fra en enkelt pool og kan manipuleres med flashlån." Teamet bekreftet dette i simuleringen og gikk over til TWAP + multi-sourcing. Estimert tap unngått: hele den låste verdien av protokollen. Leksjon: AI er verdifull for å fremkalle kjente mønstre.
Tilfelle 2 – AI gikk glipp av den opprinnelige sårbarheten. I en annen protokoll var sårbarheten en unik økonomisk feil som følge av samspillet mellom to mekanismer (belønning + avvikling). AI fant hver mekanisme "feilfri" en etter en; Kunne ikke se interaksjonen. Menneskelig modellerer og simulering fanget. Leksjon: Selv om komponentene er riktige, er økonomien i helheten AIs blindsone.
Tilfelle 3 — Simuleringsplanen sparte tid. En analytiker utarbeidet 15 forskjellige stressscenarier i AI i stedet for å planlegge dem for hånd; så kjørte det på Foundry. Planleggingen gikk ned fra 1 dag til 2 timer; men tolkningen av resultatene og avgjørelsen var menneskets. Leksjon: AI-planer, kjøretøytiltak, mennesket bestemmer.
Simuleringens uunnværlighet
I DeFi bevises ikke sikkerhet ved å "tenke"; Den er testet ved simulering. Den økonomiske robustheten til en protokoll kan forstås ved numerisk å kjøre forskjellige pris-, likviditets- og angrepsscenarier. AI kan planlegge og utarbeide koden for disse simuleringene; men det er verktøyene og menneskene som produserer og tolker resultatene. Utsagnet "sannsynligvis holdbart" produsert av AI er ikke et simuleringsresultat og kan ikke presenteres som sådan.
Tips: Når du mottar en DeFi-risikovurdering fra AI, bør du spørre hver hypotese "hvilken simulering tester jeg dette med?" Gjør det om til et spørsmål. Et sikkerhetskrav som ikke kan testes er ikke en forsikring i DeFi.
Vanlige feil
- Skanner det økonomiske underskuddet som en kodefeil. DeFi-risikoer er for det meste i forretningslogikk.
- Stoler på at AI sier "trygt" og hopper over simuleringen. Testing er nødvendig.
- Validerer komponenter én etter én og hopper over interaksjon. Helhetens økonomi er kritisk.
- Stoler på Oracle fra én enkelt kilde. Den vanligste DeFi-katastrofen.
- Ignorerer MEV/front-running. Å glemme faktumet med offentlig mempool.
- Genererer utnyttelseskode. Bare defensiv analyse er legitim.
Oppsummert
- DeFi er en høyverdig og fiendtlig plass; Risikoen ligger for det meste i økonomisk/forretningslogikk.
- MEV, front-running, sandwich- og orakelmanipulasjon er klasser av angrep som er spesifikke for DeFi.
- AI er sterk i mekanismeforklaring og scenarioutkast; Det opprinnelige økonomiske underskuddet er svakt.
- Økonomisk sikkerhet bevises ved simulering, ikke ved å tenke; AI-planer, kjøretøytiltak.
- Oracle-avhengighet er det mest sårbare punktet ved DeFi; flere ressurser og TWAP kreves.
Søknadsoppgave
Velg en AMM eller utlånsprotokoll (med tydelig dokumentasjon). Bruk "mekanismebeskrivelse" og "økonomisk angrepsoverflate" på AI-en. For hver risikohypotese AI produserer, "hvilken simulering ville jeg teste dette med?" Svar på spørsmålet. Finn så den faktiske revisjonsrapporten for den protokollen og sammenlign de faktiske funnene med risikoene flagget av AI: Hva fanget AI, hva gikk glipp av?
sjekkliste
- [ ] Jeg diskuterte risikoene i to dimensjoner: kode + økonomi.
- [ ] Jeg evaluerte MEV/front-running.
- [ ] Jeg undersøkte også Oracle-avhengigheten.
- [ ] Jeg stilte spørsmål ved samspillet mellom komponentene (hele økonomien).
- [ ] Jeg koblet hver hypotese til en simuleringsplan.
- [ ] Jeg erstattet AI-ens "safe" med simulering.
- [ ] Jeg analyserte kun for defensive formål.