Подвійний характер механізму Hook Uniswap v4: інновації та потенційні ризики
Uniswap v4 незабаром буде запущений, це оновлення дійсно амбіційне. Нова версія впровадить безліч нових функцій, включаючи підтримку безкінечно великої кількості ліквіднісних пулів для кожної торговельної пари та динамічні комісії, однократний дизайн, миттєве бухгалтерське обліку, механізм Hook, а також підтримку стандарту токенів ERC1155. Завдяки технології транзитного зберігання, Uniswap v4 очікується після оновлення Ethereum Cancun.
Серед численних інновацій механізм Hook привертає увагу через свій великий потенціал. Цей механізм дозволяє виконувати користувацький код у певних точках життєвого циклу ліквідного пулу, значно підвищуючи масштабованість і гнучкість пулу.
Однак механізм Hook може бути і двосічним мечем. Незважаючи на потужність і гнучкість, безпечне використання Hook також стикається з досить серйозними викликами. Складність Hook неминуче призводить до нових потенційних векторів атак. Тому важливо систематично представити питання безпеки та потенційні ризики, пов'язані з механізмом Hook, для сприяння безпечному розвитку спільноти; ці висновки допоможуть у створенні більш безпечного Uniswap v4 Hook.
У цій статті будуть представлені пов'язані з механізмом Hook концепції в Uniswap v4 та огляд їхніх існуючих ризиків безпеки.
Механізм Uniswap V4
Перед тим, як заглибитися в обговорення, нам потрібно мати базове уявлення про механізми Uniswap v4. Згідно з офіційним оголошенням та білому аркуші, Hook, одностороння архітектура та миттєвий облік є трьома важливими функціями для реалізації налаштованих ліквідних пулів та ефективного маршрутизації через кілька пулів.
1.1 Гачок
Hook означає контракти, що працюють на різних етапах життєвого циклу ліквідних пулів. Команда Uniswap сподівається, що, впроваджуючи Hook, будь-хто зможе приймати зважені рішення. Такий підхід дозволяє реалізувати нативну підтримку динамічних зборів, додавання обмежених ордерів на блокчейні або здійснення ринкового створення цін через середнє зважене за часом (TWAMM) для розподілу великих замовлень.
Наразі є вісім зворотних викликів Hook, поділених на чотири групи (, кожна група містить одну пару зворотних викликів ):
передІніціалізацією/післяІніціалізації
передЗміноюПозиції/післяЗміниПозиції
перед обміном/після обміну
передПожертвуванням/післяПожертвування
Команда Uniswap надала кілька прикладів (, таких як TWAMM Hook ), що описує методи роботи, а учасники спільноти також зробили деякі внески. Офіційна документація також містить посилання на репозиторій Awesome Uniswap v4 Hooks, який зібрав більше прикладів Hook.
1.2 Одиночний, блискавична бухгалтерія та механізм блокування
Архітектура синглтона та блискавична бухгалтерія спрямовані на підвищення продуктивності шляхом зниження витрат і забезпечення ефективності. Вона вводить новий контракт синглтона, у якому всі ліквідні пулі зберігаються в одному й тому ж смарт-контракті. Цей дизайн синглтона покладається на PoolManager для зберігання та управління станом усіх пулів.
Версія Uniswap v4 впроваджує механізми миттєвого обліку та блокування. Механізм блокування працює наступним чином:
контракт locker запитує lock на PoolManager.
PoolManager додає адресу цього контракту locker до черги lockData та викликає його зворотний виклик lockAcquired.
контракт locker виконує свою логіку під час зворотного виклику. Під час виконання взаємодія контракту locker з пулом може призвести до ненульового збільшення валюти. Але у кінці виконання всі збільшення повинні бути врегульовані до нуля. Крім того, якщо черга lockData не пуста, лише останній контракт locker може виконувати операцію.
PoolManager перевіряє стан черги lockData та збільшення валюти. Після перевірки PoolManager видалить цей контракт locker.
Отже, механізм блокування запобігає одночасному доступу і забезпечує, щоб усі транзакції могли бути завершені. Контракт locker запитує lock у порядку, а потім виконує транзакцію через зворотний виклик lockAcquired. Перед і після кожної операції в пулі спрацьовують відповідні зворотні виклики Hook. Нарешті, PoolManager перевіряє стан.
Цей метод означає, що операції коригують внутрішній чистий баланс (, тобто delta ), а не виконують миттєвий переказ. Будь-які зміни будуть зафіксовані в внутрішньому балансі пулу, а фактичний переказ буде здійснено після завершення операції (, тобто lock ). Цей процес гарантує, що немає незакритих токенів, тим самим підтримуючи цілісність коштів.
Через механізм блокування зовнішні всі рахунки (EOA) не можуть безпосередньо взаємодіяти з PoolManager. Натомість будь-яка взаємодія повинна проходити через контракт. Цей контракт виступає як проміжний блокувальник, і перед виконанням будь-яких операцій з пулом потрібно запитати блокування.
Існує два основних сценарії взаємодії з контрактами:
контракт locker походить з офіційної кодової бази або розгортається користувачем. Цю ситуацію можна вважати взаємодією через маршрутизатор.
контракт locker інтегровано з Hook в один і той же контракт або контролюється третіми сторонами. Цю ситуацію можна розглядати як взаємодію через Hook. У цей момент Hook виконує роль контракту locker і відповідає за обробку зворотного виклику.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
Модель загроз
Перед обговоренням відповідних питань безпеки, нам потрібно визначити модель загроз. Основна увага приділяється двом основним випадкам:
Модель загрози I: Hook сам по собі є добрим, але має вразливості.
Модель загрози II: Сам Hook є шкідливим.
Далі буде обговорено потенційні проблеми безпеки на основі цих двох моделей загрози.
2.1 Проблеми безпеки в моделі загроз I
Модель загроз I зосереджується на вразливостях, пов'язаних із самим Hook. Ця модель загроз припускає, що розробники та їх Hook є беззлобними. Однак наявні відомі вразливості смарт-контрактів також можуть з'явитися в Hook. Наприклад, якщо Hook реалізовано як оновлювальний контракт, він може зіткнутися з проблемами, подібними до вразливостей UUPSUpgradeable від OpenZeppelin.
Враховуючи наведені вище фактори, ми вибрали зосередитися на потенційних вразливостях, характерних для версії v4. У Uniswap v4 Hook - це смарт-контракт, який може виконувати користувацьку логіку до або після виконання основних операцій у пулі (, включаючи ініціалізацію, зміну позиції, обмін та збір ). Хоча очікується, що Hook реалізує стандартний інтерфейс, він також дозволяє включати користувацьку логіку. Тому наше обговорення буде обмежене логікою, що стосується стандартного інтерфейсу Hook. Потім ми спробуємо виявити можливі джерела вразливостей, наприклад, як Hook може зловживати цими стандартними функціями Hook.
Конкретно, ми зосередимося на наступних двох типах Hook:
Перший тип хуку, зберігання коштів користувача. У цьому випадку зловмисник може атакувати цей хук, щоб перевести кошти, що призведе до втрати активів.
Другий тип hook, зберігає критично важливі дані про стан, які залежать від користувача або інших протоколів. У цьому випадку зловмисник може спробувати змінити критично важливий стан. Коли інші користувачі або протоколи використовують неправильний стан, це може призвести до потенційного ризику.
Будь ласка, зверніть увагу, що гачки поза цими двома діапазонами не входять до нашої дискусії.
Після детального вивчення репозиторію Awesome Uniswap v4 Hooks ми виявили кілька серйозних вразливостей. Ці вразливості в основному виникають через ризикову взаємодію між hook, PoolManager та зовнішніми третіми сторонами, і їх можна поділити на два основних типи: проблеми з контролем доступу та проблеми з валідацією введення.
Загалом, ми виявили 22 відповідні проекти (, виключаючи проекти, які не стосуються Uniswap v4 ). Серед цих проектів ми вважаємо, що 8 з (36%) проектів мають вразливості. У цих 8 вразливих проектах 6 мають проблеми з контролем доступу, 2 можуть бути піддані ненадійним зовнішнім викликам.
2.1.1 Проблеми контролю доступу
У цій частині обговорення ми головним чином зосереджуємося на проблемах, які можуть виникнути через функції зворотного виклику в v4, включаючи 8 хуків зворотного виклику та зворотний виклик lock. Звичайно, є й інші ситуації, які потрібно перевірити, але ці ситуації різняться за дизайном і наразі не є предметом нашого обговорення.
Ці функції можуть бути викликані лише PoolManager, а не іншими адресами (, включаючи EOA та контракт ). Наприклад, у випадку, коли винагорода розподіляється за допомогою ключа пулу, якщо відповідні функції можуть бути викликані будь-яким рахунком, то винагорода може бути помилково отримана.
Отже, для hook важливо створити надійний механізм контролю доступу, особливо враховуючи те, що до них можуть звертатися інші сторони, окрім самого пулу. Суворе управління правами доступу може значно знизити ризики, пов'язані з несанкціонованою або зловмисною взаємодією з hook.
2.1.2 Проблема верифікації введення
У Uniswap v4, через наявність механізму блокування, користувачі повинні отримати lock через контракт перед виконанням будь-яких операцій з пулом ліквідності. Це гарантує, що контракт, який зараз взаємодіє, є останнім контрактом-локером.
Незважаючи на це, все ще існує можливий сценарій атаки, що виникає внаслідок неналежної перевірки вхідних даних в деяких вразливих реалізаціях Hook, що призводить до ненадійних зовнішніх викликів:
По-перше, hook не перевіряє, з яким пулом активів користувач має намір взаємодіяти. Це може бути шкідливий пул активів, що містить фальшиві токени та виконує шкідливу логіку.
По-друге, деякі ключові функції hook дозволяють будь-які зовнішні виклики.
Ненадійні зовнішні виклики надзвичайно небезпечні, оскільки вони можуть призвести до різних видів атак, включаючи нам відомі атаки повторного входу.
Щоб атакувати ці вразливі hook, зловмисник може зареєструвати власний зловмисний пул коштів для своїх фальшивих токенів, а потім викликати hook для виконання операцій у пулі коштів. Під час взаємодії з пулом коштів логіка зловмисного токена захоплює контрольний потік для вчинення неналежних дій.
2.1.3 Заходи протидії загрозам моделі I
Щоб уникнути таких проблем із безпекою, пов'язаних із hook, важливо здійснювати перевірку взаємодії шляхом належного виконання необхідного контролю доступу до чутливих зовнішніх/публічних функцій та валідації вхідних параметрів. Крім того, захист від повторних викликів може допомогти забезпечити, щоб hook не виконувався повторно в стандартному логічному потоці. Впроваджуючи належні заходи безпеки, пул коштів може зменшити ризики, пов'язані з такими загрозами.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
2.2 Проблеми безпеки в моделі загрози II
У цій моделі загрози ми припускаємо, що розробники та їхні хуки є зловмисними. Оскільки обсяг охоплення є досить широким, ми зосереджуємося лише на питаннях безпеки, пов'язаних з версією v4. Отже, ключовим є те, чи можуть надані хуки обробляти криптоактиви, які користувач переводить або авторизує.
Оскільки метод доступу до hook визначає можливі дозволи, які можуть бути надані hook, ми розділили hook на два типи:
Управлінські хуки(: hook не є точкою входу. Користувачі повинні взаємодіяти з hook через маршрутизатор), який може бути наданий Uniswap(.
Незалежні гачки)Standalone Hooks(: гачок є точкою входу, що дозволяє користувачам безпосередньо взаємодіяти з ним.
)# 2.2.1 Хостингова форма Hook
У цьому випадку криптоактиви користувача ### включають нативні токени та інші токени (, які передаються або надаються маршрутизатору. Оскільки PoolManager виконує перевірку балансу, зловмисному hook важко безпосередньо вкрасти ці активи. Однак, все ще існує потенційна вразливість для атак. Наприклад, механізм управління комісіями версії v4 може бути маніпульований зловмисником через hook.
)# 2.2.2 незалежний Hook
Коли Hook використовується як точка входу, ситуація стає ще складнішою. У цьому випадку, оскільки користувачі можуть безпосередньо взаємодіяти з hook, hook отримує більше влади. Теоретично, hook може виконувати будь-яку бажану операцію через цю взаємодію.
У версії v4 перевірка логіки коду є надзвичайно важливою. Основна проблема полягає в тому, чи можна маніпулювати логікою коду. Якщо hook є оновлювальним, це означає, що, здавалося б, безпечний hook може стати шкідливим після оновлення, що становить значний ризик. До цих ризиків належать:
Можливий до оновлення агент ### може бути безпосередньо атакований (;
Має логіку самознищення. Може бути атаковане в разі спільного виклику selfdestruct та create2.
)# 2.2.3 Заходи проти моделі загроз II
Ключовим моментом є оцінка того, чи є hook шкідливим. Зокрема, для хостингових hook ми повинні звертати увагу на поведінку управління витратами; тоді як для незалежних hook основна увага приділяється їх можливості оновлення.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ]###https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053fb97876f16(
Висновок
У цій статті спочатку коротко описуються основні механізми, пов'язані з проблемами безпеки Hook у Uniswap v4. Потім ми пропонуємо дві моделі загрози та коротко викладаємо пов'язані з ними ризики безпеки.
У наступних статтях ми проведемо детальний аналіз проблем безпеки в кожній моделі загрози.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
5
Поділіться
Прокоментувати
0/400
OfflineValidator
· 07-31 11:18
Потрібно ще зрозуміти V4
Переглянути оригіналвідповісти на0
MetaMisery
· 07-30 04:35
Ще не так стабільно, як v3, знову хочуть погратися з концепцією?
Переглянути оригіналвідповісти на0
SatoshiNotNakamoto
· 07-30 04:24
Чекаю, коли з'являться баги v4
Переглянути оригіналвідповісти на0
TokenGuru
· 07-30 04:17
Старий проект у новій версії, невдахи, які сліпо приєднуються, знову зазнають удару
Переглянути оригіналвідповісти на0
SigmaValidator
· 07-30 04:16
Зрозумів, ця яма - непогана можливість для шортити.
Аналіз безпеки механізму Hook Uniswap v4: інновації та ризики
Подвійний характер механізму Hook Uniswap v4: інновації та потенційні ризики
Uniswap v4 незабаром буде запущений, це оновлення дійсно амбіційне. Нова версія впровадить безліч нових функцій, включаючи підтримку безкінечно великої кількості ліквіднісних пулів для кожної торговельної пари та динамічні комісії, однократний дизайн, миттєве бухгалтерське обліку, механізм Hook, а також підтримку стандарту токенів ERC1155. Завдяки технології транзитного зберігання, Uniswap v4 очікується після оновлення Ethereum Cancun.
Серед численних інновацій механізм Hook привертає увагу через свій великий потенціал. Цей механізм дозволяє виконувати користувацький код у певних точках життєвого циклу ліквідного пулу, значно підвищуючи масштабованість і гнучкість пулу.
Однак механізм Hook може бути і двосічним мечем. Незважаючи на потужність і гнучкість, безпечне використання Hook також стикається з досить серйозними викликами. Складність Hook неминуче призводить до нових потенційних векторів атак. Тому важливо систематично представити питання безпеки та потенційні ризики, пов'язані з механізмом Hook, для сприяння безпечному розвитку спільноти; ці висновки допоможуть у створенні більш безпечного Uniswap v4 Hook.
У цій статті будуть представлені пов'язані з механізмом Hook концепції в Uniswap v4 та огляд їхніх існуючих ризиків безпеки.
Механізм Uniswap V4
Перед тим, як заглибитися в обговорення, нам потрібно мати базове уявлення про механізми Uniswap v4. Згідно з офіційним оголошенням та білому аркуші, Hook, одностороння архітектура та миттєвий облік є трьома важливими функціями для реалізації налаштованих ліквідних пулів та ефективного маршрутизації через кілька пулів.
1.1 Гачок
Hook означає контракти, що працюють на різних етапах життєвого циклу ліквідних пулів. Команда Uniswap сподівається, що, впроваджуючи Hook, будь-хто зможе приймати зважені рішення. Такий підхід дозволяє реалізувати нативну підтримку динамічних зборів, додавання обмежених ордерів на блокчейні або здійснення ринкового створення цін через середнє зважене за часом (TWAMM) для розподілу великих замовлень.
Наразі є вісім зворотних викликів Hook, поділених на чотири групи (, кожна група містить одну пару зворотних викликів ):
Команда Uniswap надала кілька прикладів (, таких як TWAMM Hook ), що описує методи роботи, а учасники спільноти також зробили деякі внески. Офіційна документація також містить посилання на репозиторій Awesome Uniswap v4 Hooks, який зібрав більше прикладів Hook.
1.2 Одиночний, блискавична бухгалтерія та механізм блокування
Архітектура синглтона та блискавична бухгалтерія спрямовані на підвищення продуктивності шляхом зниження витрат і забезпечення ефективності. Вона вводить новий контракт синглтона, у якому всі ліквідні пулі зберігаються в одному й тому ж смарт-контракті. Цей дизайн синглтона покладається на PoolManager для зберігання та управління станом усіх пулів.
Версія Uniswap v4 впроваджує механізми миттєвого обліку та блокування. Механізм блокування працює наступним чином:
контракт locker запитує lock на PoolManager.
PoolManager додає адресу цього контракту locker до черги lockData та викликає його зворотний виклик lockAcquired.
контракт locker виконує свою логіку під час зворотного виклику. Під час виконання взаємодія контракту locker з пулом може призвести до ненульового збільшення валюти. Але у кінці виконання всі збільшення повинні бути врегульовані до нуля. Крім того, якщо черга lockData не пуста, лише останній контракт locker може виконувати операцію.
PoolManager перевіряє стан черги lockData та збільшення валюти. Після перевірки PoolManager видалить цей контракт locker.
Отже, механізм блокування запобігає одночасному доступу і забезпечує, щоб усі транзакції могли бути завершені. Контракт locker запитує lock у порядку, а потім виконує транзакцію через зворотний виклик lockAcquired. Перед і після кожної операції в пулі спрацьовують відповідні зворотні виклики Hook. Нарешті, PoolManager перевіряє стан.
Цей метод означає, що операції коригують внутрішній чистий баланс (, тобто delta ), а не виконують миттєвий переказ. Будь-які зміни будуть зафіксовані в внутрішньому балансі пулу, а фактичний переказ буде здійснено після завершення операції (, тобто lock ). Цей процес гарантує, що немає незакритих токенів, тим самим підтримуючи цілісність коштів.
Через механізм блокування зовнішні всі рахунки (EOA) не можуть безпосередньо взаємодіяти з PoolManager. Натомість будь-яка взаємодія повинна проходити через контракт. Цей контракт виступає як проміжний блокувальник, і перед виконанням будь-яких операцій з пулом потрібно запитати блокування.
Існує два основних сценарії взаємодії з контрактами:
контракт locker походить з офіційної кодової бази або розгортається користувачем. Цю ситуацію можна вважати взаємодією через маршрутизатор.
контракт locker інтегровано з Hook в один і той же контракт або контролюється третіми сторонами. Цю ситуацію можна розглядати як взаємодію через Hook. У цей момент Hook виконує роль контракту locker і відповідає за обробку зворотного виклику.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
Модель загроз
Перед обговоренням відповідних питань безпеки, нам потрібно визначити модель загроз. Основна увага приділяється двом основним випадкам:
Модель загрози I: Hook сам по собі є добрим, але має вразливості.
Модель загрози II: Сам Hook є шкідливим.
Далі буде обговорено потенційні проблеми безпеки на основі цих двох моделей загрози.
2.1 Проблеми безпеки в моделі загроз I
Модель загроз I зосереджується на вразливостях, пов'язаних із самим Hook. Ця модель загроз припускає, що розробники та їх Hook є беззлобними. Однак наявні відомі вразливості смарт-контрактів також можуть з'явитися в Hook. Наприклад, якщо Hook реалізовано як оновлювальний контракт, він може зіткнутися з проблемами, подібними до вразливостей UUPSUpgradeable від OpenZeppelin.
Враховуючи наведені вище фактори, ми вибрали зосередитися на потенційних вразливостях, характерних для версії v4. У Uniswap v4 Hook - це смарт-контракт, який може виконувати користувацьку логіку до або після виконання основних операцій у пулі (, включаючи ініціалізацію, зміну позиції, обмін та збір ). Хоча очікується, що Hook реалізує стандартний інтерфейс, він також дозволяє включати користувацьку логіку. Тому наше обговорення буде обмежене логікою, що стосується стандартного інтерфейсу Hook. Потім ми спробуємо виявити можливі джерела вразливостей, наприклад, як Hook може зловживати цими стандартними функціями Hook.
Конкретно, ми зосередимося на наступних двох типах Hook:
Перший тип хуку, зберігання коштів користувача. У цьому випадку зловмисник може атакувати цей хук, щоб перевести кошти, що призведе до втрати активів.
Другий тип hook, зберігає критично важливі дані про стан, які залежать від користувача або інших протоколів. У цьому випадку зловмисник може спробувати змінити критично важливий стан. Коли інші користувачі або протоколи використовують неправильний стан, це може призвести до потенційного ризику.
Будь ласка, зверніть увагу, що гачки поза цими двома діапазонами не входять до нашої дискусії.
Після детального вивчення репозиторію Awesome Uniswap v4 Hooks ми виявили кілька серйозних вразливостей. Ці вразливості в основному виникають через ризикову взаємодію між hook, PoolManager та зовнішніми третіми сторонами, і їх можна поділити на два основних типи: проблеми з контролем доступу та проблеми з валідацією введення.
Загалом, ми виявили 22 відповідні проекти (, виключаючи проекти, які не стосуються Uniswap v4 ). Серед цих проектів ми вважаємо, що 8 з (36%) проектів мають вразливості. У цих 8 вразливих проектах 6 мають проблеми з контролем доступу, 2 можуть бути піддані ненадійним зовнішнім викликам.
2.1.1 Проблеми контролю доступу
У цій частині обговорення ми головним чином зосереджуємося на проблемах, які можуть виникнути через функції зворотного виклику в v4, включаючи 8 хуків зворотного виклику та зворотний виклик lock. Звичайно, є й інші ситуації, які потрібно перевірити, але ці ситуації різняться за дизайном і наразі не є предметом нашого обговорення.
Ці функції можуть бути викликані лише PoolManager, а не іншими адресами (, включаючи EOA та контракт ). Наприклад, у випадку, коли винагорода розподіляється за допомогою ключа пулу, якщо відповідні функції можуть бути викликані будь-яким рахунком, то винагорода може бути помилково отримана.
Отже, для hook важливо створити надійний механізм контролю доступу, особливо враховуючи те, що до них можуть звертатися інші сторони, окрім самого пулу. Суворе управління правами доступу може значно знизити ризики, пов'язані з несанкціонованою або зловмисною взаємодією з hook.
2.1.2 Проблема верифікації введення
У Uniswap v4, через наявність механізму блокування, користувачі повинні отримати lock через контракт перед виконанням будь-яких операцій з пулом ліквідності. Це гарантує, що контракт, який зараз взаємодіє, є останнім контрактом-локером.
Незважаючи на це, все ще існує можливий сценарій атаки, що виникає внаслідок неналежної перевірки вхідних даних в деяких вразливих реалізаціях Hook, що призводить до ненадійних зовнішніх викликів:
По-перше, hook не перевіряє, з яким пулом активів користувач має намір взаємодіяти. Це може бути шкідливий пул активів, що містить фальшиві токени та виконує шкідливу логіку.
По-друге, деякі ключові функції hook дозволяють будь-які зовнішні виклики.
Ненадійні зовнішні виклики надзвичайно небезпечні, оскільки вони можуть призвести до різних видів атак, включаючи нам відомі атаки повторного входу.
Щоб атакувати ці вразливі hook, зловмисник може зареєструвати власний зловмисний пул коштів для своїх фальшивих токенів, а потім викликати hook для виконання операцій у пулі коштів. Під час взаємодії з пулом коштів логіка зловмисного токена захоплює контрольний потік для вчинення неналежних дій.
2.1.3 Заходи протидії загрозам моделі I
Щоб уникнути таких проблем із безпекою, пов'язаних із hook, важливо здійснювати перевірку взаємодії шляхом належного виконання необхідного контролю доступу до чутливих зовнішніх/публічних функцій та валідації вхідних параметрів. Крім того, захист від повторних викликів може допомогти забезпечити, щоб hook не виконувався повторно в стандартному логічному потоці. Впроваджуючи належні заходи безпеки, пул коштів може зменшити ризики, пов'язані з такими загрозами.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
2.2 Проблеми безпеки в моделі загрози II
У цій моделі загрози ми припускаємо, що розробники та їхні хуки є зловмисними. Оскільки обсяг охоплення є досить широким, ми зосереджуємося лише на питаннях безпеки, пов'язаних з версією v4. Отже, ключовим є те, чи можуть надані хуки обробляти криптоактиви, які користувач переводить або авторизує.
Оскільки метод доступу до hook визначає можливі дозволи, які можуть бути надані hook, ми розділили hook на два типи:
Управлінські хуки(: hook не є точкою входу. Користувачі повинні взаємодіяти з hook через маршрутизатор), який може бути наданий Uniswap(.
Незалежні гачки)Standalone Hooks(: гачок є точкою входу, що дозволяє користувачам безпосередньо взаємодіяти з ним.
)# 2.2.1 Хостингова форма Hook
У цьому випадку криптоактиви користувача ### включають нативні токени та інші токени (, які передаються або надаються маршрутизатору. Оскільки PoolManager виконує перевірку балансу, зловмисному hook важко безпосередньо вкрасти ці активи. Однак, все ще існує потенційна вразливість для атак. Наприклад, механізм управління комісіями версії v4 може бути маніпульований зловмисником через hook.
)# 2.2.2 незалежний Hook
Коли Hook використовується як точка входу, ситуація стає ще складнішою. У цьому випадку, оскільки користувачі можуть безпосередньо взаємодіяти з hook, hook отримує більше влади. Теоретично, hook може виконувати будь-яку бажану операцію через цю взаємодію.
У версії v4 перевірка логіки коду є надзвичайно важливою. Основна проблема полягає в тому, чи можна маніпулювати логікою коду. Якщо hook є оновлювальним, це означає, що, здавалося б, безпечний hook може стати шкідливим після оновлення, що становить значний ризик. До цих ризиків належать:
Можливий до оновлення агент ### може бути безпосередньо атакований (;
Має логіку самознищення. Може бути атаковане в разі спільного виклику selfdestruct та create2.
)# 2.2.3 Заходи проти моделі загроз II
Ключовим моментом є оцінка того, чи є hook шкідливим. Зокрема, для хостингових hook ми повинні звертати увагу на поведінку управління витратами; тоді як для незалежних hook основна увага приділяється їх можливості оновлення.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ]###https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053fb97876f16(
Висновок
У цій статті спочатку коротко описуються основні механізми, пов'язані з проблемами безпеки Hook у Uniswap v4. Потім ми пропонуємо дві моделі загрози та коротко викладаємо пов'язані з ними ризики безпеки.
У наступних статтях ми проведемо детальний аналіз проблем безпеки в кожній моделі загрози.