Вірте чи ні, Uniswap v4 скоро зустрінеться з усіма!

Цього разу команда Uniswap поставила перед собою амбітні цілі та планує представити безліч нових функцій, включаючи необмежену кількість пулів ліквідності та динамічні комісії для кожної торгової пари, дизайн синглтона, флеш-облік, хук та підтримку стандарту токенів ERC1155. Використовуючи тимчасове сховище, представлене EIP-1153, очікується, що Uniswap v4 буде випущено після оновлення Ethereum Cancun. Серед безлічі нововведень механізм Hook привернув широку увагу завдяки своєму потужному потенціалу. Механізм Hook дозволяє виконувати певний код у певні моменти життєвого циклу пулу ліквідності, значно підвищуючи масштабованість і гнучкість пулів. Однак механізм Hook також може бути палицею з двома кінцями. Незважаючи на те, що він потужний і гнучкий, безпечне використання хука також є серйозною проблемою. Складність Хука неминуче породжує нові потенційні вектори атаки. Тому ми сподіваємося написати серію статей для систематичного ознайомлення з питаннями безпеки та потенційними ризиками, пов'язаними з механізмом Hook, щоб сприяти розвитку безпеки спільноти. Ми віримо, що ця інформація допоможе створити безпечні хуки Uniswap v4. Як вступна стаття цієї серії, ця стаття знайомить з поняттями, пов'язаними з механізмом Hook в Uniswap v4, і окреслює ризики безпеки, пов'язані з механізмом Hook.

- 1 - Механізм Uniswap V4

Перед тим як заглиблюватися глибше, нам потрібно мати базове розуміння механізмів Uniswap v4. Згідно з офіційним оголошенням [1] та білим папером [2], Хуки, одиночна архітектура та швидкий облік - це три важливі функції, які дозволяють настроювати пули ліквідності та ефективно маршрутизувати через кілька пулів.

1.1 Гачок

Hooks - це контракти, які запускаються на різних етапах життєвого циклу пула ліквідності. Команда Uniswap сподівається, що за допомогою Hooks будь-хто зможе приймати рішення про вибір, вводячи їх. Таким чином, можна реалізувати вбудовану підтримку для динамічних комісій, лімітних ордерів у ланцюжку або ринкових мейкерів з часовою зваженою середньою вагою (TWAMMs) для розбиття великих ордерів. На даний момент існує вісім викликів зворотного виклику Hooks, розділених на чотири пари (кожна пара містить один перед та один після виклику):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• beforeSwap/afterSwap
• beforeDonate/afterDonate

Нижче наведено потік обміну Hook, який був представлений у білій книзі [2].

Рисунок 1: Потік Swap Hook

Команда Uniswap продемонструвала методологію за допомогою деяких прикладів (наприклад, TWAMM Hook [3]), а також учасники спільноти також зробили внесок. Офіційна документація [4] також посилається на репозиторій Awesome Uniswap v4 Hooks [5], який збирає більше прикладів Hook.

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

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

👇🏻 Механізм блокування працює наступним чином: 1. Контракт локера запитує блокування від PoolManager. 2. PoolManager додає адресу контракту локера до черги lockData та викликає його зворотний виклик lockAcquired. 3. Контракт локера виконує свою логіку в зворотньому виклику. Взаємодії з пулом під час виконання можуть призвести до ненульового збільшення валюти. Однак до кінця виконання всі збільшення повинні складати нуль. Крім того, якщо черга lockData не є порожньою, тільки останній контракт локера може виконувати операції. 4. PoolManager перевіряє стан черги lockData та збільшення валюти. Після перевірки PoolManager видаляє контракт локера.

У підсумку, механізм блокування запобігає одночасному доступу та забезпечує урегулювання всіх транзакцій. Контракти шафи запитують блокування послідовно, а потім виконують угоди за допомогою зворотного виклику lockAcquired. Відповідні зворотні виклики Hook викликаються перед і після кожної операції з пулом. Нарешті, PoolManager перевіряє стани. Це означає, що операції коригують внутрішні чисті баланси (тобто дельта), а не виконують миттєві перекази. Будь-які модифікації записуються внутрішніми балансами пулу, і фактичні перекази відбуваються, коли операція (тобто блокування) завершується. Цей процес гарантує відсутність виставлених токенів, забезпечуючи цілісність коштів. У зв'язку з механізмом блокування зовнішні власні рахунки (EOA) не можуть взаємодіяти безпосередньо з PoolManager. Замість цього будь-яка взаємодія повинна пройти через контракт. Цей контракт діє як посередник-шафа, який запитує блокування перед проведенням будь-яких операцій з пулом. (12/08)

👇🏻 Існують два основні сценарії взаємодії з контрактами:

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

- 2 -Модель загроз

Перед обговоренням відповідних проблем безпеки нам потрібно встановити модель загроз. Ми переважно розглядаємо наступні два випадки:

• Модель загрози I: Сам гачок є безпечним, але містить вразливості.
• Модель загроз II: Сам гук є зловмисним.

У наступних розділах ми обговоримо потенційні проблеми безпеки згідно з цими двома моделями загроз.

2.1 Проблеми безпеки в моделі загроз I

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

👇🏻 Зокрема, ми зосередимо увагу на наступних двох типах Гачків:

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

Зверніть увагу, що гачки поза цими двома областями не обговорюються тут. Оскільки на момент написання немає реальних використань гачків, ми візьмемо деяку інформацію з репозиторію Awesome Uniswap v4 Hooks. Після глибокого вивчення репозиторію Awesome Uniswap v4 Hooks (хеш коміту 3a0a444922f26605ec27a41929f3ced924af6075), ми виявили кілька серйозних вразливостей. Ці вразливості в основному виникають від ризикованих взаємодій між гачком, PoolManager та зовнішніми сторонами, і можуть бути розділені на дві категорії: проблеми з контролем доступу та проблеми з перевіркою введення. Конкретні висновки показані в таблиці нижче:

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

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

У цій частині обговорення ми в основному зосереджуємося на проблемах, які можуть спричиняти функції зворотного виклику у версії 4, включаючи 8 зворотних викликів хуків та зворотний виклик блокування. Звичайно, є й інші випадки, які потребують перевірки, але вони різняться за задумом і наразі виходять за рамки сфери. Ці функції повинні викликатися тільки PoolManager, а не іншими адресами (включаючи EOA і контракти). Наприклад, у випадку, коли винагороди розподіляються з ключів пулу, винагороди можуть бути неправильно отримані, якщо відповідні функції можна викликати довільними обліковими записами. Тому створення надійних механізмів контролю доступу має вирішальне значення для хуків, оскільки вони можуть бути викликані іншими сторонами, крім самих пулів. Суворо регулюючи дозволи на доступ, пули ліквідності можуть значно знизити ризики, пов'язані з несанкціонованою або зловмисною взаємодією з хуками.

2.1.2 Проблеми перевірки введення даних

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

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

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

2.1.3 Протидії для моделі загроз I

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

2.2 Проблеми безпеки в моделі загроз II

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

• Управляючі гачки: Гачок не є точкою входу. Користувачі повинні взаємодіяти з гачком через маршрутизатор (можливо, наданий Uniswap).
• Standalone Hooks: Гачок - це точка входу, яка дозволяє користувачам взаємодіяти з ним безпосередньо.

Фігура 2: Приклад зловмисного гачка

2.2.1 Управляні Гачки

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

2.2.2 Окремі Гачки

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

• Оновлювані проксі (які можуть бути напряму атаковані)
• Логіка з самознищенням. Може бути атакована разом з викликом selfdestruct та create2.

2.2.3 Протиходії для моделі загроз II

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

- 3 - Висновок

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

Посилання

[1] Наше візіонерське бачення для Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] Чорновик білого паперу Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Uniswap v4 TWAMM Гак
https://blog.uniswap.org/v4-twamm-hook

[4] Приклади гачка
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Круті Гачки Uniswap v4
https://github.com/fewwwww/awesome-uniswap-hooks

[6] Уразливість оновлення UUPSPost-мортем
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

Про BlockSec BlockSec — провідна світова компанія з безпеки блокчейну, заснована у 2021 році відомими експертами в галузі безпеки. Компанія прагне підвищити безпеку та зручність використання у світі Web3, щоб сприяти широкому впровадженню Web3. Щоб досягти цього, BlockSec надає послуги аудиту безпеки смарт-контрактів і ланцюга EVM, систему розробки, тестування та перехоплення хакерів безпеки під назвою Phalcon для власників проєктів, платформу відстеження та розслідування коштів під назвою MetaSleuth, а також плагіни ефективності для розробників web3 під назвою MetaDock. В даний час компанія обслуговує понад 300 клієнтів, включаючи такі відомі проекти, як MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, і отримала два раунди фінансування на загальну суму понад десятки мільйонів доларів від інвестиційних інститутів, таких як Oasis Capital, IDG Capital і Distributed Capital. Головна сторінка:www.blocksec.com

Twitter：https://twitter.com/БлокSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Disclaimer：

1. Ця стаття передрукована з [ БлокSec]. Усі авторські права належать оригінальному автору [БлокSec]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Блоккомандою, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору й не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.