Чому говорять, що Hook є "подвійним мечем" Uniswap V4?

Uniswap v4 очікується в найближчому майбутньому. Цього разу команда Uniswap встановила амбітні цілі, плануючи впровадити кілька нових функцій, включаючи підтримку необмеженої кількості ліквідних пулів для кожної торгової пари та динамічні збори, унікальний дизайн, миттєве обліку, Hook, а також підтримку стандарту токенів ERC1155. Використовуючи транзитне зберігання, Uniswap v4, як очікується, буде випущений після оновлення Ethereum Cancun.

Серед багатьох інновацій механізм Hook привертає широку увагу завдяки своєму потужному потенціалу. Він підтримує виконання певного коду в конкретні моменти життєвого циклу пулу ліквідності, що значно підвищує масштабованість і гнучкість пулу.

Однак механізм Hook може бути й двосічним мечем. Незважаючи на потужність і гнучкість, безпечне використання Hook також є неабияким викликом. Складність Hook неминуче приносить нові потенційні вектори атак. Тому ми сподіваємося через ряд статей систематично представити питання безпеки та потенційні ризики, пов'язані з механізмом Hook, щоб сприяти безпечному розвитку спільноти, віримо, що ці висновки допоможуть у створенні безпечного Uniswap v4 Hook.

Як перша стаття цієї серії, цей документ представляє концепції, пов'язані з механізмом Hook у Uniswap v4, і підсумовує безпекові ризики, пов'язані з існуванням механізму Hook.

Механізм Uniswap V4

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

1.1 Гачок

Hook означає контракти, які функціонують на різних етапах життя ліквідних пулів. Команда Uniswap сподівається, що впровадження Hook дозволить кожному приймати зважені рішення. Таким чином, можна реалізувати рідну підтримку динамічних комісій, додавання лімітних ордерів на блокчейні або розподіл великих замовлень через часово зважене середнє (TWAMM).

На даний момент є вісім зворотних викликів Hook, які діляться на чотири групи (кожна група містить пару викликів):

• передІніціалізацією/післяІніціалізації

• передЗміноюПозиції/післяЗміниПозиції

• передОбміном/післяОбміну

• передДоносом/післяДоносу

1.2 Одиночний, миттєвий облік і механізм блокування

Архітектура Singleton та миттєва бухгалтерія спрямовані на підвищення продуктивності шляхом зниження витрат та забезпечення ефективності. Вона вводить новий контракт singleton, у якому всі ліквідні пулі зберігаються в одному й тому ж смарт-контракті. Цей дизайн singleton покладається на PoolManager для зберігання та управління станом усіх пулів.

У ранніх версіях протоколу Uniswap операції, такі як обмін або додавання ліквідності, передбачали безпосередній переказ токенів, в той час як версія v4 має інші особливості, оскільки вона впроваджує механізм миттєвого обліку та блокування.

Механізм блокування працює наступним чином:

1. Якийсь контракт locker запитує lock на PoolManager.

2. PoolManager додає адресу цього locker контракту до черги lockData та викликає його зворотний виклик lockAcquired.

3. Цей контракт locker виконує свою логіку у зворотному виклику. У процесі виконання взаємодія контракту locker з пулом може призвести до ненульового збільшення валюти. Проте, по завершенню виконання, всі збільшення повинні бути врегульовані до нуля. Крім того, якщо черга lockData не порожня, лише останній контракт locker може виконувати операції.

4. PoolManager перевіряє стан черги lockData та приросту валюти. Після перевірки PoolManager видалить цей контракт locker.

Сумуючи, механізм блокування запобігає конкурентному доступу і забезпечує, що всі транзакції можуть бути ліквідовані. Контракт locker запитує lock по порядку, а потім виконує транзакцію через зворотний виклик lockAcquired. Перед і після кожної операції з пулом будуть викликані відповідні зворотні виклики Hook. Нарешті, PoolManager перевірить стан.

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

Через наявність механізму блокування, всі зовнішні рахунки (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 зосереджується на вразливостях, пов'язаних безпосередньо з Hook. Ця модель загрози припускає, що розробник та його Hook не є зловмисними. Проте, існуючі відомі вразливості смарт-контрактів також можуть з'явитися в Hook. Наприклад, якщо Hook реалізований як оновлюваний контракт, то він може зіткнутися з проблемами, подібними до вразливостей UUPSUpgradeable від OpenZeppelin.

Враховуючи вищезазначені фактори, ми вирішили зосередитися на потенційних уразливостях, притаманних версії v4. У Uniswap v4 Hook є смарт-контрактом, здатним виконувати власну логіку до або після операцій в основному пулі (включаючи ініціалізацію, модифікацію позицій, обмін і збір). Хоча очікується, що Hook реалізує стандартний інтерфейс, він також дозволяє включати власну логіку. Тому наша дискусія буде обмежена логікою, що стосується стандартного інтерфейсу Hook. Потім ми спробуємо виявити можливі джерела вразливостей, наприклад, як Hook може зловживати цими стандартними функціями Hook.

Конкретно ми зосередимося на двох типах Hook:

• Перший тип hook, зберігання коштів користувачів. У цьому випадку зловмисник може атакувати цей hook для переміщення коштів, що призведе до втрати активів.

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

Зверніть увагу, що хуки за межами цих двох діапазонів не є темою нашої дискусії.

В цілому, ми виявили 22 відповідні проекти (виключаючи проекти, що не пов'язані з Uniswap v4). Серед цих проектів ми вважаємо, що 8 (36%) проектів мають вразливості. У цих 8 вразливих проектах 6 мають проблеми з контролем доступу, а 2 піддаються ненадійним зовнішнім викликам.

2.1.1 Проблеми контролю доступу

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

Ці функції повинні викликатися лише 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 через маршрутизатор (можливо, наданий Uniswap).

• Незалежний Hook: hook є точкою входу, що дозволяє користувачам взаємодіяти з ним безпосередньо.

2.2.1 Хостингова Hook

У цій ситуації криптоактиви користувача (включаючи рідні токени та інші токени) передаються або авторизуються маршрутизатору. Оскільки PoolManager виконує перевірку балансу, зловмисним хукам важко безпосередньо вкрасти ці активи. Однак все ще існують потенційні вектори атаки. Наприклад, механізм управління комісіями версії v4 може бути маніпульований зловмисниками через хуки.

2.2.2 Незалежний Hook

Коли Hook використовується як точка входу, ситуація стає ще більш складною. У цьому випадку, оскільки користувач може безпосередньо взаємодіяти з hook, він отримує більше влади. Теоретично, hook може виконати будь-яку операцію через цю взаємодію.

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

• Можливий для оновлення проксі (може бути безпосередньо атакований);

• Має логіку самознищення. Може бути атакований у випадку спільного виклику selfdestruct і create2.

2.2.3 Заходи щодо захисту від моделі загроз II

Важливий момент полягає в оцінці того, чи є hook шкідливим. Конкретно, для хостингових hook ми повинні зосередитися на поведінці управління витратами; а для незалежних hook основна увага приділяється їх можливості оновлення.

Висновок

У цій статті ми спочатку коротко викладаємо основні механізми, пов'язані з проблемою безпеки Hook в Uniswap v4. Потім ми пропонуємо дві моделі загрози та коротко викладаємо відповідні ризики безпеки.

У подальших статтях ми розглянемо кожну модель загрози