Незабаром вийде Uniswap v4, механізм Hook приховує ризики безпеки
Uniswap v4 незабаром буде випущено, це оновлення вводить безліч нових функцій, включаючи підтримку безлічі пулів ліквідності для кожної торгової пари та динамічні збори, одноразовий дизайн, блискавичне обліковування, механізм Hook, а також підтримку стандарту токенів ERC1155. Очікується, що v4 буде випущено після оновлення Ethereum Cancun.
Серед численних інновацій механізм Hook привертає увагу своєю великою потенцією. Він дозволяє виконувати користувацький код у певні моменти життєвого циклу ліквідного пулу, значно підвищуючи масштабованість і гнучкість пулу.
Однак механізм Hook може бути й подвійним мечем. Незважаючи на його потужність та гнучкість, безпечне використання Hook також стикається з викликами. Складність Hook неминуче приносить нові потенційні вектори атак. Тому систематичне введення в безпекові проблеми та потенційні ризики, пов'язані з механізмом Hook, є особливо важливим, оскільки це допоможе створити більш безпечний Uniswap v4 Hook.
У цій статті буде представлено концепції механізму Hook у Uniswap v4 та оглянуто пов'язані з ним ризики безпеки.
Механізм Uniswap V4
Перед тим, як поглиблено розглянути тему, нам потрібно мати базове розуміння механізмів Uniswap v4. Згідно з офіційним оголошенням та білим папером, Hook, одноразова архітектура та миттєве бухгалтерське обліку є трьома важливими функціями для реалізації налаштованих ліквідних пулів та ефективної маршрутизації через кілька пулів.
Гук
Hook - це контракт, який працює на різних етапах життєвого циклу ліквідних фондів. Команда Uniswap сподівається, що впровадження Hook дозволить будь-кому приймати зважені рішення. Цей підхід може забезпечити рідну підтримку динамічних зборів, додавання лімітних ордерів в блокчейні, або здійснення розподілу великих замовлень через середню вагу за часом (TWAMM).
Наразі є вісім Hook зворотних викликів, розділених на чотири групи (, кожна група містить пару зворотних викликів ):
передІніціалізацією/післяІніціалізації
передЗміноюПозиції/післяЗміниПозиції
перед обміном/після обміну
передПожертвою/післяПожертви
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
Одиничний екземпляр, миттєве облікування та механізм блокування
Одноразова архітектура та блискавичне бухгалтерування спрямовані на підвищення продуктивності шляхом зниження витрат і забезпечення ефективності. Вона вводить новий singleton контракт, в якому всі ліквідні пулі зберігаються в одному смарт-контракті. Цей одноразовий дизайн покладається на PoolManager для зберігання та управління станом усіх пулів.
Версія v4 впроваджує механізми блискавичного обліку та блокування. Механізм блокування працює наступним чином:
контракт locker запитує lock на PoolManager.
PoolManager додає адресу цього контракту locker до черги lockData та викликає його зворотний виклик lockAcquired.
Контракт locker виконує свою логіку під час зворотного виклику. Під час виконання взаємодія контракту locker з пулом може призвести до ненульового збільшення валюти. Однак, після завершення виконання всі збільшення повинні бути врегульовані до нуля. Крім того, якщо черга lockData не пуста, тільки останній контракт locker може виконати операцію.
PoolManager перевіряє стан черги lockData та збільшення валюти. Після верифікації PoolManager видалить цей контракт locker.
Отже, механізм блокування запобігає паралельному доступу та гарантує, що всі транзакції можуть бути виконані. Контракт locker запитує блокування в порядку, а потім виконує транзакцію через зворотний виклик lockAcquired. Кожен раз перед і після операцій з пулом викликаються відповідні зворотні виклики Hook. Нарешті, PoolManager перевіряє стан.
Цей метод означає, що операційна корекція стосується внутрішнього чистого балансу (, тобто delta ), а не виконання миттєвого переказу. Будь-які зміни фіксуються у внутрішньому балансі пулу, а фактичний переказ відбувається після завершення операції (, тобто lock ). Цей процес гарантує, що немає непогашених токенів, що підтримує цілісність коштів.
Через наявність механізму блокування, всі зовнішні рахунки (EOA) не можуть безпосередньо взаємодіяти з PoolManager. Натомість будь-яка взаємодія повинна проходити через контракт. Цей контракт виступає в ролі проміжного блокувальника, і перед будь-якими операціями з пулом потрібно запитати блокування.
Існує два основні сценарії взаємодії з контрактами:
locker-контракти походять з офіційної кодової бази або розгортаються користувачем. У цьому випадку ми можемо розглядати взаємодію як таку, що відбувається через маршрутизатор.
Контракт locker інтегрований в один і той же контракт з Hook, або контролюється третьою стороною. У такому випадку ми можемо розглядати взаємодію як таку, що відбувається через Hook. У цьому випадку Hook виконує роль контракту locker і відповідає за обробку зворотного виклику.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
Модель загроз
Перш ніж обговорювати відповідні питання безпеки, нам потрібно визначити модель загроз. Основну увагу слід приділити наступним двом випадкам:
Модель загрози I: Hook сам по собі є добрим, але має вразливості.
Модель загроз II: Hook сам по собі є зловмисним.
У наступній частині ми обговоримо потенційні проблеми безпеки на основі цих двох моделей загроз.
Проблеми безпеки в моделі загроз I
Модель загрози I зосереджується на вразливостях, пов'язаних з самим Hook. Ця модель загрози припускає, що розробники та їх Hook не є зловмисними. Однак відомі вразливості, які вже існують у смарт-контрактах, також можуть з'явитися в Hook.
Ми обираємо зосередитись на потенційних вразливостях, притаманних версії v4. У Uniswap v4, Hook — це смарт-контракт, який може виконувати користувацьку логіку до або після виконання основних операцій в пулі (, включаючи ініціалізацію, зміни позиції, обмін та збори ). Хоча очікується, що Hook реалізує стандартний інтерфейс, він також дозволяє включати користувацьку логіку. Тому наше обговорення буде обмежене логікою, що стосується стандартного інтерфейсу Hook. Потім ми спробуємо виявити можливі джерела вразливостей, наприклад, як Hook може зловживати цими стандартними функціями Hook.
Зокрема, ми зосередимося на наступних двох Hook:
Перший тип hook, зберігання коштів користувача. У цьому випадку зловмисник може атакувати цей hook, щоб перевести кошти, що призведе до втрати активів.
Другий тип хука, зберігає важливі дані стану, на які покладаються користувачі або інші протоколи. У цьому випадку зловмисник може спробувати змінити критичний стан. Коли інші користувачі або протоколи використовують помилковий стан, це може призвести до потенційних ризиків.
Після детального вивчення репозиторію Awesome Uniswap v4 Hooks ми виявили кілька серйозних вразливостей. Ці вразливості в основному виникають через ризикові взаємодії між hook, PoolManager та зовнішніми третіми сторонами, які можна розділити на дві категорії: проблеми з контролем доступу та проблеми з перевіркою вводу.
Загалом ми виявили 22 відповідних проекти (, виключаючи проекти, які не мають відношення до Uniswap v4 ). Серед цих проектів ми вважаємо, що 8 з (36%) проектів мають вразливості. У цих 8 вразливих проектах 6 мають проблеми з контролем доступу, а 2 легко піддаються ненадійним зовнішнім викликам.
Проблеми контролю доступу
У цьому обговоренні ми головним чином зосереджуємося на проблемах, які можуть виникнути з функціями зворотного виклику у v4, включаючи 8 зворотних викликів hook та lock. Ці функції повинні викликатися лише PoolManager і не можуть бути викликані іншими адресами (, включаючи EOA та контракти ). Наприклад, у випадку, коли винагорода розподіляється за допомогою ключа пулу, якщо відповідні функції можуть бути викликані будь-яким рахунком, тоді винагорода може бути неправильно отримана.
Отже, для hook надзвичайно важливо встановити потужний механізм контролю доступу, особливо якщо їх можуть викликати інші сторони, окрім самого пулу. Завдяки суворому управлінню правами доступу, пули ліквідності можуть суттєво знизити ризики несанкціонованої або злоумисної взаємодії з hook.
Питання верифікації введення
У Uniswap v4, через наявність механізму блокування, користувачі повинні отримати lock через контракт перед виконанням будь-яких операцій з пулом ліквідності. Це забезпечує, що контракт, що бере участь у взаємодії, є останнім контрактом-локером.
Попри це, існує можливий сценарій атаки, пов'язаний з ненадійними зовнішніми викликами через неналежну перевірку введення в деяких вразливих реалізаціях Hook:
По-перше, hook не перевіряє, з яким пулом ліквідності користувач має намір взаємодіяти. Це може бути шкідливий пул з фальшивими токенами та шкідливою логікою.
По-друге, деякі ключові функції hook дозволяють будь-які зовнішні виклики.
Ненадійні зовнішні виклики надзвичайно небезпечні, оскільки вони можуть призвести до різних типів атак, включаючи добре відомі нам атаки повторного входу.
Щоб атакувати ці вразливі hook, зловмисник може зареєструвати шкідливий пул ліквідності для своїх фальшивих токенів, а потім викликати hook для виконання операцій у пулі ліквідності. Під час взаємодії з пулом ліквідності логіка шкідливих токенів захоплює контрольний потік для здійснення злочинних дій.
Заходи протидії моделі загроз I
Щоб уникнути подібних проблем безпеки, пов'язаних із hook, важливо належним чином виконати необхідний контроль доступу до чутливих зовнішніх/публічних функцій та перевірити вхідні параметри для валідації взаємодії. Крім того, захист від повторних викликів може допомогти забезпечити, щоб hook не виконувався повторно в стандартних логічних процесах. Завдяки впровадженню відповідних заходів безпеки, фондові пулі можуть знизити ризики, пов'язані з такими загрозами.
Проблеми безпеки в моделі загроз II
У цій моделі загроз ми припускаємо, що розробник та його хук є зловмисними. Оскільки масштаби залучення дуже широкі, ми зосередимося лише на питаннях безпеки, пов'язаних з версією v4. Отже, ключовим є те, чи може наданий хук обробляти криптоактиви під час переказу або авторизації користувача.
Оскільки доступ до методу hook визначає можливі права, які можуть бути надані hook, ми відповідно розділили hook на два типи:
Керовані Hook(Managed Hooks): hook не є точкою входу. Користувачі повинні взаємодіяти з hook через маршрутизатор (, який може бути наданий Uniswap ).
незалежні крючки(Standalone Hooks):hook є точкою входу, що дозволяє користувачам взаємодіяти безпосередньо.
Хостинг Hook
У цьому випадку криптоактиви користувача (, що включають рідні токени та інші токени ), передаються або авторизуються роутеру. Оскільки PoolManager виконує перевірку балансу, зловмисним хукам важко безпосередньо вкрасти ці активи. Проте, все ще існує потенційна вразливість. Наприклад, механізм управління комісіями версії v4 може бути маніпульований зловмисниками через хуки.
незалежний Hook
Коли Hook використовується як точка входу, ситуація стає ще більш складною. У цьому випадку, оскільки користувачі можуть безпосередньо взаємодіяти з hook, він отримує більше повноважень. Теоретично, hook може виконувати будь-яку бажану операцію через цю взаємодію.
У версії v4 перевірка логіки коду є надзвичайно важливою. Основна проблема полягає в тому, чи можна маніпулювати логікою коду. Якщо hook є оновлювальним, це означає, що на перший погляд безпечний hook може стати шкідливим після оновлення, що становить значний ризик. Ці ризики включають:
Можливий для оновлення проксі ( може бути безпосередньо атакований );
Має логіку самознищення. Може бути атакована в разі спільного виклику selfdestruct та create2.
Заходи проти моделі загроз II
Ключовим моментом є оцінка того, чи є hook шкідливим. Конкретно, для хостингових hook ми повинні звернути увагу на поведінку управління витратами; тоді як для незалежних hook основна увага приділяється їх здатності до оновлення.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053fb97876f16)
Висновок
Ця стаття коротко викладає основні механізми, пов'язані з проблемами безпеки Hook в Uniswap v4, пропонує дві моделі загроз і описує відповідні ризики безпеки.
У наступних статтях ми проведемо глибокий аналіз проблем безпеки в кожній моделі загроз.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
У механізмі Hook Uniswap v4 є проблеми з безпекою. Експерти нагадують про обережне використання.
Незабаром вийде Uniswap v4, механізм Hook приховує ризики безпеки
Uniswap v4 незабаром буде випущено, це оновлення вводить безліч нових функцій, включаючи підтримку безлічі пулів ліквідності для кожної торгової пари та динамічні збори, одноразовий дизайн, блискавичне обліковування, механізм Hook, а також підтримку стандарту токенів ERC1155. Очікується, що v4 буде випущено після оновлення Ethereum Cancun.
Серед численних інновацій механізм Hook привертає увагу своєю великою потенцією. Він дозволяє виконувати користувацький код у певні моменти життєвого циклу ліквідного пулу, значно підвищуючи масштабованість і гнучкість пулу.
Однак механізм Hook може бути й подвійним мечем. Незважаючи на його потужність та гнучкість, безпечне використання Hook також стикається з викликами. Складність Hook неминуче приносить нові потенційні вектори атак. Тому систематичне введення в безпекові проблеми та потенційні ризики, пов'язані з механізмом Hook, є особливо важливим, оскільки це допоможе створити більш безпечний Uniswap v4 Hook.
У цій статті буде представлено концепції механізму Hook у Uniswap v4 та оглянуто пов'язані з ним ризики безпеки.
Механізм Uniswap V4
Перед тим, як поглиблено розглянути тему, нам потрібно мати базове розуміння механізмів Uniswap v4. Згідно з офіційним оголошенням та білим папером, Hook, одноразова архітектура та миттєве бухгалтерське обліку є трьома важливими функціями для реалізації налаштованих ліквідних пулів та ефективної маршрутизації через кілька пулів.
Гук
Hook - це контракт, який працює на різних етапах життєвого циклу ліквідних фондів. Команда Uniswap сподівається, що впровадження Hook дозволить будь-кому приймати зважені рішення. Цей підхід може забезпечити рідну підтримку динамічних зборів, додавання лімітних ордерів в блокчейні, або здійснення розподілу великих замовлень через середню вагу за часом (TWAMM).
Наразі є вісім Hook зворотних викликів, розділених на чотири групи (, кожна група містить пару зворотних викликів ):
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
Одиничний екземпляр, миттєве облікування та механізм блокування
Одноразова архітектура та блискавичне бухгалтерування спрямовані на підвищення продуктивності шляхом зниження витрат і забезпечення ефективності. Вона вводить новий singleton контракт, в якому всі ліквідні пулі зберігаються в одному смарт-контракті. Цей одноразовий дизайн покладається на PoolManager для зберігання та управління станом усіх пулів.
Версія v4 впроваджує механізми блискавичного обліку та блокування. Механізм блокування працює наступним чином:
контракт locker запитує lock на PoolManager.
PoolManager додає адресу цього контракту locker до черги lockData та викликає його зворотний виклик lockAcquired.
Контракт locker виконує свою логіку під час зворотного виклику. Під час виконання взаємодія контракту locker з пулом може призвести до ненульового збільшення валюти. Однак, після завершення виконання всі збільшення повинні бути врегульовані до нуля. Крім того, якщо черга lockData не пуста, тільки останній контракт locker може виконати операцію.
PoolManager перевіряє стан черги lockData та збільшення валюти. Після верифікації PoolManager видалить цей контракт locker.
Отже, механізм блокування запобігає паралельному доступу та гарантує, що всі транзакції можуть бути виконані. Контракт locker запитує блокування в порядку, а потім виконує транзакцію через зворотний виклик lockAcquired. Кожен раз перед і після операцій з пулом викликаються відповідні зворотні виклики Hook. Нарешті, PoolManager перевіряє стан.
Цей метод означає, що операційна корекція стосується внутрішнього чистого балансу (, тобто delta ), а не виконання миттєвого переказу. Будь-які зміни фіксуються у внутрішньому балансі пулу, а фактичний переказ відбувається після завершення операції (, тобто lock ). Цей процес гарантує, що немає непогашених токенів, що підтримує цілісність коштів.
Через наявність механізму блокування, всі зовнішні рахунки (EOA) не можуть безпосередньо взаємодіяти з PoolManager. Натомість будь-яка взаємодія повинна проходити через контракт. Цей контракт виступає в ролі проміжного блокувальника, і перед будь-якими операціями з пулом потрібно запитати блокування.
Існує два основні сценарії взаємодії з контрактами:
locker-контракти походять з офіційної кодової бази або розгортаються користувачем. У цьому випадку ми можемо розглядати взаємодію як таку, що відбувається через маршрутизатор.
Контракт locker інтегрований в один і той же контракт з Hook, або контролюється третьою стороною. У такому випадку ми можемо розглядати взаємодію як таку, що відбувається через Hook. У цьому випадку Hook виконує роль контракту locker і відповідає за обробку зворотного виклику.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
Модель загроз
Перш ніж обговорювати відповідні питання безпеки, нам потрібно визначити модель загроз. Основну увагу слід приділити наступним двом випадкам:
Модель загрози I: Hook сам по собі є добрим, але має вразливості.
Модель загроз II: Hook сам по собі є зловмисним.
У наступній частині ми обговоримо потенційні проблеми безпеки на основі цих двох моделей загроз.
Проблеми безпеки в моделі загроз I
Модель загрози I зосереджується на вразливостях, пов'язаних з самим Hook. Ця модель загрози припускає, що розробники та їх Hook не є зловмисними. Однак відомі вразливості, які вже існують у смарт-контрактах, також можуть з'явитися в Hook.
Ми обираємо зосередитись на потенційних вразливостях, притаманних версії v4. У Uniswap v4, Hook — це смарт-контракт, який може виконувати користувацьку логіку до або після виконання основних операцій в пулі (, включаючи ініціалізацію, зміни позиції, обмін та збори ). Хоча очікується, що Hook реалізує стандартний інтерфейс, він також дозволяє включати користувацьку логіку. Тому наше обговорення буде обмежене логікою, що стосується стандартного інтерфейсу Hook. Потім ми спробуємо виявити можливі джерела вразливостей, наприклад, як Hook може зловживати цими стандартними функціями Hook.
Зокрема, ми зосередимося на наступних двох Hook:
Перший тип hook, зберігання коштів користувача. У цьому випадку зловмисник може атакувати цей hook, щоб перевести кошти, що призведе до втрати активів.
Другий тип хука, зберігає важливі дані стану, на які покладаються користувачі або інші протоколи. У цьому випадку зловмисник може спробувати змінити критичний стан. Коли інші користувачі або протоколи використовують помилковий стан, це може призвести до потенційних ризиків.
Після детального вивчення репозиторію Awesome Uniswap v4 Hooks ми виявили кілька серйозних вразливостей. Ці вразливості в основному виникають через ризикові взаємодії між hook, PoolManager та зовнішніми третіми сторонами, які можна розділити на дві категорії: проблеми з контролем доступу та проблеми з перевіркою вводу.
Загалом ми виявили 22 відповідних проекти (, виключаючи проекти, які не мають відношення до Uniswap v4 ). Серед цих проектів ми вважаємо, що 8 з (36%) проектів мають вразливості. У цих 8 вразливих проектах 6 мають проблеми з контролем доступу, а 2 легко піддаються ненадійним зовнішнім викликам.
Проблеми контролю доступу
У цьому обговоренні ми головним чином зосереджуємося на проблемах, які можуть виникнути з функціями зворотного виклику у v4, включаючи 8 зворотних викликів hook та lock. Ці функції повинні викликатися лише PoolManager і не можуть бути викликані іншими адресами (, включаючи EOA та контракти ). Наприклад, у випадку, коли винагорода розподіляється за допомогою ключа пулу, якщо відповідні функції можуть бути викликані будь-яким рахунком, тоді винагорода може бути неправильно отримана.
Отже, для hook надзвичайно важливо встановити потужний механізм контролю доступу, особливо якщо їх можуть викликати інші сторони, окрім самого пулу. Завдяки суворому управлінню правами доступу, пули ліквідності можуть суттєво знизити ризики несанкціонованої або злоумисної взаємодії з hook.
Питання верифікації введення
У Uniswap v4, через наявність механізму блокування, користувачі повинні отримати lock через контракт перед виконанням будь-яких операцій з пулом ліквідності. Це забезпечує, що контракт, що бере участь у взаємодії, є останнім контрактом-локером.
Попри це, існує можливий сценарій атаки, пов'язаний з ненадійними зовнішніми викликами через неналежну перевірку введення в деяких вразливих реалізаціях Hook:
По-перше, hook не перевіряє, з яким пулом ліквідності користувач має намір взаємодіяти. Це може бути шкідливий пул з фальшивими токенами та шкідливою логікою.
По-друге, деякі ключові функції hook дозволяють будь-які зовнішні виклики.
Ненадійні зовнішні виклики надзвичайно небезпечні, оскільки вони можуть призвести до різних типів атак, включаючи добре відомі нам атаки повторного входу.
Щоб атакувати ці вразливі hook, зловмисник може зареєструвати шкідливий пул ліквідності для своїх фальшивих токенів, а потім викликати hook для виконання операцій у пулі ліквідності. Під час взаємодії з пулом ліквідності логіка шкідливих токенів захоплює контрольний потік для здійснення злочинних дій.
Заходи протидії моделі загроз I
Щоб уникнути подібних проблем безпеки, пов'язаних із hook, важливо належним чином виконати необхідний контроль доступу до чутливих зовнішніх/публічних функцій та перевірити вхідні параметри для валідації взаємодії. Крім того, захист від повторних викликів може допомогти забезпечити, щоб hook не виконувався повторно в стандартних логічних процесах. Завдяки впровадженню відповідних заходів безпеки, фондові пулі можуть знизити ризики, пов'язані з такими загрозами.
Проблеми безпеки в моделі загроз II
У цій моделі загроз ми припускаємо, що розробник та його хук є зловмисними. Оскільки масштаби залучення дуже широкі, ми зосередимося лише на питаннях безпеки, пов'язаних з версією v4. Отже, ключовим є те, чи може наданий хук обробляти криптоактиви під час переказу або авторизації користувача.
Оскільки доступ до методу hook визначає можливі права, які можуть бути надані hook, ми відповідно розділили hook на два типи:
Керовані Hook(Managed Hooks): hook не є точкою входу. Користувачі повинні взаємодіяти з hook через маршрутизатор (, який може бути наданий Uniswap ).
незалежні крючки(Standalone Hooks):hook є точкою входу, що дозволяє користувачам взаємодіяти безпосередньо.
Хостинг Hook
У цьому випадку криптоактиви користувача (, що включають рідні токени та інші токени ), передаються або авторизуються роутеру. Оскільки PoolManager виконує перевірку балансу, зловмисним хукам важко безпосередньо вкрасти ці активи. Проте, все ще існує потенційна вразливість. Наприклад, механізм управління комісіями версії v4 може бути маніпульований зловмисниками через хуки.
незалежний Hook
Коли Hook використовується як точка входу, ситуація стає ще більш складною. У цьому випадку, оскільки користувачі можуть безпосередньо взаємодіяти з hook, він отримує більше повноважень. Теоретично, hook може виконувати будь-яку бажану операцію через цю взаємодію.
У версії v4 перевірка логіки коду є надзвичайно важливою. Основна проблема полягає в тому, чи можна маніпулювати логікою коду. Якщо hook є оновлювальним, це означає, що на перший погляд безпечний hook може стати шкідливим після оновлення, що становить значний ризик. Ці ризики включають:
Можливий для оновлення проксі ( може бути безпосередньо атакований );
Має логіку самознищення. Може бути атакована в разі спільного виклику selfdestruct та create2.
Заходи проти моделі загроз II
Ключовим моментом є оцінка того, чи є hook шкідливим. Конкретно, для хостингових hook ми повинні звернути увагу на поведінку управління витратами; тоді як для незалежних hook основна увага приділяється їх здатності до оновлення.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053fb97876f16)
Висновок
Ця стаття коротко викладає основні механізми, пов'язані з проблемами безпеки Hook в Uniswap v4, пропонує дві моделі загроз і описує відповідні ризики безпеки.
У наступних статтях ми проведемо глибокий аналіз проблем безпеки в кожній моделі загроз.