Gevinster:
- Evne til at forstå DeFi-byggesten som AMM, likviditetspulje, orakel- og flashlån og bruge kunstig intelligens i mekanismeforklaring og scenarieudkast
- At være i stand til at skelne, at de fleste DeFi-risici er økonomiske/forretningslogiske sårbarheder, ikke kodefejl, og at kunstig intelligens er svag i den oprindelige økonomiske sårbarhed
- At kunne forstå, at økonomisk sikkerhed bevises ved simulering, ikke ved at tænke, og at orakelafhængighed er det mest skrøbelige punkt.
DeFi (Decentralized Finance) er det højeste værdi og mest angrebne domæne af Web3. Udvekslinger, udlånsprotokoller, likviditetspuljer – alt sammen kører som kode og flytter alle millioner af dollars i et fjendtligt miljø. I denne enhed vil vi bruge AI som protokolanalyseassistent; Vi vil lære at forstå likviditet, prissætning, MEV og økonomiske angreb, og hvor AI er nyttig og utilstrækkelig i dette kontekstuelle område.
Grundlæggende byggesten i DeFi
- AMM (Automated Market Maker): En udvekslingsmekanisme, der fastsætter priser ved en formel (f.eks. x·y=k) i stedet for at matche købere og sælgere.
- Likviditetspulje: En fælles fond, hvor brugere indbetaler tokens og handler.
- Udlånsprotokol: Lån mod sikkerhed; Likvidation sker, når belåningsværdien falder.
- Oracle: Datakilden, der bringer omverdenens pris til protokollen — DeFis mest kritiske og mest skrøbelige afhængighed.
- Flashlån: Et lån taget uden sikkerhed i en enkelt transaktion og returneret i samme transaktion; Det har både legitime anvendelser og et angrebsværktøj.
MEV og økonomiske angreb
MEV (Maximal Extractable Value — værdien udtrukket af myndigheden til at bestille/tilføje/fjerne transaktioner) er en risikoklasse, der er specifik for DeFi. Afventende transaktioner vises i den offentlige pulje (mempool); Denne synlighed åbner døren til følgende angreb:
- Front-running: At se en rentabel transaktion og indsætte sin egen transaktion foran den.
- Sandwichangreb: Placering af transaktioner før og efter offerets køb og drage fordel af prisforskellen.
- Oracle-manipulation: Bedrager protokollen ved øjeblikkeligt at ændre prisen på en pool, normalt med et flashlån.
Disse angreb opstår ikke fra kodens "bug", men fra udnyttelsen af det økonomiske design. Det er her AI har det sværeste: AI, der er god til at scanne teknisk kode, kan ofte ikke opdage en protokolspecifik økonomisk sårbarhed.
Bemærk: Størstedelen af DeFi-sårbarheder er ikke "kodefejl", men økonomiske/forretningslogiske sårbarheder. AI's standardkodescanning savner disse; Dette er det felt, der kræver den mest menneskelige ekspertise, simulering og modellering.
AI's rolle i DeFi-analyse
1. Mekanismebeskrivelse. AI er stærk til at forklare i almindeligt sprog, hvordan en kompleks protokol (f.eks. en kurvebaseret AMM) fungerer. Dette giver hurtig adgang til analysen.
2. Generering af et scenarie/modhypotese. "Til hvilken prisbevægelse vil denne gældsprotokol gå ind i en likvidationskrise?" AI producerer scenarieudkast med spørgsmål som; disse testes ved simulering.
3. Påmindelse om kendte angrebsmønstre. AI’en fremkalder mønstrene fra tidligere DeFi-angreb (orakelmanipulation, genindtræden, likvidationsspiral) som en tjekliste.
4. Udkast til simuleringsplan. AI kan komme med en plan for, hvilke scenarier der skal testes; men selve simuleringen udføres med værktøjet (Foundry, Tenderly).
Svag prompt / Stærk prompt
Svag prompt:
Er denne DeFi-protokol sikker?
Kraftig prompt:
Din rolle: DeFi protokolanalytiker. Undersøg protokolmekanismen nedenfor. Overvej følgende økonomiske angrebsvektorer én efter én: orakelmanipulation (med flashlån), sandwich/front-running, likvidationsspiral, likviditetstilbagetrækningseffekt. For hver vektor: hvordan udløses, hvilken betingelse der kræves, mulig påvirkning. Dette er de hypoteser, der skal testes VED SIMULATION; Sig ikke "sikkert/usikkert" helt sikkert. GENERER Faktisk angrebskode; Beskriv risiko kun til defensive formål.
Fire kopierbare skabeloner
1) Mekanismebeskrivelse:
Forklar i almindeligt sprog, trin for trin, denne protokols prissætnings-/likviditetsmekanisme: hvad sker der, når en bruger foretager en transaktion, hvordan bestemmes prisen, hvilke eksterne afhængigheder er der? Marker den del, du ikke forstår, eller lad være uklar.
2) Økonomisk angrebsoverflade:
Kortlæg den økonomiske angrebsflade af denne protokol: hvilke antagelser kan udnyttes i orakel, likviditet, sikkerhedsstillelse, likvidation, regeringsførelse? Skriv hver risiko med en betingelse ("hvad nu hvis"). Præsenter det som en hypotese, der skal bekræftes ved simulering.
3) Stressscenarie:
Overvej følgende scenarier: hvis sikkerhedstoken falder med 50 %, hvis orakelprisen afviger med 30 % kortvarigt, hvis 80 % af likviditeten trækkes tilbage, hvad vil protokollen så være? Skriv ned afvirkningen af hvert scenarie. Gør ikke krav på numerisk præcision; Angiv, at simulering er påkrævet.
4) Matching af historieangrebsmønster:
Har designet af denne protokol lignende betingelser som hvilke af de kendte DeFi-angrebsmønstre (f.eks. orakel med én kilde, åben pris for flashlån)? Påpeg ligheder til defensive formål; Tag ikke udnyttelsestrinnet, det vil kun give et opmærksomhedspunkt.
Tre minisager (i antal)
Case 1 — Oracle-risiko opdaget tidligt. Et team var ved at designe en ny gældsprotokol. Under mekanismeforklaringen markerede YZ hypotesen, at "prisen er taget fra en enkelt pulje og kan manipuleres med flashlån." Holdet bekræftede dette i simuleringen og flyttede til TWAP + multi-sourcing. Estimeret tab undgået: hele den låste værdi af protokollen. Lektion: AI er værdifuld til at fremkalde kendte mønstre.
Tilfælde 2 - AI gik glip af den oprindelige sårbarhed. I en anden protokol var sårbarheden en unik økonomisk fejl som følge af samspillet mellem to mekanismer (belønning + likvidation). AI fandt hver mekanisme "fejlfri" én efter én; Kunne ikke se interaktionen. Menneskelig modelbygger og simulering fanget. Lektion: Mens komponenterne er rigtige, er økonomien i helheden AI's blinde plet.
Case 3 — Simuleringsplanen sparede tid. En analytiker udarbejdede 15 forskellige stressscenarier i AI i stedet for at planlægge dem i hånden; så kørte det på Foundry. Planlægningen gik ned fra 1 dag til 2 timer; men fortolkningen af resultaterne og beslutningen var menneskets. Lektion: AI-planer, køretøjsforanstaltninger, mennesket bestemmer.
Simuleringens uundværlighed
I DeFi bevises sikkerhed ikke ved at "tænke"; Det er testet ved simulering. Den økonomiske robusthed af en protokol kan forstås ved numerisk at køre forskellige pris-, likviditets- og angrebsscenarier. AI kan planlægge og udarbejde koden for disse simuleringer; men det er værktøjerne og folkene, der producerer og fortolker resultaterne. Udsagnet "sandsynligvis holdbart" produceret af AI er ikke et simuleringsresultat og kan ikke præsenteres som sådan.
Tip: Når du modtager en DeFi-risikovurdering fra AI, bør du spørge hver hypotese "hvilken simulering tester jeg dette med?" Gør det til et spørgsmål. Et sikkerhedskrav, der ikke kan testes, er ikke en forsikring i DeFi.
Almindelige fejl
- Scanner det økonomiske underskud som en kodefejl. DeFi-risici er for det meste i forretningslogik.
- Stoler på, at AI siger "sikker" og springer simuleringen over. Test er påkrævet.
- Validerer komponenter én efter én og springer interaktion over. Helhedens økonomi er kritisk.
- Tillid til Oracle fra en enkelt kilde. Den mest almindelige DeFi-katastrofe.
- Ignorerer MEV/front-running. At glemme kendsgerningen om offentlig mempool.
- Generering af udnyttelseskode. Kun defensiv analyse er legitim.
Sammenfattende
- DeFi er et højværdi og fjendtligt rum; Risiciene ligger for det meste i økonomisk/forretningslogik.
- MEV, front-running, sandwich og oracle manipulation er klasser af angreb, der er specifikke for DeFi.
- AI er stærk i mekanismeforklaring og scenarieudformning; Det oprindelige økonomiske underskud er svagt.
- Økonomisk sikkerhed bevises ved simulering, ikke tænkning; AI-planer, køretøjsforanstaltninger.
- Oracle-afhængighed er det mest sårbare punkt ved DeFi; flere ressourcer og TWAP påkrævet.
Ansøgningsopgave
Vælg en AMM eller udlånsprotokol (med tydelig dokumentation). Anvend meddelelserne "mekanismebeskrivelse" og "økonomisk angrebsoverflade" på AI'en. For hver risikohypotese, som AI producerer, "hvilken simulering ville jeg teste dette med?" Besvar spørgsmålet. Find derefter den faktiske revisionsrapport for denne protokol, og sammenlign de faktiske resultater med de risici, som AI’en har markeret: Hvad fangede AI’en, hvad gik den glip af?
tjekliste
- [ ] Jeg diskuterede risiciene i to dimensioner: kode + økonomi.
- [ ] Jeg vurderede MEV/frontløb.
- [ ] Jeg undersøgte også Oracle-afhængigheden.
- [ ] Jeg satte spørgsmålstegn ved samspillet mellem komponenterne (hele økonomien).
- [ ] Jeg koblede hver hypotese til en simuleringsplan.
- [ ] Jeg erstattede AI's "safe" med simulering.
- [ ] Jeg analyserede kun til defensive formål.