Aave збирається обмежити високоризиковани активи у V3, V4 та Horizon

Aave збирається обмежити високоризиковани активи у V3, V4 та Horizon

2026/06/02 15:55:00
Кастомне зображення
Декентралізована фінансова сфера переживає масштабний зсув парадигми, оскільки провідні протоколи позичання пріоритезують довгострокову економічну стійкість над короткостроковими надходженнями ліквідності. Як провідна глобальна криптовалютна біржа, така як KuCoin, ми уважно стежимо за цими безпековими змінами інституційного рівня, щоб допомогти нашим користувачам орієнтуватися в змінних ринкових умовах. Останній фреймворк зменшення ризиків Aave позначає визначальний поворотний момент у декентралізованому управлінні активами та запобіганні неплатоспроможності протоколу.
Це всебічний огляд активів Aave V3 V4, який досліджує, як протокол збирається виявляти, класифікувати та обмежувати високоризиковани токени в своїх поточних та майбутніх пулів позичання.

Основні висновки

  • Зміна парадигми: Aave активно зміщує свою основну оцінку ризиків з зовнішньої волатильності ринку та показників ліквідності на внутрішні, приховані технічні ризики смартконтрактів.
  • Стандартизовані критерії: Новопропонований процес перевірки активів передбачає нульову толерантність до нестандартних ERC-20 токенів, неперевірених оракулів цін та надмірних адміністративних прав.
  • Вплив на протокол: Суворі обмеження активів одночасно застосовуватимуться до існуючих пулів Aave V3, майбутніх розгортань Aave V4 та дуже очікуваної архітектури Aave Horizon, спрямованої на інституційних учасників.
  • Захисні обмеження: Несумісні активи підлягають негайним захисним діям, включаючи агресивне зменшення коефіцієнтів кредит-до-вартості (LTV), зниження лімітів надання або повну відмову у прийнятті.

Перехід від ринкових ризиків до технічних ризиків

Роками децентралізовані платформи позичання оцінювали ризики виключно з фінансової точки зору, аналізуючи історичну волатильність, середній щоденний обсяг торгівлі та ринкову капіталізацію. Хоча ці метрики ефективно зменшують ланцюгову ліквідацію під час стандартних ринкових спадів, вони не впоруються зі складними експлойтами смартконтрактів. Оновлена рамка Aave передбачає агресивний зсув у бік виявлення вразливостей у коді до того, як актив може бути використаний як забезпечення.

Що таке приховані технічні ризики?

Приховані технічні ризики — це структурні аномалії, вбудовані безпосередньо в код смартконтракту токена, які змінюють його поведінку за певних умов. На відміну від ринкових ризиків, які видно через публічну книгу ордерів і діаграми глибини біржі, технічні ризики залишаються неактивними, доки їх не активує експлойт або маніпуляція з боку управління. Прикладами є нестандартні функції переказу, приховані шаблони оновлення без таймлоків та недокументовані зовнішні залежності. Ці приховані вразливості можуть дозволити зловмисникам штучно маніпулювати балансами або висмоктувати ліквідність незалежно від того, наскільки «ліквідним» здається актив на публічних ринках.

Чому слабкості коду загрожують платоспроможністю

Коли позичальник робить депозит активу на біржі або платформі позичання, такій як Aave, протокол припускає, що механізми постачання та переказу цього активу є детермінованими і незмінними. Одна критична слабкість у коді може повністю зруйнувати це припущення, що призведе до катастрофічного неплатоспроможного стану протоколу. Якщо токен забезпечення містить вразливість, яка дозволяє довільне створення токенів або маніпуляцію балансом, нападник може створити нескінченну кількість забезпечення з нізвідки. Потім вони можуть використовувати цей підроблений актив для позичання легітимних, високоліквідних активів, таких як USDC або ETH, залишаючи протокол з безцінними, експлуатованими токенами та незабезпеченим боргом.

Обмеження традиційних даних ланцюга

Традиційний аналіз on-chain даних є відставаючим індикатором, зосереджуючись на минулій продуктивності, концентрації гаманців та історичній ліквідності DEX. Хоча ці метрики корисні для виявлення ризиків маніпулювання ринком, вони не бачать експлойтів смартконтрактів нульового дня та раптових зловмисних оновлень управління. Токен може мати ідеальний on-chain профіль з мільйонами доларів заблокованої ліквідності та тисячами унікальних власників, але все ще мати катастрофічну вразливість у своєму коді. Нова парадигма Aave визнає, що залежність виключно від історичних транзакційних даних створює хибне відчуття безпеки, що вимагає всебічного аудиту на рівні коду.

Основні критерії оцінки активів Aave V3 V4

Щоб систематично усунути технічні вразливості, Aave впроваджує строгий, стандартизований інструмент оцінки, призначений для виявлення аномалій активів. Цей структурований підхід є фундаментальною основою для перевірки активів Aave V3 V4, забезпечуючи, щоб кожен підтримуваний токен відповідав жорстким стандартам безпеки.
Критерії перевірки Цільова фокусировка Прийнятний стандарт
Відповідність ERC-20 Структура коду токена Строга відповідність EIP-20 без побічних ефектів
Регулювання хуків Зміни стану під час переказу Повний заборона на довільні зовнішні виконання
Надійність Oracle Безпека стрічки цін Надлишкові децентралізовані потоки з резервними шляхами
Підвищення привілеїв Адміністративний контроль та мультипідписи Класифікація з рівня 0 до рівня 2
Інфляція пропозиції Дозволи на мінтинг Жорстко закодовані великі літери або багатопідписові часові блокування
Підтримка аудиту Життєвий цикл смартконтракту Регулярні, незалежні, зовнішні перевірки коду

Строгі правила сумісності з ERC-20

Стандарт ERC-20 був розроблений для забезпечення безперебійної сумісності в екосистемі Ethereum, але багато сучасних токенів відхиляються від його основних специфікацій, щоб реалізувати користувацькі функції. Оновлений процес перевірки Aave встановлює непохитну позицію щодо токенів, які використовують нестандартні реалізації, такі як дефляційні комісії за переказ, механізми rebasing або подвійні баланси токенів. Токени, які зменшують комісію під час переказу, спотворюють внутрішнє облікове ведення протоколу, викликаючи розбіжності між зареєстрованими балансами та фактичними токенами, що зберігаються у смартконтракті. Внаслідок цього будь-який актив, який не точно відтворює стандартну поведінку переказу EIP-20, буде заборонений до інтеграції.

Блокування хуків токенів для безпеки

Хуки токенів, поширені стандартами, такими як ERC-777 та певними користувацькими розширеннями ERC-20, дозволяють контракту токена повідомляти зовнішні адреси про будь-які перекази. Хоча ця функція дозволяє реалізовувати складні програмні шаблони, вона створює величезний вектор атаки, відомий як вразливість до повторного виклику. Під час атаки повторного виклику зловмисний контракт перехоплює хук переказу та виконує другу, неавторизовану транзакцію, перш ніж протокол позичання зможе оновити свої внутрішні баланси. Щоб забезпечити абсолютну безпеку протоколу, Aave вводить повний заборону на будь-який колатеральний актив, що використовує довільні хуки переказу або зворотні виклики.

Обов’язкова надійність оракула цін

Децентралізована платформа позичання є лише настільки безпечною, наскільки надійними є цінові дані, що визначають її пороги ліквідації. Aave вимагає, щоб кожен актив мав надзвичайно надійну, високо децентралізовану архітектуру оракула цін, яка в основному використовує Chainlink, а також передбачає надійні вторинні системи резервування.
Конфігурації Oracle повинні демонструвати виняткову стійкість до маніпуляцій цінами за допомогою флеш-позичок, спотворень через прослизання при низькій ліквідності та затримок доставки даних. Якщо актив залежить від одного джерела децентралізованої біржі (DEX) для визначення ціни, він буде миттєво дискваліфікований через простоту тимчасового маніпулювання такими пулами.

Оцінка привілейованих ролей (рівень 0-5)

Щоб зменшити ризики централізації, Aave класифікує керування та адміністративні контролі кандидатських токенів за строгим масштабом рівнів від 0 до 5. Рівень 0 означає повну незмінність або розподіл автоматизованому, з блокуванням за часом DAO, тоді як рівень 5 вказує на один єдиний зовнішній акаунт (EOA) без блокування за часом з абсолютною владою.
  • Рівень 0: Повністю незмінний код або децентралізований контроль DAO з довгими таймлоками.
  • Рівень 1: Багатопідписовий контроль із мінімальним 72-годинним публічним таймлоком для всіх функцій.
  • Рівень 2: Багатопідписовий контроль з короткими таймлоками, обмежений змінами не критичних параметрів.
  • Рівень 3: Централізована команда з багатопідписовим доступом, здатна призупиняти або оновлювати контракти без таймлоку.
  • Рівень 4: Один EOA або розробницький гаманець з можливістю оновлення або призупинення контракту.
  • Рівень 5: Один EOA з необмеженим доступом до балансів користувачів, мінтингу або перезапису коду.
За новими напрямками активи з профілем ризику рівня 3 або вище будуть підлягати суворим обмеженням або повній виключенню з рівнів забезпечення протоколу.

Аудит функцій безмежного створення монет

Токени, які мають механізми створення на основі, становлять екзистенційну загрозу для кредитних протоколів, якщо ключі створення скомпрометовано або використано неправильно. Команда з ризиків Aave проводить глибокий аналіз коду, щоб відобразити кожну адресу, смартконтракт та мультипідпис, здатний викликати функцію створення. Якщо проект зберігає необмежену здатність до створення без прозорих, жорстко закодованих обмежень пропозиції або строгих криптографічних бар’єрів мультипідпису, його не можна вважати надійним забезпеченням. Протокол негайно позначить ці активи, забезпечуючи, що несподівана інфляція пропозиції не зможе знизити вартість активу до нуля за одну ніч.

Постійні аудити безпеки смартконтрактів

Одна лише перевірка безпеки, проведена при запуску токена, більше не є достатньою в екосистемі, що характеризується швидкими оновленнями та змінними векторами атак. Aave тепер вимагає, щоб випускники активів надавали підтвердження постійних, неперервних перевірок безпеки смартконтрактів, проведених авторитетними, незалежними сторонніми фірмами. Коли проект активу проходить оновлення коду, міграцію або структурну зміну своєї екосистеми, необхідно подавати новий аудиторський ланцюжок. Невиконання вимоги зберігати актуальну та прозору історію незалежних перевірок коду спричинить автоматичну переоцінку рівня ризику активу в екосистемі Aave.

Сектори з обмеженнями: V3, V4 та Horizon

Застосування цих підвищених стандартів безпеки вплине на кілька ключових секторів у сфері децентралізованої фінансовості. Суворі напрями, викладені у огляді активів Aave V3 V4, суттєво вплинуть на три основні складові екосистеми Aave: вже існуючі пули V3, майбутні ринки V4 та спеціалізовану інституційну архітектуру позичання, відому як Aave Horizon.

Перевірка постачання моста між ланцюгами

Міжблокчейн-мостовані активи, обгорнуті токени та синтетичні варіанти є одними з найбільш цільових та експлуатованих векторів у сучасній історії децентралізованої фінансової системи. Коли актив мостується з його нативного блокчейну на іншу мережу, його безпека повністю залежить від базової інфраструктури смартконтрактів моста. Aave впроваджує всебічний процес перевірки всіх обгорнутих та мостованих активів у своїх пулах V3, уважно аналізуючи історичну доступність моста, структуру мультипідпису та децентралізацію валідаторів. Активи, забезпечені хрупкою, централизованою або часто змінюваною архітектурою моста, отримають агресивно обмежені ліміти пропозиції для ізоляції потенційного міжблокчейн-зараження.

Більш щільне затягування на ризикованих LRT

Рідкісні токени рестейкінгу (LRT) привели до притоку мільярдів доларів капіталу, але їхня гіперкомпозиція вводить складні шари системного ризику. LRT представляє вимогу на стейканий ETH, який подальше переадресовується для забезпечення різних активно валідованих сервісів (AVS), створюючи довгий ланцюг технічних залежностей. Aave V4 підсилює контроль над цим сектором, аналізуючи підlying ризики слешингу, централізацію операторів нод та затримки з виведенням ліквідності, пов’язані з кожним LRT. LRT, які підтримують невстановлені AVS з неаудитованими контрактами слешингу, зазнають негайного обмеження позичання та значного зменшення корисності колатералу для захисту основного протоколу від масового слешингу.

Aave Horizon: Суворі аудити RWA

Aave Horizon — це стратегічне розширення протоколу в секторі активів реального світу (RWA), створення окремих, строго регульованих пулів, призначених для інституційного капіталу. Оскільки RWA з’єднують розподілені смартконтракти з традиційною фізичною інфраструктурою, вони вимагають фундаментально іншого підходу до аудиту.
Кожен актив RWA, що підключається до Aave Horizon, повинен пройти детальний огляд контрактів токенізації, щоб забезпечити, що функції чорного списку та заморожування не можуть бути зловжиті зовнішніми учасниками.

Перевірка поза ланцюгових правових рамок

Поза стандартними аудитами коду, сектор RWA вимагає абсолютної перевірки базових позачергових правових суб’єктів, інструментів, ізольованих від банкрутства, та механізмів зберігання колатералу. Якщо токен RWA представляє токенізований казначейський білеть США або нерухомість, правові засоби захисту, доступні DAO у випадку дефолту, повинні бути абсолютно ясними. Рамки управління ризиками Aave вимагають, щоб емітенти надавали незаперечні правові думки, які детально пояснюють, як захищаються права власності, грошові потоки або боргові зобов’язання у традиційних судах. Будь-який актив, правова база якого позачергово є нечіткою, погано структурованою або зареєстрованою у непідкорювальній юрисдикції, буде повністю заборонений у екосистемі Horizon.

Наслідки для несумісних активів

Токени, які зараз перелічені або прагнуть до включення, але не відповідають цим суворим параметрам, підлягатимуть негайним програмним дисциплінарним заходам. Мета — не покарати конкретні проекти, а динамічно захистити загальні ліквідні пули від потенційних помилок у коді, системних експлойтів або атак на рівні управління.

Зменшення лімітів пропозиції та позичання

Першим захистом проти структурно підозрілого активу є негайне зменшення лімітів поставок і позичання для цього активу у всіх активних пулів позичання. Знижуючи ліміт поставок, Aave обмежує загальну суму конкретного токена, яку можна депонувати в протокол, ефективно обмежуючи загальну експозицію. Одночасно зменшення ліміту позичання запобігає користувачам утворювати величезні короткі позиції або використовувати цей токен для вилучення чистої ліквідності з платформи. У серйозних випадках, коли підозрюється наявність технічної вразливості, ліміти поставок і позичання зменшуються безпосередньо до нуля, блокуючи будь-яку подальшу експозицію протоколу.

Обмеження параметрів співвідношення позики до вартості

Параметри співвідношення позики до вартості (LTV) визначають, яку саме суму капіталу користувач може позичити під свої депоновані забезпечення. Наприклад, LTV 80% означає, що користувач, який депонує активи на суму $100, може позичити до $80 іншої криптовалюти.
LTV = \left( \frac{\text{Максимальна сума позики}}{\text{Вартість наданого забезпечення}} \right) \times 100\%
Для нещодобрих або високоризикованих активів, виявлених у ході огляду, Aave програмно знизить коефіцієнт LTV, іноді знижуючи його до 0%. Зниження LTV до 0% повністю позбавляє токен його функції забезпечення, змушуючи користувачів розглядати його виключно як ізольований, непозичальний актив і запобігаючи його використанню як забезпечення для системних боргів протоколу.

Затримані запуски та відмови у прийнятті активів

Для активів, які проходять через процес управління або очікують розгортання в майбутніх екосистемах V4 та Horizon, невідповідність призводить до негайних затримок запуску або постійної відмови. Ядро ризиків протоколу надасть детальні технічні звіти з описом точних змін у коді, покращень оракулів або правових уточнень, необхідних для відповідності. Актив залишиться замороженим у черзі на підключення, доки незалежні компанії з безпеки не підтвердять, що всі технічні попередження були повністю усунені. Ця проактивна перевірка забезпечує зупинку високоризикованих технічних боргів на порозі протоколу, набагато раніше, ніж вони зможуть загрожувати капіталу користувачів.

Висновок

Зі зрілістю децентралізованого фінансу як глобально визнаної фінансової основи, безпека протоколів повинна еволюціонувати від реактивного керування кризами до проактивного ізоляції ризиків. Вирішальний перехід Aave до аналізу глибоких технічних і структурних ризиків коду у V3, V4 та Horizon встановлює мірку для всього індустрії. Реалізуючи це всебічне оцінювання активів Aave V3 V4 та застосовуючи незмінні стандарти щодо сумісності коду ERC-20, стійкості оракулів та юридичної прозорості, протокол ефективно імунізує себе від системного неплатоспроможності. Як провідна криптовалютна біржа, така як KuCoin, ми активно підтримуємо ці жорсткі рамки безпеки, які в кінцевому підсумку сприяють безпечнішому та передбачуванішому середовищу торгівлі та позичання для всіх учасників цифрових активів.

ЧАСТІ ПИТАННЯ

Яка є основна мета останнього огляду активів Aave V3 V4?

Основна мета огляду активів Aave V3 V4 полягає в систематичному переході фокусу оцінки ризиків протоколу від стандартних показників ринкової волатильності до глибокого аналізу технічних вразливостей смартконтрактів для запобігання експлуатації протоколу та неплатоспроможності через просрочені борги.

Чому Aave вводить обмеження для рідких токенів рестейкінгу (LRT)?

Aave вводить жорсткіші обмеження на LRT через їх складні шари системного ризику, включаючи потенційні вразливості повторного входу смартконтрактів, неперевірені параметри знищення валідаторів та затримки ліквідності, що загрожують ліквідаціям під час зниження ринку.

Як Aave Horizon забезпечує управління ризиками реальних активів (RWA)?

Aave Horizon проводить строгі, інституційні аудити RWA, які оцінюють як код смартконтракту токенізації, так і базові позачасові правові рамки, забезпечуючи безпечне розміщення активів від банкрутства та чіткі правові засоби захисту для протоколу.

Що відбувається з токеном, якщо його коефіцієнт кредитної забезпеченості (LTV) зменшується до 0%?

Коли LTV токена зменшується до 0%, він повністю втрачає свою корисність як забезпечення на платформі, що означає, що користувачі більше не можуть позичити будь-які інші цифрові активи під свої депоновані баланси цього конкретного токена.

Чи може актив бути знову доданий після відмови від нової системи ризиків Aave?

Так, актив може бути знову розглянутий для лістингу, коли розробницька команда повністю виправить виділені технічні ризики, пройде наступні аудити безпеки смартконтракту та успішно повторно подасть актив на формальний огляд.

Відмова від відповідальності: Для вашої зручності цю сторінку було перекладено за допомогою технології ШІ (на базі GPT). Для отримання найточнішої інформації дивіться оригінальну англійську версію.