Câștiguri:
- Abilitatea de a înțelege elementele de bază ale DeFi, cum ar fi AMM, fondul de lichiditate, oracle și împrumut flash și de a utiliza inteligența artificială în explicarea mecanismului și în elaborarea scenariului
- A putea distinge faptul că majoritatea riscurilor DeFi sunt vulnerabilități economice/logicii de afaceri, nu erori de cod și că inteligența artificială este slabă în vulnerabilitatea economică inițială
- A putea înțelege că securitatea economică este dovedită prin simulare, nu prin gândire și că dependența de oracol este punctul cel mai fragil.
DeFi (Decentralized Finance) este domeniul cu cea mai mare valoare și cel mai atacat al Web3. Schimburile, protocoalele de creditare, pool-urile de lichidități — toate rulează ca cod și toate mută milioane de dolari într-un mediu ostil. În această unitate, vom folosi AI ca asistent de analiză a protocolului; Vom învăța să înțelegem lichiditatea, prețurile, MEV și atacurile economice și unde AI este utilă și inadecvată în acest domeniu contextual.
Elementele de bază ale DeFi
- AMM (Automated Market Maker): un mecanism de schimb care stabilește prețurile printr-o formulă (de exemplu, x·y=k), mai degrabă decât potrivirea cumpărătorilor și vânzătorilor.
- Fond de lichiditate: un fond comun în care utilizatorii depun jetoane și are loc tranzacționarea.
- Protocolul de creditare: Împrumut cu garanție; Lichidarea are loc atunci când valoarea garanției scade.
- Oracle: Sursa de date care aduce prețul din lumea exterioară la protocol - cea mai critică și mai fragilă dependență a DeFi.
- Împrumut rapid: Un împrumut luat fără garanție într-o singură tranzacție și returnat în aceeași tranzacție; Are atât utilizări legitime, cât și un instrument de atac.
MEV și atacuri economice
MEV (Valoarea maximă extractabilă — valoarea extrasă de autoritate pentru a comanda/adăuga/elimina tranzacții) este o clasă de risc specifică DeFi. Tranzacțiile în așteptare apar în pool-ul public (mempool); Această vizibilitate deschide ușa pentru următoarele atacuri:
- Front-running: Vederea unei tranzacții profitabile și introducerea propriei tranzacții în fața acesteia.
- Atacul tip sandwich: Plasarea tranzacțiilor înainte și după cumpărarea victimei și profitând din diferența de preț.
- Manipularea Oracle: Înșelarea protocolului prin modificarea instantanee a prețului unui pool, de obicei cu un împrumut rapid.
Aceste atacuri nu provin din „bug” codului, ci din exploabilitatea designului economic. Aici AI are cele mai multe dificultăți: AI care se pricepe la scanarea codului tehnic adesea nu poate detecta o vulnerabilitate economică specifică protocolului.
Atenție: majoritatea vulnerabilităților DeFi nu sunt „bucuri de cod”, ci vulnerabilități economice/logicii de afaceri. Scanarea codului standard al AI nu le face; Acesta este domeniul care necesită cea mai umană expertiză, simulare și modelare.
Rolul AI în analiza DeFi
1. Descrierea mecanismului. AI este puternică în a explica într-un limbaj simplu cum funcționează un protocol complex (de exemplu, un AMM bazat pe curbe). Acest lucru oferă o intrare rapidă în analiză.
2. Generarea unui scenariu/contra-ipoteză. „La ce mișcare de preț va intra acest protocol de datorii într-o criză de lichidare?” AI produce schițe de scenarii cu întrebări precum; acestea sunt testate prin simulare.
3. Reamintirea tiparelor de atac cunoscute. AI evocă tiparele atacurilor DeFi din trecut (manipularea oracolului, reintrarea, spirala de lichidare) ca o listă de verificare.
4. Proiect de plan de simulare. AI poate veni cu un plan pentru care scenarii să fie testate; dar simularea în sine se face cu instrumentul (Foundry, Tenderly).
Prompt slab / Prompt puternic
Prompt slab:
Este acest protocol DeFi sigur?
Solicitare puternică:
Rolul tău: analist de protocol DeFi. Examinați mecanismul de protocol de mai jos. Luați în considerare următorii vectori de atac economic unul câte unul: manipularea oracolului (cu împrumut rapid), tip sandwich/front-running, spirala de lichidare, efectul de retragere a lichidității. Pentru fiecare vector: cum se declanșează, ce condiție este necesară, impact posibil. Acestea sunt ipotezele de testat PRIN SIMULARE; Nu spune „sigur/nesigur” cu siguranță. GENERATE Cod de atac real; Descrieți riscul numai în scopuri defensive.
Patru șabloane copiabile
1) Descrierea mecanismului:
Explicați într-un limbaj simplu, pas cu pas, mecanismul de preț/lichiditate al acestui protocol: ce se întâmplă atunci când un utilizator face o tranzacție, cum este determinat prețul, ce dependențe externe există? Marcați partea pe care nu o înțelegeți sau lăsați neclară.
2) Suprafața de atac economic:
Hartă suprafața de atac economic a acestui protocol: ce ipoteze pot fi exploatate în oracol, lichiditate, garanție, lichidare, guvernare? Scrieți fiecare risc cu o condiție („ce-ar fi dacă”). Prezentați-o ca o ipoteză care trebuie confirmată prin simulare.
3) Scenariu de stres:
Luați în considerare următoarele scenarii: dacă tokenul colateral scade cu 50%, dacă prețul oracolului se abate cu 30% momentan, dacă 80% din lichiditate este retrasă, care va fi protocolul? Notați efectul secundar al fiecărui scenariu. Nu pretindeți precizie numerică; Specificați că simularea este necesară.
4) Potrivirea modelului de atac istoric:
Designul acestui protocol suportă condiții similare cu care dintre modelele de atac DeFi cunoscute (de exemplu, oracol cu sursă unică, preț deschis împrumut rapid)? Subliniază asemănările în scopuri defensive; Nu face pasul de exploatare, va produce doar un punct de atenție.
Trei mini cutii (în cifre)
Cazul 1 – Riscul Oracle a fost detectat devreme. O echipă proiecta un nou protocol de îndatorare. În timpul explicației mecanismului, YZ a marcat ipoteza că „prețul este luat dintr-un singur pool și poate fi manipulat cu împrumuturi flash”. Echipa a confirmat acest lucru în simulare și a trecut la TWAP + multi-sourcing. Pierderea estimată evitată: întreaga valoare blocată a protocolului. Lecție: AI este valoroasă în evocarea tiparelor cunoscute.
Cazul 2 – AI a ratat vulnerabilitatea inițială. Într-un alt protocol, vulnerabilitatea a fost o eroare economică unică rezultată din interacțiunea a două mecanisme (recompensă + lichidare). AI a găsit fiecare mecanism „fără cusur” unul câte unul; Nu am putut vedea interacțiunea. Modelator uman și simulare capturate. Lecție: în timp ce componentele sunt corecte, economia întregului este punctul mort al AI.
Cazul 3 — Planul de simulare a economisit timp. Un analist a redactat 15 scenarii diferite de stres în IA în loc să le planifice manual; apoi a condus-o la Turnătorie. Planificarea a scăzut de la 1 zi la 2 ore; dar interpretarea rezultatelor și decizia au fost ale omului. Lecție: planuri AI, măsuri de vehicule, decizii umane.
Indispensabilitatea simulării
În DeFi, securitatea nu este dovedită prin „gândire”; Este testat prin simulare. Robustețea economică a unui protocol poate fi înțeleasă prin rularea numerică a diferitelor scenarii de preț, lichiditate și atac. AI poate planifica și redacta codul acestor simulări; dar instrumentele și oamenii sunt cei care produc și interpretează rezultatele. Declarația „probabil durabilă” produsă de AI nu este un rezultat de simulare și nu poate fi prezentată ca atare.
Sfat: Când primiți o evaluare a riscului DeFi de la AI, ar trebui să întrebați fiecare ipoteză „cu ce simulare testez asta?” Transformă-l într-o întrebare. O afirmație de securitate care nu poate fi testată nu este o asigurare în DeFi.
Greșeli comune
- Scanarea deficitului economic ca un bug de cod. Riscurile DeFi sunt în mare parte în logica afacerii.
- Având încredere în IA pentru a spune „în siguranță” și săriți peste simulare. Este necesară testarea.
- Validarea componentelor una câte una și omiterea interacțiunii. Economia întregului este critică.
- Aveți încredere în Oracle dintr-o singură sursă. Cel mai frecvent dezastru DeFi.
- Ignorarea MEV/front-running. Uitând de faptul că mempool-ul public.
- Generarea codului de exploatare. Numai analiza defensivă este legitimă.
Pe scurt
- DeFi este un spațiu de mare valoare și ostil; Riscurile sunt în mare parte în logica economică/de afaceri.
- MEV, front-running, sandwich și manipularea oracolului sunt clase de atacuri specifice DeFi.
- AI este puternică în explicarea mecanismului și în elaborarea scenariilor; Deficitul economic inițial este slab.
- Securitatea economică este dovedită prin simulare, nu prin gândire; Planuri AI, măsuri pentru vehicule.
- Dependența de Oracle este punctul cel mai vulnerabil al DeFi; sunt necesare resurse multiple și TWAP.
Sarcina de aplicare
Alegeți un protocol AMM sau de împrumut (cu documentație clară). Aplicați solicitările „descrierea mecanismului” și „suprafața de atac economic” la AI. Pentru fiecare ipoteză de risc pe care o produce AI, „cu ce simulare aș testa asta?” Răspunde la întrebare. Apoi găsiți raportul de audit propriu-zis al acelui protocol și comparați constatările reale cu riscurile semnalate de AI: Ce a prins AI, ce a ratat?
lista de verificare
- [ ] Am discutat despre riscuri în două dimensiuni: cod + economie.
- [ ] Am evaluat MEV/front-running.
- [ ] Am examinat și dependența Oracle.
- [ ] Am pus sub semnul întrebării interacțiunea componentelor (întreaga economie).
- [ ] Am conectat fiecare ipoteză la un plan de simulare.
- [ ] Am înlocuit „seiful” AI-ului cu simulare.
- [ ] Am analizat doar în scop defensiv.