единици
1. Въведение в изкуствения интелект в блокчейн и Web3: роли, граници, удостоверяване и критичност на сигурността 2. Поддръжка за писане на интелигентни договори: Solidity/Vyper чернова и генериране на защитен код 3. Поддръжка при одит на интелигентни договори: Преглед на сигурността и чернови констатации 4. Сканиране на уязвимости: Често срещани модели на уязвимости и автоматизиран анализ 5. Анализ на данните във веригата: осмисляне на данни за блокове, транзакции и портфейли 6. Анализ на DeFi и протоколи: ликвидност, MEV и икономически атаки 7. Токеномично моделиране: доставка, разпространение, стимули и симулация 8. Документация и техническо писане: Бяла книга, NatSpec и Ръководство за потребителя 9. Измами, дърпане на килими и откриване на риск: Червени знамена във веригата 10. Критичен за безопасността одит, експертно одобрение и отговорна употреба 11. Работен процес от край до край, управление, проверка и етика
единица 6 / 11

Анализ на DeFi и протоколи: ликвидност, MEV и икономически атаки

Печалби:

  • Способност за разбиране на градивни елементи на DeFi като AMM, ликвиден пул, оракул и флаш заем и използване на изкуствен интелект при обяснение на механизми и изготвяне на сценарии
  • Да можеш да разграничиш, че повечето рискове от DeFi са уязвимости на икономическата/бизнес логиката, а не грешки в кода, и че изкуственият интелект е слаб в първоначалната икономическа уязвимост
  • Да можеш да разбереш, че икономическата сигурност се доказва чрез симулация, а не чрез мислене, и че пристрастяването към оракули е най-крехката точка.

DeFi (децентрализирани финанси) е най-ценният и най-атакуваният домейн на Web3. Борси, протоколи за кредитиране, пулове на ликвидност – всички те работят като код и всички прехвърлят милиони долари във враждебна среда. В този раздел ще използваме AI като помощник за анализ на протоколи; Ще се научим да разбираме ликвидността, цените, MEV и икономическите атаки и къде AI е полезен и неадекватен в тази контекстуална област.

Основни градивни елементи на DeFi

  • AMM (Автоматизиран маркетмейкър): Механизъм за обмен, който определя цените по формула (напр. x·y=k), вместо да съпоставя купувачи и продавачи.
  • Ликвидност: общ фонд, където потребителите депозират токени и се извършва търговия.
  • Кредитен протокол: Заем срещу обезпечение; Ликвидацията настъпва, когато стойността на обезпечението намалее.
  • Oracle: Източникът на данни, който привежда цената на външния свят към протокола — най-критичната и най-крехката зависимост на DeFi.
  • Бърз заем: Заем, взет без обезпечение в една транзакция и върнат в същата транзакция; Има както легитимни употреби, така и инструмент за атака.

MEV и икономически атаки

MEV (Максимална стойност за извличане — стойността, извлечена от органа за нареждане/добавяне/премахване на транзакции) е рисков клас, специфичен за DeFi. Чакащите транзакции се появяват в публичния пул (mempool); Тази видимост отваря вратата за следните атаки:

  • Отпред: Виждане на печеливша транзакция и вмъкване на собствена транзакция пред нея.
  • Сандвич атака: Поставяне на транзакции преди и след покупката на жертвата и печалба от разликата в цената.
  • Манипулиране на Oracle: Подвеждане на протокола чрез незабавна промяна на цената на пул, обикновено с бърз заем.

Тези атаки произтичат не от „бъга“ на кода, а от възможността за използване на икономическия дизайн. Това е мястото, където AI среща най-много трудности: AI, който е добър в сканирането на техническия код, често не може да открие икономическа уязвимост, специфична за протокола.

Внимание: Повечето уязвимости на DeFi не са „бъгове в кода“, а уязвимости на икономическата/бизнес логиката. Стандартното кодово сканиране на AI ги пропуска; Това е областта, която изисква най-много човешки опит, симулация и моделиране.

Ролята на AI в анализа на DeFi

1. Описание на механизма. AI е мощен в обяснението на прост език как работи сложен протокол (напр. базиран на крива AMM). Това осигурява бързо влизане в анализа.

2. Генериране на сценарий/контрахипотеза. „При какво движение на цените този дългов протокол ще навлезе в ликвидационна криза?“ AI създава чернови на сценарий с въпроси като; те се тестват чрез симулация.

3. Припомняне на известни модели на атака. AI извиква моделите на минали DeFi атаки (манипулация на оракул, повторно влизане, спирала за ликвидация) като контролен списък.

4. Проект на план за симулация. AI може да излезе с план за това кои сценарии да се тестват; но самата симулация се прави с инструмента (Foundry, Tenderly).

Слаба подкана / Силна подкана

Слаба подкана:

Безопасен ли е този DeFi протокол?

Мощна подкана:

Вашата роля: анализатор на DeFi протокол. Разгледайте механизма на протокола по-долу. Обмислете следните вектори на икономическа атака един по един: манипулиране на оракул (с бърз заем), сандвич/първоначално, спирала на ликвидация, ефект на изтегляне на ликвидност. За всеки вектор: как да се задейства, какво условие е необходимо, възможно въздействие. Това са хипотезите, които трябва да бъдат тествани ЧРЕЗ СИМУЛАЦИЯ; Не казвайте със сигурност „сигурно/опасно“. ГЕНЕРИРАНЕ на действителен код за атака; Опишете риска само за отбранителни цели.

Четири копируеми шаблона

1) Описание на механизма:

Обяснете на прост език, стъпка по стъпка, механизма за ценообразуване/ликвидност на този протокол: какво се случва, когато потребител направи транзакция, как се определя цената, какви външни зависимости има? Маркирайте частта, която не разбирате или оставяте неясна.

2) Повърхност за икономическа атака:

Картирайте повърхността на икономическата атака на този протокол: какви предположения могат да се използват в Oracle, ликвидност, обезпечение, ликвидация, управление? Напишете всеки риск с условие („какво ако“). Представете го като хипотеза, която трябва да бъде потвърдена чрез симулация.

3) Стрес сценарий:

Помислете за следните сценарии: ако токенът на обезпечението спадне с 50%, ако цената на оракула се отклони с 30% моментално, ако 80% от ликвидността бъде изтеглена, какъв ще бъде протоколът? Запишете страничния ефект на всеки сценарий. Не претендирайте за числена точност; Посочете, че е необходима симулация.

4) Съвпадение на модела на атака по история:

Дизайнът на този протокол отговаря ли на условията, подобни на кой от известните модели на DeFi атака (напр. оракул с един източник, отворена цена на флаш заем)? Посочете приликите за отбранителни цели; Не предприемайте стъпката на експлойт, това само ще доведе до точка на внимание.

Три мини калъфа (в брой)

Случай 1 — Рискът от Oracle, забелязан рано. Екип разработваше нов протокол за дълга. По време на обяснението на механизма YZ отбеляза хипотезата, че „цената е взета от един пул и може да бъде манипулирана с бързи заеми“. Екипът потвърди това в симулацията и премина към TWAP + мулти-източник. Очаквана избегната загуба: цялата заключена стойност на протокола. Урок: AI е ценен при извикването на известни модели.

Случай 2 — AI пропусна първоначалната уязвимост. В друг протокол уязвимостта е уникална икономическа грешка в резултат на взаимодействието на два механизма (награда + ликвидация). Изкуственият интелект намери всеки механизъм „безупречен“ един по един; Не можах да видя взаимодействието. Човешки моделатор и симулация са заснети. Урок: докато компонентите са правилни, икономиката на цялото е сляпото петно ​​на AI.

Случай 3 — Симулационният план спести време. Един анализатор начерта 15 различни сценария на стрес в AI, вместо да ги планира на ръка; след това го пуснах в леярната. Планирането намаля от 1 ден на 2 часа; но интерпретацията на резултатите и решението бяха на човека. Урок: AI планира, измерва превозното средство, решава човек.

Незаменимостта на симулацията

В DeFi сигурността не се доказва чрез „мислене“; Тества се чрез симулация. Икономическата устойчивост на един протокол може да бъде разбрана чрез числено изпълнение на различни сценарии за цена, ликвидност и атака. AI може да планира и изготви кода на тези симулации; но инструментите и хората са тези, които произвеждат и интерпретират резултатите. Изявлението „вероятно издръжлив“, произведено от AI ​​не е резултат от симулация и не може да бъде представено като такова.

Съвет: Когато получите оценка на риска за DeFi от AI, трябва да попитате всяка хипотеза „с каква симулация да тествам това?“ Превърнете го във въпрос. Твърдение за сигурност, което не може да бъде тествано, не е гаранция в DeFi.

Често срещани грешки

  • Сканиране на икономическия дефицит като кодова грешка. Рисковете за DeFi са предимно в бизнес логиката.
  • Доверете се на AI ​​да каже „безопасно“ и прескочете симулацията. Тестването е задължително.
  • Валидиране на компонентите един по един и пропускане на взаимодействие. Икономиката като цяло е критична.
  • Доверяване на Oracle от един източник. Най-често срещаната катастрофа на DeFi.
  • Игнориране на MEV/предно движение. Забравяйки факта на публичния mempool.
  • Генериране на експлойт код. Легитимен е само защитният анализ.

В обобщение

  • DeFi е високоценно и враждебно пространство; Рисковете са най-вече в икономическа/бизнес логика.
  • MEV, front-running, sandwich и oracle манипулация са класове атаки, специфични за DeFi.
  • AI е силен в обяснението на механизмите и изготвянето на сценарии; Първоначалният икономически дефицит е слаб.
  • Икономическата сигурност се доказва чрез симулация, а не чрез мислене; AI планове, мерки за превозни средства.
  • Зависимостта от Oracle е най-уязвимата точка на DeFi; необходими са множество ресурси и TWAP.

Задача за приложение

Изберете AMM или протокол за заемане (с ясна документация). Приложете подканите „описание на механизма“ и „повърхност за икономическа атака“ към AI. За всяка рискова хипотеза, която AI произвежда, „с каква симулация бих тествал това?“ Отговорете на въпроса. След това намерете действителния одитен доклад на този протокол и сравнете действителните констатации с рисковете, отбелязани от AI: Какво е хванал AI, какво е пропуснал?

контролен списък

  • [ ] Обсъдих рисковете в две измерения: код + икономика.
  • [ ] Оцених MEV/преден ход.
  • [] Проучих също зависимостта от Oracle.
  • [ ] Поставих под въпрос взаимодействието на компонентите (цялата икономика).
  • [ ] Свързах всяка хипотеза със симулационен план.
  • [ ] Замених „сейфа“ на AI със симулация.
  • [ ] Анализирах само за отбранителни цели.