Uniswap v4 незабаром буде запущено, оновлення вводить безліч нових функцій, включаючи підтримку безмежної кількості ліквідних пулів для кожної торгової пари та динамічні комісії, одиничний дизайн, миттєву бухгалтерію, механізм Hook, а також підтримку стандарту токенів ERC1155. Серед них механізм Hook привернув широке зацікавлення завдяки своєму потужному потенціалу.
Механізм Hook дозволяє виконувати користувацький код у певні моменти життєвого циклу ліквідного пулу, що значно підвищує масштабованість і гнучкість пулу. Однак механізм Hook також може бути двосічним мечем. Хоча він потужний і гнучкий, безпечне використання Hook також є немалим випробуванням. Складність Hook неминуче призводить до нових потенційних векторів атак.
Ця стаття представить концепцію механізму Hook у Uniswap v4 та підсумує пов'язані з ним ризики безпеки.
Основний механізм Uniswap v4
Перед тим як заглибитися в обговорення, нам потрібно мати базове розуміння механізму Uniswap v4. Згідно з офіційним оголошенням та білою книгою, Hook, одноразова архітектура та миттєве бухгалтерське обліку є трьома важливими функціями для реалізації користувацьких ліквіднісних пулів та ефективної маршрутизації через кілька пулів.
Механізм Hook
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 виконує свою логіку під час зворотного виклику. Взаємодія з пулом під час виконання може призвести до ненульового приросту валюти, але після завершення виконання всі прирости повинні бути врегульовані в нуль.
PoolManager перевіряє стан черги lockData та приросту валюти. Після верифікації, видаляє цей договір locker.
В цілому, механізм блокування запобігає конкурентному доступу і забезпечує, щоб усі транзакції могли бути завершені. Цей підхід означає, що операційні коригування стосуються внутрішнього чистого балансу, а не виконання миттєвого переказу. Будь-які зміни записуються в внутрішньому балансі пулу, а фактичний переказ здійснюється наприкінці операції.
Через наявність механізму блокування, всі зовнішні рахунки (EOA) не можуть безпосередньо взаємодіяти з PoolManager. Будь-яка взаємодія повинна здійснюватися через контракт. Існує два основних сценарії взаємодії з контрактом:
locker-контракт походить з офіційної кодової бази або розгортається користувачем. Цю ситуацію можна вважати взаємодією через маршрутизатор.
контракт locker інтегровано в той самий контракт з Hook, або контролюється стороннім суб'єктом. Цю ситуацію можна розглядати як взаємодію через Hook.
Модель загрози
Перед обговоренням відповідних питань безпеки нам потрібно визначити модель загроз. Основна увага приділяється двом ситуаціям:
Модель загрози I: Hook сам по собі є благим, але має вразливості.
Модель загрози II: сам Hook є шкідливим.
проблеми безпеки в моделі загроз I
Модель загрози I зосереджується на вразливостях, пов'язаних безпосередньо з Hook. Ця модель загрози припускає, що розробник та його Hook не є зловмисними. Проте, відомі вразливості існуючих смарт-контрактів також можуть виникнути в Hook.
Ми вирішили зосередитися на потенційних вразливостях, характерних для версії v4, зосередивши увагу на наступних двох Hook:
Хук для зберігання коштів користувача. Зловмисник може атакувати цей Хук для переміщення коштів, що призведе до втрати активів.
Hook для зберігання ключових станів даних, що залежать від користувача або інших протоколів. Зловмисники можуть спробувати змінити ключовий стан, що може призвести до потенційного ризику, коли інші користувачі або протоколи використовують неправильний стан.
Після дослідження ми виявили кілька серйозних вразливостей, які в основному походять від ризикової взаємодії між Hook, PoolManager та зовнішніми третіми сторонами, які можна розділити на дві категорії: проблеми з контролем доступу та проблеми з перевіркою введення.
Проблема контролю доступу
Функції зворотного виклику в v4 можуть викликати проблеми, включаючи 8 Hook зворотних викликів та lock зворотний виклик. Ці функції повинні викликатись лише PoolManager, а не іншими адресами. Для Hook надзвичайно важливо встановити потужний механізм контролю доступу, особливо якщо їх можуть викликати інші сторони, окрім самого пулу.
Проблема верифікації введення
Попри наявність механізму блокування, існує можливий сценарій атаки, пов'язаний із ненадійними зовнішніми викликами, що виникають через неналежну валідацію вводу в деяких вразливих реалізаціях Hook:
Hook не перевіряє, з яким пулом ліквідності користувач має намір взаємодіяти. Це може бути шкідливий пул з фальшивими токенами та небезпечною логікою.
Деякі ключові функції Hook дозволяють будь-які зовнішні виклики.
Ненадійні зовнішні виклики є вкрай небезпечними і можуть призвести до різних типів атак, включаючи повторні атаки.
Заходи безпеки
Для уникнення подібних проблем безпеки, пов'язаних з Hook, надзвичайно важливо забезпечити необхідний контроль доступу до чутливих зовнішніх/публічних функцій шляхом їх належного виконання та перевірки вхідних параметрів, щоб верифікувати взаємодію. Крім того, захист від повторних викликів може допомогти забезпечити, щоб Hook не виконувався повторно в стандартному логічному процесі.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
Проблеми безпеки в моделі загроз II
У цій моделі загроз ми припускаємо, що розробник та його Hook є зловмисними. Ключовим є те, чи може наданий Hook обробляти криптоактиви, що передаються користувачем або авторизуються.
Згідно з методами доступу до Hook, ми розділяємо Hook на два типи:
Хостинг Hook: Hook не є точкою входу. Користувач повинен взаємодіяти з Hook через маршрутизатор.
Незалежний Hook: Hook - це точка входу, що дозволяє користувачам взаємодіяти з ним безпосередньо.
Хук з управлінням
Криптоактиви користувача були переведені або授权члени router. Оскільки PoolManager виконує перевірку балансу, зловмисним Hook не легко безпосередньо вкрасти ці активи. Проте все ще існує потенційна площа атаки, наприклад, механізм управління зборами версії v4 може бути маніпульований зловмисниками через Hook.
Незалежний Hook
Коли Hook використовується як точка входу, ситуація стає ще більш складною. Hook отримує більше влади і теоретично може виконувати будь-яку бажану операцію через цю взаємодію.
У версії v4 перевірка логіки коду є надзвичайно важливою. Основна проблема полягає в тому, чи можна маніпулювати логікою коду. Якщо Hook є оновлювальним, це означає, що на перший погляд безпечний Hook може стати шкідливим після оновлення, створюючи таким чином значний ризик. Ці ризики включають:
Можливий для оновлення агент ( може бути безпосередньо атакований )
Має логіку самознищення. Може бути атаковано у випадку спільного виклику selfdestruct та create2.
Заходи безпеки
Ключовим моментом є оцінка того, чи є Hook шкідливим. Конкретно, для керованих Hook ми повинні звернути увагу на поведінку управління витратами; а для незалежних Hook основна увага приділяється їх можливості оновлення.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053fb97876f16)
Висновок
Ця стаття коротко викладає основні механізми, пов'язані з проблемами безпеки Hook у Uniswap v4, і пропонує дві моделі загроз та пов'язані з ними ризики безпеки. Механізм Hook, хоча і потужний, також створює нові виклики безпеки. Як розробники, так і користувачі повинні повністю усвідомлювати ці потенційні ризики та вживати відповідних заходів для забезпечення безпеки активів при використанні Uniswap v4.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Механізм Hook Uniswap v4: безпекові виклики за потужними функціями
Механізм Hook в Uniswap v4: потенціал і ризики
Uniswap v4 незабаром буде запущено, оновлення вводить безліч нових функцій, включаючи підтримку безмежної кількості ліквідних пулів для кожної торгової пари та динамічні комісії, одиничний дизайн, миттєву бухгалтерію, механізм Hook, а також підтримку стандарту токенів ERC1155. Серед них механізм Hook привернув широке зацікавлення завдяки своєму потужному потенціалу.
Механізм Hook дозволяє виконувати користувацький код у певні моменти життєвого циклу ліквідного пулу, що значно підвищує масштабованість і гнучкість пулу. Однак механізм Hook також може бути двосічним мечем. Хоча він потужний і гнучкий, безпечне використання Hook також є немалим випробуванням. Складність Hook неминуче призводить до нових потенційних векторів атак.
Ця стаття представить концепцію механізму Hook у Uniswap v4 та підсумує пов'язані з ним ризики безпеки.
Основний механізм Uniswap v4
Перед тим як заглибитися в обговорення, нам потрібно мати базове розуміння механізму Uniswap v4. Згідно з офіційним оголошенням та білою книгою, Hook, одноразова архітектура та миттєве бухгалтерське обліку є трьома важливими функціями для реалізації користувацьких ліквіднісних пулів та ефективної маршрутизації через кілька пулів.
Механізм Hook
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 виконує свою логіку під час зворотного виклику. Взаємодія з пулом під час виконання може призвести до ненульового приросту валюти, але після завершення виконання всі прирости повинні бути врегульовані в нуль.
PoolManager перевіряє стан черги lockData та приросту валюти. Після верифікації, видаляє цей договір locker.
В цілому, механізм блокування запобігає конкурентному доступу і забезпечує, щоб усі транзакції могли бути завершені. Цей підхід означає, що операційні коригування стосуються внутрішнього чистого балансу, а не виконання миттєвого переказу. Будь-які зміни записуються в внутрішньому балансі пулу, а фактичний переказ здійснюється наприкінці операції.
Через наявність механізму блокування, всі зовнішні рахунки (EOA) не можуть безпосередньо взаємодіяти з PoolManager. Будь-яка взаємодія повинна здійснюватися через контракт. Існує два основних сценарії взаємодії з контрактом:
locker-контракт походить з офіційної кодової бази або розгортається користувачем. Цю ситуацію можна вважати взаємодією через маршрутизатор.
контракт locker інтегровано в той самий контракт з Hook, або контролюється стороннім суб'єктом. Цю ситуацію можна розглядати як взаємодію через Hook.
Модель загрози
Перед обговоренням відповідних питань безпеки нам потрібно визначити модель загроз. Основна увага приділяється двом ситуаціям:
проблеми безпеки в моделі загроз I
Модель загрози I зосереджується на вразливостях, пов'язаних безпосередньо з Hook. Ця модель загрози припускає, що розробник та його Hook не є зловмисними. Проте, відомі вразливості існуючих смарт-контрактів також можуть виникнути в Hook.
Ми вирішили зосередитися на потенційних вразливостях, характерних для версії v4, зосередивши увагу на наступних двох Hook:
Хук для зберігання коштів користувача. Зловмисник може атакувати цей Хук для переміщення коштів, що призведе до втрати активів.
Hook для зберігання ключових станів даних, що залежать від користувача або інших протоколів. Зловмисники можуть спробувати змінити ключовий стан, що може призвести до потенційного ризику, коли інші користувачі або протоколи використовують неправильний стан.
Після дослідження ми виявили кілька серйозних вразливостей, які в основному походять від ризикової взаємодії між Hook, PoolManager та зовнішніми третіми сторонами, які можна розділити на дві категорії: проблеми з контролем доступу та проблеми з перевіркою введення.
Проблема контролю доступу
Функції зворотного виклику в v4 можуть викликати проблеми, включаючи 8 Hook зворотних викликів та lock зворотний виклик. Ці функції повинні викликатись лише PoolManager, а не іншими адресами. Для Hook надзвичайно важливо встановити потужний механізм контролю доступу, особливо якщо їх можуть викликати інші сторони, окрім самого пулу.
Проблема верифікації введення
Попри наявність механізму блокування, існує можливий сценарій атаки, пов'язаний із ненадійними зовнішніми викликами, що виникають через неналежну валідацію вводу в деяких вразливих реалізаціях Hook:
Hook не перевіряє, з яким пулом ліквідності користувач має намір взаємодіяти. Це може бути шкідливий пул з фальшивими токенами та небезпечною логікою.
Деякі ключові функції Hook дозволяють будь-які зовнішні виклики.
Ненадійні зовнішні виклики є вкрай небезпечними і можуть призвести до різних типів атак, включаючи повторні атаки.
Заходи безпеки
Для уникнення подібних проблем безпеки, пов'язаних з Hook, надзвичайно важливо забезпечити необхідний контроль доступу до чутливих зовнішніх/публічних функцій шляхом їх належного виконання та перевірки вхідних параметрів, щоб верифікувати взаємодію. Крім того, захист від повторних викликів може допомогти забезпечити, щоб Hook не виконувався повторно в стандартному логічному процесі.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
Проблеми безпеки в моделі загроз II
У цій моделі загроз ми припускаємо, що розробник та його Hook є зловмисними. Ключовим є те, чи може наданий Hook обробляти криптоактиви, що передаються користувачем або авторизуються.
Згідно з методами доступу до Hook, ми розділяємо Hook на два типи:
Хостинг Hook: Hook не є точкою входу. Користувач повинен взаємодіяти з Hook через маршрутизатор.
Незалежний Hook: Hook - це точка входу, що дозволяє користувачам взаємодіяти з ним безпосередньо.
Хук з управлінням
Криптоактиви користувача були переведені або授权члени router. Оскільки PoolManager виконує перевірку балансу, зловмисним Hook не легко безпосередньо вкрасти ці активи. Проте все ще існує потенційна площа атаки, наприклад, механізм управління зборами версії v4 може бути маніпульований зловмисниками через Hook.
Незалежний Hook
Коли Hook використовується як точка входу, ситуація стає ще більш складною. Hook отримує більше влади і теоретично може виконувати будь-яку бажану операцію через цю взаємодію.
У версії v4 перевірка логіки коду є надзвичайно важливою. Основна проблема полягає в тому, чи можна маніпулювати логікою коду. Якщо Hook є оновлювальним, це означає, що на перший погляд безпечний Hook може стати шкідливим після оновлення, створюючи таким чином значний ризик. Ці ризики включають:
Заходи безпеки
Ключовим моментом є оцінка того, чи є Hook шкідливим. Конкретно, для керованих Hook ми повинні звернути увагу на поведінку управління витратами; а для незалежних Hook основна увага приділяється їх можливості оновлення.
! [Чому Hook є «палицею з двома кінцями» для Uniswap V4?] ](https://img-cdn.gateio.im/social/moments-97c1e5846e4f09953053fb97876f16)
Висновок
Ця стаття коротко викладає основні механізми, пов'язані з проблемами безпеки Hook у Uniswap v4, і пропонує дві моделі загроз та пов'язані з ними ризики безпеки. Механізм Hook, хоча і потужний, також створює нові виклики безпеки. Як розробники, так і користувачі повинні повністю усвідомлювати ці потенційні ризики та вживати відповідних заходів для забезпечення безпеки активів при використанні Uniswap v4.