Vinster:
- Förmåga att förstå DeFi-byggstenar som AMM, likviditetspool, orakel- och flashlån och använda artificiell intelligens i mekanismförklaring och scenarioutformning
- Att kunna urskilja att de flesta DeFi-riskerna är ekonomiska/affärslogiska sårbarheter, inte kodbuggar, och att artificiell intelligens är svag i den ursprungliga ekonomiska sårbarheten
- Att kunna förstå att ekonomisk säkerhet bevisas genom simulering, inte genom att tänka, och att orakelberoende är den ömtåligaste punkten.
DeFi (Decentralized Finance) är den högsta värdefulla och mest attackerade domänen i Web3. Utbyten, låneprotokoll, likviditetspooler – allt körs som kod och alla flyttar miljontals dollar i en fientlig miljö. I den här enheten kommer vi att använda AI som assistent för protokollanalys; Vi kommer att lära oss att förstå likviditet, prissättning, MEV och ekonomiska attacker och var AI är till hjälp och otillräcklig inom detta kontextuella område.
Grundläggande byggstenar i DeFi
- AMM (Automated Market Maker): En utbytesmekanism som sätter priser med en formel (t.ex. x·y=k) istället för att matcha köpare och säljare.
- Likviditetspool: En gemensam fond där användare sätter in tokens och handel sker.
- Utlåningsprotokoll: Upplåning mot säkerhet; Likvidation sker när pantvärdet minskar.
- Oracle: Datakällan som ger omvärldspriset till protokollet — DeFis mest kritiska och ömtåliga beroende.
- Snabblån: Ett lån som tas utan säkerhet i en enda transaktion och returneras i samma transaktion; Den har både legitim användning och ett attackverktyg.
MEV och ekonomiska attacker
MEV (Maximal Extractable Value — värdet som extraheras av myndigheten för att beställa/lägga till/ta bort transaktioner) är en riskklass som är specifik för DeFi. Väntande transaktioner visas i den offentliga poolen (mempool); Denna synlighet öppnar dörren till följande attacker:
- Front-running: Att se en lönsam transaktion och sätta in en egen transaktion framför den.
- Smörgåsattack: Placera transaktioner före och efter offrets köp och dra nytta av prisskillnaden.
- Oracle-manipulation: Lura protokollet genom att omedelbart ändra priset på en pool, vanligtvis med ett flashlån.
Dessa attacker härrör inte från "buggen" i koden, utan från den ekonomiska designens exploatering. Det är här AI har svårast: AI som är bra på att skanna teknisk kod kan ofta inte upptäcka en protokollspecifik ekonomisk sårbarhet.
Observera: Majoriteten av DeFi-sårbarheterna är inte "kodbuggar" utan ekonomiska/affärslogiska sårbarheter. AI:s standardkodskanning missar dessa; Detta är det område som kräver mest mänsklig expertis, simulering och modellering.
AI:s roll i DeFi-analys
1. Mekanismbeskrivning. AI är kraftfull på att förklara i klartext hur ett komplext protokoll (t.ex. en kurvbaserad AMM) fungerar. Detta ger snabb ingång i analysen.
2. Generera ett scenario/mothypotes. "Till vilken prisrörelse kommer detta skuldprotokoll att gå in i en likvidationskris?" AI tar fram scenarioutkast med frågor som; dessa testas genom simulering.
3. Påminnelse om kända attackmönster. AI:n framkallar mönstren från tidigare DeFi-attacker (orakelmanipulation, återinträde, likvidationsspiral) som en checklista.
4. Utkast till simuleringsplan. AI kan komma med en plan för vilka scenarier som ska testas; men själva simuleringen görs med verktyget (Foundry, Tenderly).
Svag prompt / Stark prompt
Svag uppmaning:
Är detta DeFi-protokoll säkert?
Kraftfull uppmaning:
Din roll: DeFi protokollanalytiker. Undersök protokollmekanismen nedan. Tänk på följande ekonomiska attackvektorer en efter en: orakelmanipulation (med flashlån), sandwich/front-running, likvidationsspiral, likviditetsuttagseffekt. För varje vektor: hur man utlöser, vilket tillstånd som krävs, möjlig påverkan. Det här är hypoteserna som ska testas GENOM SIMULERING; Säg inte "säkert/osäkert" med säkerhet. GENERERA faktisk attackkod; Beskriv risk endast i defensiva syften.
Fyra kopierbara mallar
1) Beskrivning av mekanismen:
Förklara på ett enkelt språk, steg för steg, prissättnings-/likviditetsmekanismen för detta protokoll: vad händer när en användare gör en transaktion, hur bestäms priset, vilka externa beroenden finns det? Markera den del du inte förstår eller lämna otydlig.
2) Ekonomisk attackyta:
Kartlägg den ekonomiska attackytan för detta protokoll: vilka antaganden kan utnyttjas i orakel, likviditet, säkerhet, likvidation, styrning? Skriv varje risk med ett villkor ("tänk om"). Presentera det som en hypotes som ska bekräftas genom simulering.
3) Stressscenario:
Tänk på följande scenarier: om säkerhetstoken sjunker med 50 %, om orakelpriset tillfälligt avviker med 30 %, om 80 % av likviditeten dras ut, vad blir protokollet? Skriv ner följdeffekten av varje scenario. Gör inte anspråk på numerisk precision; Ange att simulering krävs.
4) Matchning av historikattackmönster:
Har utformningen av detta protokoll liknande villkor som vilket av de kända DeFi-attackmönstren (t.ex. orakel med en källa, öppet pris för flashlån)? Peka på likheter i defensiva syften; Ta inte exploateringssteget, det kommer bara att ge en punkt av uppmärksamhet.
Tre minifodral (i antal)
Fall 1 – Oracle-risk upptäcktes tidigt. Ett team höll på att utforma ett nytt skuldprotokoll. Under mekanismförklaringen markerade YZ hypotesen att "priset tas från en enda pool och kan manipuleras med snabblån." Teamet bekräftade detta i simuleringen och gick över till TWAP + multi-sourcing. Uppskattad förlust undviken: hela det låsta värdet av protokollet. Lektion: AI är värdefullt för att framkalla kända mönster.
Fall 2 — AI missade den ursprungliga sårbarheten. I ett annat protokoll var sårbarheten ett unikt ekonomiskt fel som följde av interaktionen mellan två mekanismer (belöning + likvidation). AI:n fann varje mekanism "felfri" en efter en; Kunde inte se interaktionen. Människomodellerare och simulering fångas. Lärdom: medan komponenterna är rätt, är ekonomin i helheten AI:s blinda fläck.
Fall 3 — Simuleringsplanen sparade tid. En analytiker skrev ut 15 olika stressscenarier i AI:n istället för att planera dem för hand; sedan körde det på Foundry. Planeringen gick ner från 1 dag till 2 timmar; men tolkningen av resultaten och beslutet var människans. Lektion: AI-planer, fordonsåtgärder, människan bestämmer.
Simuleringens oumbärlighet
I DeFi bevisas inte säkerheten genom att "tänka"; Det testas genom simulering. Den ekonomiska robustheten hos ett protokoll kan förstås genom att numeriskt köra olika pris-, likviditets- och attackscenarier. AI kan planera och rita koden för dessa simuleringar; men det är verktygen och människorna som producerar och tolkar resultaten. Påståendet "förmodligen hållbart" producerat av AI är inte ett simuleringsresultat och kan inte presenteras som sådant.
Tips: När du får en DeFi-riskbedömning från AI bör du fråga varje hypotes "vilken simulering testar jag detta med?" Förvandla det till en fråga. Ett säkerhetskrav som inte kan testas är inte en garanti i DeFi.
Vanliga misstag
- Skanna det ekonomiska underskottet som en kodbugg. DeFi-risker ligger mest i affärslogik.
- Lita på att AI säger "säkert" och hoppar över simuleringen. Testning krävs.
- Validera komponenter en efter en och hoppa över interaktion. Helhetens ekonomi är avgörande.
- Lita på Oracle från en enda källa. Den vanligaste DeFi-katastrofen.
- Ignorerar MEV/front-running. Att glömma faktumet av offentlig mempool.
- Genererar exploateringskod. Endast defensiv analys är legitim.
Sammanfattningsvis
- DeFi är ett högvärdigt och fientligt utrymme; Riskerna ligger mest i ekonomisk/affärslogik.
- MEV, front-running, sandwich- och orakelmanipulation är klasser av attacker som är specifika för DeFi.
- AI är stark i mekanismförklaring och scenarioutformning; Det ursprungliga ekonomiska underskottet är svagt.
- Ekonomisk säkerhet bevisas genom simulering, inte genom att tänka; AI-planer, fordonsåtgärder.
- Oracle-beroende är den mest sårbara punkten i DeFi; flera resurser och TWAP krävs.
Applikationsuppgift
Välj ett AMM eller utlåningsprotokoll (med tydlig dokumentation). Tillämpa anvisningarna "mekanismbeskrivning" och "ekonomisk attackyta" på AI:n. För varje riskhypotes som AI producerar, "vilken simulering skulle jag testa detta med?" Svara på frågan. Hitta sedan den faktiska revisionsrapporten för det protokollet och jämför de faktiska resultaten med riskerna som flaggats av AI: Vad fångade AI:n, vad missade den?
checklista
- [ ] Jag diskuterade riskerna i två dimensioner: kod + ekonomi.
- [ ] Jag utvärderade MEV/front-running.
- [ ] Jag undersökte också Oracle-beroendet.
- [ ] Jag ifrågasatte samspelet mellan komponenterna (hela ekonomin).
- [ ] Jag kopplade varje hypotes till en simuleringsplan.
- [ ] Jag ersatte AI:s "safe" med simulering.
- [ ] Jag analyserade bara i defensiva syften.