Ieguvumi:
- Spēja izprast tādus DeFi blokus kā AMM, likviditātes fonds, orākuls un zibatmiņas aizdevums un izmantot mākslīgo intelektu mehānismu skaidrošanā un scenāriju izstrādē
- Spēja atšķirt, ka lielākā daļa DeFi risku ir ekonomikas/biznesa loģikas ievainojamības, nevis koda kļūdas, un ka mākslīgais intelekts ir vājš sākotnējā ekonomiskajā ievainojamībā.
- Spēja saprast, ka ekonomisko drošību pierāda simulācijas, nevis domāšana, un ka orākula atkarība ir trauslākais punkts.
DeFi (decentralizētās finanses) ir Web3 vērtīgākais un visvairāk uzbruktākais domēns. Biržas, aizdevumu protokoli, likviditātes pūli — tas viss darbojas kā kods, un tas viss pārvieto miljoniem dolāru naidīgā vidē. Šajā vienībā mēs izmantosim AI kā protokola analīzes palīgu; Mēs iemācīsimies izprast likviditāti, cenas, MEV un ekonomiskos uzbrukumus un to, kur AI ir noderīgs un neatbilstošs šajā kontekstā.
DeFi pamatelementi
- AMM (Automated Market Maker): apmaiņas mehānisms, kas nosaka cenas pēc formulas (piem., x·y=k), nevis saskaņojot pircējus un pārdevējus.
- Likviditātes fonds: kopējais fonds, kurā lietotāji nogulda žetonus un notiek tirdzniecība.
- Aizdevuma protokols: Aizņemšanās pret ķīlu; Likvidācija notiek, kad ķīlas vērtība samazinās.
- Oracle: datu avots, kas nodrošina ārpasaules cenu protokolam — DeFi viskritiskākā un trauslākā atkarība.
- Zibkredīts: Aizdevums, kas paņemts bez ķīlas vienā darījumā un atdots tajā pašā darījumā; Tam ir gan likumīgi lietojumi, gan uzbrukuma rīks.
MEV un ekonomiskie uzbrukumi
MEV (Maksimālā ekstrahējamā vērtība — vērtība, ko iegūst iestāde, lai pasūtītu/pievienotu/noņemtu darījumus) ir DeFi riska klase. Neapstiprinātie darījumi parādās publiskajā pūlā (mempool); Šī redzamība paver durvis šādiem uzbrukumiem:
- Priekšā: redzēt ienesīgu darījumu un ievietot tam priekšā savu darījumu.
- Sviestmaižu uzbrukums: darījumu veikšana pirms un pēc cietušā pirkuma un peļņas gūšana no cenu starpības.
- Oracle manipulācijas: protokola maldināšana, uzreiz mainot baseina cenu, parasti ar zibatmiņas kredītu.
Šie uzbrukumi rodas nevis no koda "kļūdas", bet gan no ekonomiskā dizaina izmantojamības. Šeit AI ir visgrūtāk: AI, kas labi skenē tehnisko kodu, bieži nevar atklāt protokolam raksturīgu ekonomisko ievainojamību.
Uzmanību: lielākā daļa DeFi ievainojamību nav "koda kļūdas", bet gan ekonomikas/biznesa loģikas ievainojamības. AI standarta koda skenēšana to izlaiž; Šī ir joma, kurā ir vajadzīgas vislielākās cilvēku zināšanas, simulācijas un modelēšana.
AI loma DeFi analīzē
1. Mehānisma apraksts. AI ir spēcīgs, lai vienkāršā valodā izskaidrotu, kā darbojas sarežģīts protokols (piemēram, uz līknes balstīta AMM). Tas nodrošina ātru iekļūšanu analīzē.
2. Scenārija/prethipotēzes ģenerēšana. "Ar kādu cenu kustību šis parāda protokols nonāks likvidācijas krīzē?" AI izstrādā scenāriju melnrakstus ar tādiem jautājumiem kā; tie tiek pārbaudīti ar simulāciju.
3. Atgādināt zināmos uzbrukuma modeļus. AI kā kontrolsaraksts atgādina iepriekšējo DeFi uzbrukumu modeļus (orākulu manipulācijas, atgriešanās, likvidācijas spirāle).
4. Simulācijas plāna projekts. AI var nākt klajā ar plānu, kurus scenārijus pārbaudīt; bet pati simulācija tiek veikta ar rīku (Foundry, Tenderly).
Vāja uzvedne / spēcīga uzvedne
Vāja uzvedne:
Vai šis DeFi protokols ir drošs?
Spēcīga uzvedne:
Jūsu loma: DeFi protokola analītiķis. Pārbaudiet tālāk norādīto protokola mehānismu. Apsveriet šādus ekonomikas uzbrukuma vektorus pa vienam: orākulu manipulācijas (ar zibatmiņas aizdevumu), sviestmaizes/priekšējā darbība, likvidācijas spirāle, likviditātes izņemšanas efekts. Katram vektoram: kā aktivizēt, kāds nosacījums ir nepieciešams, iespējamā ietekme. Šīs ir hipotēzes, kas jāpārbauda, IZMANTOJOT SIMULĀCIJU; Noteikti nesakiet "drošs/nedroši". ĢENERĒT Faktiskais uzbrukuma kods; Aprakstiet risku tikai aizsardzības nolūkos.
Četras kopējamas veidnes
1) Mehānisma apraksts:
Vienkāršā valodā soli pa solim izskaidrojiet šī protokola cenu noteikšanas/likviditātes mehānismu: kas notiek, kad lietotājs veic darījumu, kā tiek noteikta cena, kādas ir ārējās atkarības? Atzīmējiet daļu, kuru nesaprotat vai atstājat neskaidru.
2) Ekonomiskā uzbrukuma virsma:
Kartē šī protokola ekonomisko uzbrukumu virsmu: kādus pieņēmumus var izmantot orākulā, likviditātē, nodrošinājumā, likvidācijā, pārvaldībā? Uzrakstiet katru risku ar nosacījumu ("kā būtu, ja būtu"). Norādiet to kā hipotēzi, kas jāapstiprina ar simulāciju.
3) Stresa scenārijs:
Apsveriet šādus scenārijus: ja nodrošinājuma marķieris samazināsies par 50%, ja orākula cena īslaicīgi novirzās par 30%, ja tiek izņemti 80% likviditātes, kāds būs protokols? Pierakstiet katra scenārija blakusefektu. Nepretendējiet uz skaitlisko precizitāti; Norādiet, ka ir nepieciešama simulācija.
4) Vēstures uzbrukuma modeļa atbilstība:
Vai šī protokola dizains atbilst kādam no zināmajiem DeFi uzbrukuma modeļiem (piemēram, viena avota orākuls, zibatmiņas aizdevuma atvērtā cena)? Aizsardzības nolūkos norādiet līdzības; Neveiciet ekspluatācijas soli, tas tikai piesaistīs uzmanību.
Trīs mini futrāļi (skaitļos)
1. gadījums — agri pamanīts Oracle risks. Komanda izstrādāja jaunu parāda protokolu. Mehānisma skaidrojuma laikā YZ atzīmēja hipotēzi, ka "cena tiek ņemta no viena pūla un ar to var manipulēt ar zibkredītiem". Komanda to apstiprināja simulācijā un pārgāja uz TWAP + vairāku avotu izmantošanu. Aptuvenais novērstais zaudējums: visa protokola bloķētā vērtība. Mācība: AI ir vērtīga zināmu modeļu ierosināšanai.
2. gadījums — AI palaida garām sākotnējo ievainojamību. Citā protokolā ievainojamība bija unikāla ekonomiska kļūda, kas radās divu mehānismu mijiedarbības rezultātā (atlīdzība + likvidācija). AI konstatēja, ka katrs mehānisms ir "nevainojams" pa vienam; Nevarēja redzēt mijiedarbību. Uzņemts cilvēka modelētājs un simulācija. Nodarbība: lai gan komponenti ir pareizi, visa ekonomika ir AI aklā zona.
3. gadījums — simulācijas plāns ietaupīja laiku. Viens analītiķis AI izstrādāja 15 dažādus stresa scenārijus, nevis plānoja tos ar rokām; tad palaida to Foundry. Plānošana samazinājās no 1 dienas līdz 2 stundām; bet rezultātu interpretācija un lēmums bija cilvēka ziņā. Nodarbība: AI plāni, transportlīdzekļa mērījumi, cilvēks izlemj.
Simulācijas nepieciešamība
DeFi sistēmā drošība netiek pierādīta ar “domāšanu”; To pārbauda ar simulāciju. Protokola ekonomisko stabilitāti var saprast, skaitliski izpildot dažādus cenu, likviditātes un uzbrukuma scenārijus. AI var plānot un izstrādāt šo simulāciju kodu; bet tieši rīki un cilvēki rada un interpretē rezultātus. AI radītais apgalvojums "iespējams, izturīgs" nav simulācijas rezultāts, un to nevar uzrādīt kā tādu.
Padoms. Saņemot DeFi riska novērtējumu no AI, jums ir jājautā katrai hipotēzei "ar kādu simulāciju man to pārbaudīt?" Pārvērtiet to par jautājumu. Drošības prasība, ko nevar pārbaudīt, nav garantija DeFi.
Biežas kļūdas
- Ekonomiskā deficīta skenēšana kā koda kļūda. DeFi riski galvenokārt ir biznesa loģikā.
- Uzticoties AI teikt "drošs" un izlaist simulāciju. Nepieciešama pārbaude.
- Komponentu apstiprināšana pa vienam un mijiedarbības izlaišana. Visa ekonomika ir kritiska.
- Uzticoties Oracle no viena avota. Visizplatītākā DeFi katastrofa.
- MEV/front-running ignorēšana. Aizmirstot publisko mempool faktu.
- Ekspluatācijas koda ģenerēšana. Tikai aizsardzības analīze ir likumīga.
Rezumējot
- DeFi ir augstvērtīga un naidīga telpa; Riski galvenokārt ir saistīti ar ekonomikas/biznesa loģiku.
- MEV, front-running, sandwich un oracle manipulācijas ir uzbrukumu klases, kas raksturīgas DeFi.
- AI ir spēcīgs mehānismu skaidrošanā un scenāriju izstrādē; Sākotnējais ekonomikas deficīts ir vājš.
- Ekonomisko drošību pierāda simulācija, nevis domāšana; AI plāni, transportlīdzekļu pasākumi.
- Oracle atkarība ir visneaizsargātākais DeFi punkts; nepieciešami vairāki resursi un TWAP.
Lietojumprogrammas uzdevums
Izvēlieties AMM vai aizdevuma protokolu (ar skaidru dokumentāciju). Pielietojiet AI uzvednes "mehānisma apraksts" un "ekonomiskā uzbrukuma virsma". Katrai riska hipotēzei AI rada: "ar kādu simulāciju es to pārbaudītu?" Atbildi uz jautājumu. Pēc tam atrodiet šī protokola faktisko audita ziņojumu un salīdziniet faktiskos konstatējumus ar AI atzīmētajiem riskiem: ko AI noķēra, ko palaida garām?
kontrolsaraksts
- [ ] Es apspriedu riskus divās dimensijās: kods + ekonomika.
- [ ] Es novērtēju MEV/front-running.
- [ ] Es arī pārbaudīju Oracle atkarību.
- [ ] Es apšaubīju komponentu (visas ekonomikas) mijiedarbību.
- [ ] Katru hipotēzi savienoju ar simulācijas plānu.
- [ ] Es aizstāju AI "seifu" ar simulāciju.
- [ ] Es analizēju tikai aizsardzības nolūkos.