zisky:
- Schopnost porozumět stavebním blokům DeFi, jako je AMM, fond likvidity, oracle a flash úvěr a používat umělou inteligenci při vysvětlení mechanismů a navrhování scénářů
- Schopnost rozlišit, že většina rizik DeFi jsou zranitelnosti ekonomické/obchodní logiky, nikoli chyby v kódu, a že umělá inteligence je slabá v původní ekonomické zranitelnosti
- Být schopen pochopit, že ekonomická bezpečnost se dokazuje simulací, nikoli myšlením, a že závislost na orákulu je tím nejkřehčím bodem.
DeFi (Decentralized Finance) je nejhodnotnější a nejnapadanější doménou Web3. Burzy, půjčovací protokoly, fondy likvidity – to vše běží jako kód a všechny přesouvají miliony dolarů v nepřátelském prostředí. V této jednotce budeme používat AI jako asistenta analýzy protokolu; Naučíme se porozumět likviditě, cenám, MEV a ekonomickým útokům a tomu, kde je AI v této kontextové oblasti užitečná a neadekvátní.
Základní stavební kameny DeFi
- AMM (Automated Market Maker): Mechanismus směny, který určuje ceny podle vzorce (např. x·y=k) spíše než párování kupujících a prodávajících.
- Fond likvidity: Společný fond, do kterého uživatelé vkládají tokeny a obchodují.
- Výpůjční protokol: Půjčka proti zástavě; K likvidaci dochází, když hodnota zajištění klesá.
- Oracle: Zdroj dat, který protokolu přináší vnější cenu – nejkritičtější a nejkřehčí závislost DeFi.
- Blesková půjčka: Půjčka přijatá bez zajištění v jedné transakci a vrácená ve stejné transakci; Má jak legitimní použití, tak nástroj pro útok.
MEV a ekonomické útoky
MEV (maximální extrahovatelná hodnota – hodnota extrahovaná orgánem pro objednávání/přidávání/odebírání transakcí) je riziková třída specifická pro DeFi. Nevyřízené transakce se objeví ve veřejném fondu (mempool); Tato viditelnost otevírá dveře následujícím útokům:
- Front-running: Vidět ziskovou transakci a vložit před ni vlastní transakci.
- Sendvičový útok: Uskutečňování transakcí před a po nákupu oběti a profitování z cenového rozdílu.
- Oracle manipulace: Klamání protokolu okamžitou změnou ceny fondu, obvykle pomocí bleskové půjčky.
Tyto útoky nevznikají z „chyby“ kódu, ale ze zneužitelnosti ekonomického návrhu. Zde má AI největší potíže: AI, která je dobrá ve skenování technického kódu, často nedokáže detekovat ekonomickou zranitelnost specifickou pro daný protokol.
Upozornění: Většina zranitelností DeFi nejsou „chyby v kódu“, ale zranitelnosti ekonomické/obchodní logiky. Standardní skenování kódu AI je postrádá; Toto je oblast, která vyžaduje nejvíce lidských znalostí, simulace a modelování.
Role AI v analýze DeFi
1. Popis mechanismu. Umělá inteligence dokáže srozumitelným jazykem vysvětlit, jak funguje složitý protokol (např. AMM založený na křivkách). To umožňuje rychlý vstup do analýzy.
2. Generování scénáře/protihypotézy. "Při jakém cenovém pohybu vstoupí tento dluhový protokol do likvidační krize?" AI vytváří návrhy scénářů s otázkami jako; tyto jsou testovány simulací.
3. Připomenutí známých vzorů útoků. Umělá inteligence evokuje vzorce minulých útoků DeFi (manipulace s věštcem, reentrancy, likvidační spirála) jako kontrolní seznam.
4. Návrh plánu simulace. Umělá inteligence může přijít s plánem, které scénáře otestovat; ale samotná simulace se provádí pomocí nástroje (Foundry, Tenderly).
Slabá výzva / Silná výzva
Slabá výzva:
Je tento protokol DeFi bezpečný?
Výkonná výzva:
Vaše role: analytik protokolu DeFi. Prozkoumejte mechanismus protokolu níže. Uvažujme jeden po druhém následující vektory ekonomického útoku: manipulace s věštcem (s bleskovou půjčkou), sendvič/front-running, likvidační spirála, efekt stažení likvidity. Pro každý vektor: jak spustit, jaká podmínka je požadována, možný dopad. Toto jsou hypotézy, které mají být testovány SIMULACE; Určitě neříkejte „zabezpečené/nebezpečné“. GENERATE Skutečný kód útoku; Popište riziko pouze pro obranné účely.
Čtyři kopírovatelné šablony
1) Popis mechanismu:
Vysvětlete srozumitelným jazykem, krok za krokem, mechanismus tvorby cen/likvidity tohoto protokolu: co se stane, když uživatel provede transakci, jak se určuje cena, jaké existují externí závislosti? Označte část, které nerozumíte nebo ji nechte nejasnou.
2) Plocha ekonomického útoku:
Zmapujte povrch ekonomického útoku tohoto protokolu: jaké předpoklady lze využít v orákulu, likviditě, kolaterálu, likvidaci, správě věcí veřejných? Každé riziko zapište s podmínkou („co kdyby“). Předložte to jako hypotézu, která má být potvrzena simulací.
3) Stresový scénář:
Zvažte následující scénáře: pokud token kolaterálu klesne o 50 %, pokud se cena orákula na chvíli odchýlí o 30 %, pokud se stáhne 80 % likvidity, jaký bude protokol? Zapište si řetězový efekt každého scénáře. Nenárokujte si číselnou přesnost; Určete, že je vyžadována simulace.
4) Porovnání vzorů útoku historie:
Snáší návrh tohoto protokolu podobné podmínky, jaké ze známých vzorů útoku DeFi (např. jednozdrojový oracle, otevřená cena flash půjčky)? Poukázat na podobnosti pro obranné účely; Nedělejte vykořisťovací krok, jen to vzbudí pozornost.
Tři mini pouzdra (v číslech)
Případ 1 – Riziko společnosti Oracle bylo včas odhaleno. Tým navrhoval nový dluhový protokol. Během vysvětlování mechanismu YZ označil hypotézu, že „cena je převzata z jednoho fondu a může být manipulována pomocí bleskových půjček“. Tým to potvrdil v simulaci a přešel na TWAP + multi-sourcing. Zabráněno odhadované ztrátě: celá uzamčená hodnota protokolu. Ponaučení: Umělá inteligence je cenná při vyvolávání známých vzorů.
Případ 2 – AI minula původní zranitelnost. V jiném protokolu byla zranitelnost jedinečnou ekonomickou chybou vyplývající ze vzájemného působení dvou mechanismů (odměna + likvidace). Umělá inteligence shledala každý mechanismus „bezchybný“ jeden po druhém; Interakce se nepodařilo zobrazit. Lidský modelář a simulace zachyceny. Ponaučení: zatímco komponenty jsou správné, ekonomika celku je slepým místem AI.
Případ 3 — Simulační plán ušetřil čas. Jeden analytik navrhl 15 různých stresových scénářů do AI, místo aby je plánoval ručně; pak to spustil ve Foundry. Plánování se zkrátilo z 1 dne na 2 hodiny; ale interpretace výsledků a rozhodnutí byly na člověku. Lekce: AI plány, měření vozidel, lidská rozhodnutí.
Nezbytnost simulace
V DeFi se bezpečnost neprokazuje „myšlením“; Testuje se simulací. Ekonomická robustnost protokolu může být pochopena tím, že numericky spustíte různé scénáře cen, likvidity a útoku. AI může plánovat a navrhovat kód těchto simulací; ale jsou to nástroje a lidé, kteří vytvářejí a interpretují výsledky. Výrok „pravděpodobně odolný“ vytvořený AI není výsledkem simulace a nelze jej jako takový prezentovat.
Tip: Když od AI obdržíte hodnocení rizika DeFi, měli byste se každé hypotézy zeptat: „Jakou simulací to mám testovat?“ Udělejte z toho otázku. Bezpečnostní tvrzení, které nelze otestovat, není v DeFi ujištění.
Časté chyby
- Skenování ekonomického deficitu jako chyba v kódu. Rizika DeFi jsou většinou v obchodní logice.
- Důvěřovat AI, že řekne „bezpečné“ a přeskakovat simulaci. Je vyžadováno testování.
- Ověřování komponent jedna po druhé a přeskakování interakce. Ekonomika celku je kritická.
- Důvěřujte Oracle z jednoho zdroje. Nejčastější katastrofa DeFi.
- Ignorování MEV/přední chod. Zapomínání na fakt veřejného mempoolu.
- Generování exploit kódu. Pouze defenzivní analýza je legitimní.
V souhrnu
- DeFi je vysoce hodnotný a nepřátelský prostor; Rizika jsou většinou v ekonomické/obchodní logice.
- MEV, front-running, sandwich a oracle manipulace jsou třídy útoků specifické pro DeFi.
- AI je silná ve vysvětlování mechanismů a navrhování scénářů; Původní ekonomický deficit je slabý.
- Ekonomická bezpečnost se dokazuje simulací, nikoli myšlením; Plány AI, opatření vozidel.
- Závislost na Oracle je nejzranitelnějším bodem DeFi; vyžaduje více zdrojů a TWAP.
Aplikační úkol
Vyberte si AMM nebo výpůjční protokol (s jasnou dokumentací). Aplikujte na AI výzvy „popis mechanismu“ a „plocha ekonomického útoku“. U každé rizikové hypotézy, kterou AI vytvoří, „jakou simulaci bych to otestoval?“ Odpovězte na otázku. Poté najděte skutečnou zprávu o auditu tohoto protokolu a porovnejte skutečná zjištění s riziky označenými AI: Co AI zachytila, co jí uniklo?
kontrolní seznam
- [ ] Rizika jsem probíral ve dvou dimenzích: kód + ekonomika.
- [ ] Hodnotil jsem MEV/přední běh.
- [ ] Zkoumal jsem také závislost Oracle.
- [ ] Zpochybnil jsem interakci komponent (celá ekonomika).
- [ ] Každou hypotézu jsem propojil se simulačním plánem.
- [ ] Nahradil jsem "trezor" AI simulací.
- [ ] Analyzoval jsem pouze pro obranné účely.