Двусторонний характер механизма 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, разделенных на четыре группы (, каждая группа содержит пару обратных вызовов ):
передИнициализацией/послеИнициализации
beforeModifyPosition/afterModifyPosition
передСменой/послеСмены
передПожертвованием/послеПожертвования
Команда Uniswap предоставила несколько примеров (, таких как метод работы TWAMM Hook ), а участники сообщества также внесли некоторые вклад. Официальная документация также ссылается на репозиторий Awesome Uniswap v4 Hooks, который собирает больше примеров Hook.
1.2 Синглтон, молниеносная бухгалтерия и механизм блокировки
Архитектура Singleton и молниеносный учет предназначены для повышения производительности за счет снижения затрат и обеспечения эффективности. Она вводит новый контракт singleton, в котором все ликвидные пулы хранятся в одном и том же смарт-контракте. Этот дизайн Singleton полагается на PoolManager для хранения и управления состоянием всех пулов.
Версия Uniswap 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, так и отвечает за обработку обратного вызова.
Модель угроз
Перед обсуждением связанных с безопасностью вопросов нам необходимо определить модель угроз. Основное внимание следует уделить следующим двум ситуациям:
Модель угроз I: Hook сам по себе является безвредным, но содержит уязвимость.
Модель угроз II: Hook сам по себе является злонамеренным.
Далее будут обсуждены потенциальные проблемы безопасности в соответствии с этими двумя моделями угроз.
2.1 Проблемы безопасности в модели угроз I
Модель угроз I сосредоточена на уязвимостях, связанных с самим Hook. Эта модель угроз предполагает, что разработчик и его Hook не имеют злых намерений. Однако известные уязвимости существующих смарт-контрактов также могут проявляться в Hook. Например, если Hook реализован как обновляемый контракт, он может столкнуться с проблемами, связанными с уязвимостью UUPSUpgradeable от OpenZeppelin.
Учитывая вышеизложенные факторы, мы решили сосредоточиться на потенциальных уязвимостях, характерных для версии v4. В Uniswap v4 Hook — это смарт-контракт, который может выполнять пользовательскую логику до или после выполнения операций с основным пулом (, включая инициализацию, изменение позиции, обмен и сбор ). Хотя ожидается, что Hook реализует стандартный интерфейс, он также позволяет включать пользовательскую логику. Поэтому наше обсуждение будет ограничено логикой, связанной со стандартным интерфейсом 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 хуков и обратный вызов блокировки. Конечно, есть и другие случаи, которые необходимо проверить, но эти случаи отличаются по дизайну и в настоящее время не входят в наш круг обсуждения.
Эти функции должны вызываться только PoolManager, а не другими адресами (, включая EOA и контракты ). Например, в случае, если вознаграждение распределяется с помощью ключа пула, если соответствующие функции могут быть вызваны любым аккаунтом, вознаграждение может быть неправильно получено.
Таким образом, для hook крайне важно создать надежный механизм контроля доступа, особенно учитывая, что к ним могут обращаться сторонние лица, кроме самого пула. Путем строгого управления правами доступа, ликвидный пул может значительно снизить риски несанкционированного или злонамеренного взаимодействия с hook.
2.1.2 Проблемы проверки ввода
В Uniswap v4 из-за наличия механизма блокировки пользователи должны получить lock через контракт перед выполнением любых операций с пулом ликвидности. Это гарантирует, что текущий взаимодействующий контракт является актуальным контрактом-локером.
Тем не менее, существует возможный сценарий атаки, при котором из-за ненадлежащей валидации входных данных в некоторых уязвимых реализациях Hook происходят недоверенные внешние вызовы:
Во-первых, hook не проверяет пул средств, с которым пользователь собирается взаимодействовать. Это может быть злонамеренный пул средств, содержащий поддельные токены и выполняющий вредоносную логику.
Во-вторых, некоторые ключевые функции hook позволяют произвольные внешние вызовы.
Ненадежные внешние вызовы чрезвычайно опасны, поскольку они могут привести к различным типам атак, включая хорошо известные нам атаки повторного входа.
Чтобы атаковать эти уязвимые хуки, злоумышленник может зарегистрировать злонамеренный пул ликвидности для своих поддельных токенов, а затем вызвать хуки для выполнения операций в пуле. При взаимодействии с пулом ликвидности логика злонамеренных токенов перехватывает управление потоком для совершения неправомерных действий.
2.1.3 Меры по защите от модели угроз I
Чтобы избежать подобных проблем безопасности, связанных с hook, крайне важно правильно выполнять необходимый контроль доступа к чувствительным внешним/публичным функциям и проверять входные параметры для верификации взаимодействий. Кроме того, защита от повторного входа может помочь убедиться, что hook не будет повторно выполняться в стандартном логическом процессе. Реализовав соответствующие меры безопасности, пул ликвидности может снизить риски, связанные с такими угрозами.
2.2 Проблемы безопасности в модели угроз II
В этой модели угроз мы предполагаем, что разработчик и его хуки являются злонамеренными. Учитывая широкий диапазон вовлеченности, мы сосредоточимся только на вопросах безопасности, связанных с версией v4. Поэтому ключевым моментом является то, могут ли предоставленные хуки обрабатывать зашифленные активы пользователя при переводах или авторизации.
Поскольку метод доступа к хуку определяет возможные разрешения, которые могут быть предоставлены хуку, мы разделяем хуки на два типа:
Управляемые хуки (: hook не является точкой входа. Пользователь должен взаимодействовать с hook через маршрутизатор ), который может быть предоставлен Uniswap (.
Независимые крюки)Standalone Hooks(: крюк является точкой входа, позволяя пользователям взаимодействовать с ним напрямую.
)# 2.2.1 Хостинговый Hook
В этом случае криптоактивы пользователя ### включают нативные токены и другие токены (, которые передаются или авторизованы для маршрутизатора. Поскольку PoolManager выполняет проверку баланса, злоумышленникам не так легко напрямую украсть эти активы. Тем не менее, существует потенциальная уязвимость. Например, механизм управления сборами версии v4 может быть скомпрометирован злоумышленниками через хуки.
)# 2.2.2 Независимый Hook
Когда Hook используется в качестве точки входа, ситуация становится более сложной. В этом случае, поскольку пользователи могут напрямую взаимодействовать с hook, у него появляется больше власти. Теоретически, hook может выполнять любые действия, которые он хочет, через это взаимодействие.
В версии v4 проверка логики кода является очень важной. Основная проблема заключается в том, можно ли манипулировать логикой кода. Если хук является обновляемым, это означает, что казалось бы безопасный хук может стать злонамеренным после обновления, что представляет собой значительный риск. Эти риски включают:
Апгрейдable代理### может быть подвержен прямой атаке(;
Имеет логику саморазрушения. Может быть атакован в случае совместного вызова selfdestruct и create2.
)# 2.2.3 Меры противодействия модели угроз II
Ключевым моментом является оценка того, является ли hook вредоносным. Конкретно, для управляемых hook мы должны обращать внимание на поведение управления затратами; в то время как для независимых hook основное внимание следует уделять тому, могут ли они быть обновлены.
![Почему Hook называют "двуострым мечом" Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Вывод
В статье сначала кратко описываются основные механизмы, связанные с проблемами безопасности 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
Старая версия проекта эволюционировала, неудачники, которые слепо поднимаются на борт, снова столкнутся с трудностями.
Анализ безопасности механизма 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 Синглтон, молниеносная бухгалтерия и механизм блокировки
Архитектура Singleton и молниеносный учет предназначены для повышения производительности за счет снижения затрат и обеспечения эффективности. Она вводит новый контракт singleton, в котором все ликвидные пулы хранятся в одном и том же смарт-контракте. Этот дизайн Singleton полагается на PoolManager для хранения и управления состоянием всех пулов.
Версия Uniswap 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, так и отвечает за обработку обратного вызова.
Модель угроз
Перед обсуждением связанных с безопасностью вопросов нам необходимо определить модель угроз. Основное внимание следует уделить следующим двум ситуациям:
Модель угроз I: Hook сам по себе является безвредным, но содержит уязвимость.
Модель угроз II: Hook сам по себе является злонамеренным.
Далее будут обсуждены потенциальные проблемы безопасности в соответствии с этими двумя моделями угроз.
2.1 Проблемы безопасности в модели угроз I
Модель угроз I сосредоточена на уязвимостях, связанных с самим Hook. Эта модель угроз предполагает, что разработчик и его Hook не имеют злых намерений. Однако известные уязвимости существующих смарт-контрактов также могут проявляться в Hook. Например, если Hook реализован как обновляемый контракт, он может столкнуться с проблемами, связанными с уязвимостью UUPSUpgradeable от OpenZeppelin.
Учитывая вышеизложенные факторы, мы решили сосредоточиться на потенциальных уязвимостях, характерных для версии v4. В Uniswap v4 Hook — это смарт-контракт, который может выполнять пользовательскую логику до или после выполнения операций с основным пулом (, включая инициализацию, изменение позиции, обмен и сбор ). Хотя ожидается, что Hook реализует стандартный интерфейс, он также позволяет включать пользовательскую логику. Поэтому наше обсуждение будет ограничено логикой, связанной со стандартным интерфейсом 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 хуков и обратный вызов блокировки. Конечно, есть и другие случаи, которые необходимо проверить, но эти случаи отличаются по дизайну и в настоящее время не входят в наш круг обсуждения.
Эти функции должны вызываться только PoolManager, а не другими адресами (, включая EOA и контракты ). Например, в случае, если вознаграждение распределяется с помощью ключа пула, если соответствующие функции могут быть вызваны любым аккаунтом, вознаграждение может быть неправильно получено.
Таким образом, для hook крайне важно создать надежный механизм контроля доступа, особенно учитывая, что к ним могут обращаться сторонние лица, кроме самого пула. Путем строгого управления правами доступа, ликвидный пул может значительно снизить риски несанкционированного или злонамеренного взаимодействия с hook.
2.1.2 Проблемы проверки ввода
В Uniswap v4 из-за наличия механизма блокировки пользователи должны получить lock через контракт перед выполнением любых операций с пулом ликвидности. Это гарантирует, что текущий взаимодействующий контракт является актуальным контрактом-локером.
Тем не менее, существует возможный сценарий атаки, при котором из-за ненадлежащей валидации входных данных в некоторых уязвимых реализациях Hook происходят недоверенные внешние вызовы:
Во-первых, hook не проверяет пул средств, с которым пользователь собирается взаимодействовать. Это может быть злонамеренный пул средств, содержащий поддельные токены и выполняющий вредоносную логику.
Во-вторых, некоторые ключевые функции hook позволяют произвольные внешние вызовы.
Ненадежные внешние вызовы чрезвычайно опасны, поскольку они могут привести к различным типам атак, включая хорошо известные нам атаки повторного входа.
Чтобы атаковать эти уязвимые хуки, злоумышленник может зарегистрировать злонамеренный пул ликвидности для своих поддельных токенов, а затем вызвать хуки для выполнения операций в пуле. При взаимодействии с пулом ликвидности логика злонамеренных токенов перехватывает управление потоком для совершения неправомерных действий.
2.1.3 Меры по защите от модели угроз I
Чтобы избежать подобных проблем безопасности, связанных с hook, крайне важно правильно выполнять необходимый контроль доступа к чувствительным внешним/публичным функциям и проверять входные параметры для верификации взаимодействий. Кроме того, защита от повторного входа может помочь убедиться, что hook не будет повторно выполняться в стандартном логическом процессе. Реализовав соответствующие меры безопасности, пул ликвидности может снизить риски, связанные с такими угрозами.
2.2 Проблемы безопасности в модели угроз II
В этой модели угроз мы предполагаем, что разработчик и его хуки являются злонамеренными. Учитывая широкий диапазон вовлеченности, мы сосредоточимся только на вопросах безопасности, связанных с версией v4. Поэтому ключевым моментом является то, могут ли предоставленные хуки обрабатывать зашифленные активы пользователя при переводах или авторизации.
Поскольку метод доступа к хуку определяет возможные разрешения, которые могут быть предоставлены хуку, мы разделяем хуки на два типа:
Управляемые хуки (: hook не является точкой входа. Пользователь должен взаимодействовать с hook через маршрутизатор ), который может быть предоставлен Uniswap (.
Независимые крюки)Standalone Hooks(: крюк является точкой входа, позволяя пользователям взаимодействовать с ним напрямую.
)# 2.2.1 Хостинговый Hook
В этом случае криптоактивы пользователя ### включают нативные токены и другие токены (, которые передаются или авторизованы для маршрутизатора. Поскольку PoolManager выполняет проверку баланса, злоумышленникам не так легко напрямую украсть эти активы. Тем не менее, существует потенциальная уязвимость. Например, механизм управления сборами версии v4 может быть скомпрометирован злоумышленниками через хуки.
)# 2.2.2 Независимый Hook
Когда Hook используется в качестве точки входа, ситуация становится более сложной. В этом случае, поскольку пользователи могут напрямую взаимодействовать с hook, у него появляется больше власти. Теоретически, hook может выполнять любые действия, которые он хочет, через это взаимодействие.
В версии v4 проверка логики кода является очень важной. Основная проблема заключается в том, можно ли манипулировать логикой кода. Если хук является обновляемым, это означает, что казалось бы безопасный хук может стать злонамеренным после обновления, что представляет собой значительный риск. Эти риски включают:
Апгрейдable代理### может быть подвержен прямой атаке(;
Имеет логику саморазрушения. Может быть атакован в случае совместного вызова selfdestruct и create2.
)# 2.2.3 Меры противодействия модели угроз II
Ключевым моментом является оценка того, является ли hook вредоносным. Конкретно, для управляемых hook мы должны обращать внимание на поведение управления затратами; в то время как для независимых hook основное внимание следует уделять тому, могут ли они быть обновлены.
![Почему Hook называют "двуострым мечом" Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Вывод
В статье сначала кратко описываются основные механизмы, связанные с проблемами безопасности Hook в Uniswap v4. Затем мы представляем две модели угроз и кратко излагаем связанные с ними риски безопасности.
В последующих статьях мы проведем глубокий анализ вопросов безопасности в каждом из моделей угроз.