Скорый запуск 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, разделённых на четыре группы (, каждая группа содержит пару обратных вызовов ):
передИнициализацией/послеИнициализации
beforeModifyPosition/afterModifyPosition
передОбменом/послеОбмена
передПожертвованием/послеПожертвования
Синглтон, молниеносная бухгалтерия и механизм блокировки
Синглтон-архитектура и молниеносная бухгалтерия направлены на повышение производительности за счет снижения затрат и обеспечения эффективности. Она вводит новый синглтон-контракт, где все ликвидные пулы хранятся в одном и том же смарт-контракте. Этот синглтон-дизайн полагается на PoolManager для хранения и управления состоянием всех пулов.
Версия v4 вводит механизм молниеносной бухгалтерии и блокировки. Механизм блокировки работает следующим образом:
контракт locker запрашивает lock в PoolManager.
PoolManager добавляет адрес этого контракта locker в очередь lockData и вызывает его обратный вызов lockAcquired.
Контракт locker выполняет свою логику в колбэке. В процессе выполнения взаимодействие контракта locker с пулом может привести к ненулевому увеличению валюты. Однако по окончании выполнения все увеличения должны быть урегулированы до нуля. Кроме того, если очередь lockData не пуста, только последний контракт locker может выполнять операции.
PoolManager проверяет состояние очереди lockData и приростов валюты. После проверки PoolManager удалит этот контракт locker.
В общем, механизм блокировки предотвращает одновременный доступ и гарантирует, что все транзакции могут быть урегулированы. Контракт locker запрашивает lock по порядку, а затем выполняет транзакцию через коллбек lockAcquired. Каждый раз перед и после операции в пуле будут вызваны соответствующие коллбеки Hook. Наконец, PoolManager проверит состояние.
Этот метод означает, что операции корректируют внутренний чистый баланс (, а именно дельту ), а не выполняют моментальный перевод. Любые изменения будут записаны во внутреннем балансе пула, фактический перевод будет осуществлен по окончании операции (, а именно lock ). Этот процесс гарантирует отсутствие непогашенных токенов, тем самым поддерживая целостность средств.
Из-за существования механизма блокировки, все внешние учетные записи (EOA) не могут напрямую взаимодействовать с PoolManager. Вместо этого любое взаимодействие должно проходить через контракт. Этот контракт выступает в качестве промежуточного блокировщика и перед выполнением любых операций с пулом необходимо запрашивать блокировку.
Существует два основных сценария взаимодействия с контрактами:
locker контракт поступает из официального репозитория кода или развернут пользователем. В этом случае мы можем рассматривать взаимодействие как осуществляемое через маршрутизатор.
интеграция контракта locker и Hook в один и тот же контракт или контроль со стороны третьих лиц. В этом случае мы можем рассматривать взаимодействие как осуществляемое через Hook. В этом случае Hook выполняет как роль контракта locker, так и отвечает за обработку обратных вызовов.
Модель угроз
Перед обсуждением связанных с безопасностью вопросов нам необходимо определить модель угроз. Основное внимание уделяется следующим двум ситуациям:
Модель угроз I: Hook сам по себе является благожелательным, но содержит уязвимости.
Модель угроз II: сам Hook является злонамеренным.
В следующей части мы обсудим потенциальные проблемы безопасности в соответствии с этими двумя моделями угроз.
Проблемы безопасности в модели угроз I
Модель угроз I сосредоточена на уязвимостях, связанных с самим Hook. Эта модель угроз предполагает, что разработчик и его Hook не являются злонамеренными. Однако известные уязвимости в смарт-контрактах также могут появляться в Hook.
Мы выбираем сосредоточиться на потенциальных уязвимостях, специфичных для версии v4. В Uniswap v4 Hook — это смарт-контракт, который может выполнять пользовательскую логику до или после выполнения операций в основном пуле, включая инициализацию, изменение позиции, обмен и сбор (. Хотя ожидается, что Hook будет реализовывать стандартный интерфейс, он также позволяет включать пользовательскую логику. Таким образом, наш круг обсуждения будет ограничен логикой, связанной со стандартным интерфейсом Hook. Затем мы постараемся выяснить возможные источники уязвимостей, например, как Hook может злоупотреблять этими стандартными функциями Hook.
Конкретно, мы сосредоточим внимание на следующих двух Hook:
Первый тип хука, хранение средств пользователей. В этом случае злоумышленник может атаковать этот хук для перевода средств, что приведет к потере активов.
Второй вид хука, который хранит критически важные данные состояния, зависящие от пользователей или других протоколов. В этом случае злоумышленник может попытаться изменить критическое состояние. Когда другие пользователи или протоколы используют ошибочное состояние, это может привести к потенциальным рискам.
После глубокого изучения репозитория Awesome Uniswap v4 Hooks мы обнаружили несколько серьезных уязвимостей. Эти уязвимости в основном исходят от взаимодействия рисков между hook, PoolManager и внешними третьими сторонами и могут быть в основном разделены на два типа: проблемы контроля доступа и проблемы валидации ввода.
В общем, мы обнаружили 22 связанных проекта ), исключив проекты, не связанные с Uniswap v4 (. Среди этих проектов мы считаем, что 8 из )36%( имеют уязвимости. Из этих 8 уязвимых проектов 6 имеют проблемы с контролем доступа, а 2 подвержены ненадежным внешним вызовам.
)# Проблема контроля доступа
В этой части обсуждения мы в основном сосредоточимся на проблемах, которые могут быть вызваны функциями обратного вызова в v4, включая 8 хуков и блокировочные обратные вызовы. Эти функции должны вызываться только PoolManager и не могут вызываться другими адресами ###, включая EOA и контракт (. Например, в случае, если вознаграждение распределяется с помощью ключа пула, если соответствующая функция может быть вызвана любым аккаунтом, то вознаграждение может быть ошибочно получено.
Таким образом, для hook крайне важно создать надежный механизм контроля доступа, особенно учитывая, что к ним могут обращаться другие стороны, помимо самого пула. Путем строгого управления правами доступа, ликвидные пулы могут значительно снизить риски, связанные с несанкционированным или злонамеренным взаимодействием с hook.
)# Вопросы верификации ввода
В Uniswap v4, из-за наличия механизма блокировки, пользователи должны получить lock через контракт перед выполнением любых операций с пулом средств. Это гарантирует, что текущий участвующий в взаимодействии контракт является последним контрактом-локером.
Тем не менее, существует возможный сценарий атаки, связанный с недостоверными внешними вызовами, вызванными неправильной проверкой входных данных в некоторых уязвимых реализациях Hook:
Во-первых, hook не проверяет пул ликвидности, с которым пользователь собирается взаимодействовать. Это может быть злонамеренный пул с поддельными токенами и вредоносной логикой.
Во-вторых, некоторые ключевые функции hook позволяют произвольные внешние вызовы.
Неавторизованные внешние вызовы крайне опасны, так как могут привести к различным типам атак, включая известные нам атаки повторного входа.
Чтобы атаковать эти уязвимые хуки, атакующий может зарегистрировать злонамеренный пул ликвидности для своих поддельных токенов, а затем вызвать хуки для выполнения операций в пуле. При взаимодействии с пулом ликвидности логика злонамеренных токенов перехватывает поток управления для совершения недобросовестных действий.
Меры по защите от угроз модели I
Чтобы избежать таких проблем с безопасностью, связанных с hook, крайне важно выполнять необходимый контроль доступа к чувствительным внешним/публичным функциям и проверять входные параметры для валидации взаимодействий. Кроме того, защита от повторного входа может помочь гарантировать, что hook не будет повторно выполнен в стандартном логическом процессе. Реализуя соответствующие меры безопасности, пул средств может снизить риски, связанные с такими угрозами.
Проблемы безопасности в модели угроз II
В этой модели угроз мы предполагаем, что разработчик и его хуки являются злонамеренными. Учитывая широкий круг вопросов, мы сосредоточимся только на проблемах безопасности, связанных с версией v4. Таким образом, ключевым моментом является то, может ли предоставленный хук обрабатывать криптоактивы, переведенные или авторизованные пользователем.
Поскольку методы доступа к хуку определяют возможные права, которые могут быть предоставлены хуку, мы разделяем хуки на две категории:
Управляемые хуки###Managed Hooks(: хуки не являются точкой входа. Пользователи должны взаимодействовать с хуками через маршрутизатор), который может быть предоставлен Uniswap(.
Независимые крюки ) Standalone Hooks (: крюк является точкой входа, позволяя пользователям взаимодействовать с ним напрямую.
)# Хук с управлением
В этом случае криптоактивы пользователя ###, включая нативные токены и другие токены (, передаются или авторизуются для маршрутизатора. Поскольку PoolManager выполняет проверку баланса, злонамеренные хуки не могут легко украсть эти активы напрямую. Тем не менее, все еще существуют потенциальные уязвимости. Например, механизм управления комиссиями версии v4 может быть подвержен манипуляциям со стороны злоумышленников через хуки.
)# Независимый Hook
Когда Hook используется в качестве точки входа, ситуация становится более сложной. В этом случае, поскольку пользователи могут взаимодействовать с hook напрямую, hook получает больше власти. Теоретически, hook может выполнять любое действие, которое он хочет, через это взаимодействие.
В версии v4 проверка логики кода является очень важной. Основная проблема заключается в том, можно ли манипулировать логикой кода. Если хук можно обновлять, это означает, что на первый взгляд безопасный хук может стать вредоносным после обновления, что представляет собой серьезный риск. Эти риски включают:
Модернизируемый агент ### может быть подвергнут прямой атаке (;
С логикой самоуничтожения. Может быть атакован в случае совместного вызова selfdestruct и create2.
)# Меры предосторожности против модели угроз II
Ключевым моментом является оценка того, является ли hook злонамеренным. В частности, для управляемых hook мы должны обратить внимание на поведение управления расходами; а для независимых hook основное внимание уделяется тому, можно ли их обновить.
![Почему Hook называют "двусторонним мечом" Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Заключение
В данной статье кратко описываются ключевые механизмы, связанные с проблемами безопасности 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, разделённых на четыре группы (, каждая группа содержит пару обратных вызовов ):
Синглтон, молниеносная бухгалтерия и механизм блокировки
Синглтон-архитектура и молниеносная бухгалтерия направлены на повышение производительности за счет снижения затрат и обеспечения эффективности. Она вводит новый синглтон-контракт, где все ликвидные пулы хранятся в одном и том же смарт-контракте. Этот синглтон-дизайн полагается на PoolManager для хранения и управления состоянием всех пулов.
Версия v4 вводит механизм молниеносной бухгалтерии и блокировки. Механизм блокировки работает следующим образом:
контракт locker запрашивает lock в PoolManager.
PoolManager добавляет адрес этого контракта locker в очередь lockData и вызывает его обратный вызов lockAcquired.
Контракт locker выполняет свою логику в колбэке. В процессе выполнения взаимодействие контракта locker с пулом может привести к ненулевому увеличению валюты. Однако по окончании выполнения все увеличения должны быть урегулированы до нуля. Кроме того, если очередь lockData не пуста, только последний контракт locker может выполнять операции.
PoolManager проверяет состояние очереди lockData и приростов валюты. После проверки PoolManager удалит этот контракт locker.
В общем, механизм блокировки предотвращает одновременный доступ и гарантирует, что все транзакции могут быть урегулированы. Контракт locker запрашивает lock по порядку, а затем выполняет транзакцию через коллбек lockAcquired. Каждый раз перед и после операции в пуле будут вызваны соответствующие коллбеки Hook. Наконец, PoolManager проверит состояние.
Этот метод означает, что операции корректируют внутренний чистый баланс (, а именно дельту ), а не выполняют моментальный перевод. Любые изменения будут записаны во внутреннем балансе пула, фактический перевод будет осуществлен по окончании операции (, а именно lock ). Этот процесс гарантирует отсутствие непогашенных токенов, тем самым поддерживая целостность средств.
Из-за существования механизма блокировки, все внешние учетные записи (EOA) не могут напрямую взаимодействовать с PoolManager. Вместо этого любое взаимодействие должно проходить через контракт. Этот контракт выступает в качестве промежуточного блокировщика и перед выполнением любых операций с пулом необходимо запрашивать блокировку.
Существует два основных сценария взаимодействия с контрактами:
locker контракт поступает из официального репозитория кода или развернут пользователем. В этом случае мы можем рассматривать взаимодействие как осуществляемое через маршрутизатор.
интеграция контракта locker и Hook в один и тот же контракт или контроль со стороны третьих лиц. В этом случае мы можем рассматривать взаимодействие как осуществляемое через Hook. В этом случае Hook выполняет как роль контракта locker, так и отвечает за обработку обратных вызовов.
Модель угроз
Перед обсуждением связанных с безопасностью вопросов нам необходимо определить модель угроз. Основное внимание уделяется следующим двум ситуациям:
Модель угроз I: Hook сам по себе является благожелательным, но содержит уязвимости.
Модель угроз II: сам Hook является злонамеренным.
В следующей части мы обсудим потенциальные проблемы безопасности в соответствии с этими двумя моделями угроз.
Проблемы безопасности в модели угроз I
Модель угроз I сосредоточена на уязвимостях, связанных с самим Hook. Эта модель угроз предполагает, что разработчик и его Hook не являются злонамеренными. Однако известные уязвимости в смарт-контрактах также могут появляться в Hook.
Мы выбираем сосредоточиться на потенциальных уязвимостях, специфичных для версии v4. В Uniswap v4 Hook — это смарт-контракт, который может выполнять пользовательскую логику до или после выполнения операций в основном пуле, включая инициализацию, изменение позиции, обмен и сбор (. Хотя ожидается, что Hook будет реализовывать стандартный интерфейс, он также позволяет включать пользовательскую логику. Таким образом, наш круг обсуждения будет ограничен логикой, связанной со стандартным интерфейсом Hook. Затем мы постараемся выяснить возможные источники уязвимостей, например, как Hook может злоупотреблять этими стандартными функциями Hook.
Конкретно, мы сосредоточим внимание на следующих двух Hook:
Первый тип хука, хранение средств пользователей. В этом случае злоумышленник может атаковать этот хук для перевода средств, что приведет к потере активов.
Второй вид хука, который хранит критически важные данные состояния, зависящие от пользователей или других протоколов. В этом случае злоумышленник может попытаться изменить критическое состояние. Когда другие пользователи или протоколы используют ошибочное состояние, это может привести к потенциальным рискам.
После глубокого изучения репозитория Awesome Uniswap v4 Hooks мы обнаружили несколько серьезных уязвимостей. Эти уязвимости в основном исходят от взаимодействия рисков между hook, PoolManager и внешними третьими сторонами и могут быть в основном разделены на два типа: проблемы контроля доступа и проблемы валидации ввода.
В общем, мы обнаружили 22 связанных проекта ), исключив проекты, не связанные с Uniswap v4 (. Среди этих проектов мы считаем, что 8 из )36%( имеют уязвимости. Из этих 8 уязвимых проектов 6 имеют проблемы с контролем доступа, а 2 подвержены ненадежным внешним вызовам.
)# Проблема контроля доступа
В этой части обсуждения мы в основном сосредоточимся на проблемах, которые могут быть вызваны функциями обратного вызова в v4, включая 8 хуков и блокировочные обратные вызовы. Эти функции должны вызываться только PoolManager и не могут вызываться другими адресами ###, включая EOA и контракт (. Например, в случае, если вознаграждение распределяется с помощью ключа пула, если соответствующая функция может быть вызвана любым аккаунтом, то вознаграждение может быть ошибочно получено.
Таким образом, для hook крайне важно создать надежный механизм контроля доступа, особенно учитывая, что к ним могут обращаться другие стороны, помимо самого пула. Путем строгого управления правами доступа, ликвидные пулы могут значительно снизить риски, связанные с несанкционированным или злонамеренным взаимодействием с hook.
)# Вопросы верификации ввода
В Uniswap v4, из-за наличия механизма блокировки, пользователи должны получить lock через контракт перед выполнением любых операций с пулом средств. Это гарантирует, что текущий участвующий в взаимодействии контракт является последним контрактом-локером.
Тем не менее, существует возможный сценарий атаки, связанный с недостоверными внешними вызовами, вызванными неправильной проверкой входных данных в некоторых уязвимых реализациях Hook:
Во-первых, hook не проверяет пул ликвидности, с которым пользователь собирается взаимодействовать. Это может быть злонамеренный пул с поддельными токенами и вредоносной логикой.
Во-вторых, некоторые ключевые функции hook позволяют произвольные внешние вызовы.
Неавторизованные внешние вызовы крайне опасны, так как могут привести к различным типам атак, включая известные нам атаки повторного входа.
Чтобы атаковать эти уязвимые хуки, атакующий может зарегистрировать злонамеренный пул ликвидности для своих поддельных токенов, а затем вызвать хуки для выполнения операций в пуле. При взаимодействии с пулом ликвидности логика злонамеренных токенов перехватывает поток управления для совершения недобросовестных действий.
Меры по защите от угроз модели I
Чтобы избежать таких проблем с безопасностью, связанных с hook, крайне важно выполнять необходимый контроль доступа к чувствительным внешним/публичным функциям и проверять входные параметры для валидации взаимодействий. Кроме того, защита от повторного входа может помочь гарантировать, что hook не будет повторно выполнен в стандартном логическом процессе. Реализуя соответствующие меры безопасности, пул средств может снизить риски, связанные с такими угрозами.
Проблемы безопасности в модели угроз II
В этой модели угроз мы предполагаем, что разработчик и его хуки являются злонамеренными. Учитывая широкий круг вопросов, мы сосредоточимся только на проблемах безопасности, связанных с версией v4. Таким образом, ключевым моментом является то, может ли предоставленный хук обрабатывать криптоактивы, переведенные или авторизованные пользователем.
Поскольку методы доступа к хуку определяют возможные права, которые могут быть предоставлены хуку, мы разделяем хуки на две категории:
Управляемые хуки###Managed Hooks(: хуки не являются точкой входа. Пользователи должны взаимодействовать с хуками через маршрутизатор), который может быть предоставлен Uniswap(.
Независимые крюки ) Standalone Hooks (: крюк является точкой входа, позволяя пользователям взаимодействовать с ним напрямую.
)# Хук с управлением
В этом случае криптоактивы пользователя ###, включая нативные токены и другие токены (, передаются или авторизуются для маршрутизатора. Поскольку PoolManager выполняет проверку баланса, злонамеренные хуки не могут легко украсть эти активы напрямую. Тем не менее, все еще существуют потенциальные уязвимости. Например, механизм управления комиссиями версии v4 может быть подвержен манипуляциям со стороны злоумышленников через хуки.
)# Независимый Hook
Когда Hook используется в качестве точки входа, ситуация становится более сложной. В этом случае, поскольку пользователи могут взаимодействовать с hook напрямую, hook получает больше власти. Теоретически, hook может выполнять любое действие, которое он хочет, через это взаимодействие.
В версии v4 проверка логики кода является очень важной. Основная проблема заключается в том, можно ли манипулировать логикой кода. Если хук можно обновлять, это означает, что на первый взгляд безопасный хук может стать вредоносным после обновления, что представляет собой серьезный риск. Эти риски включают:
Модернизируемый агент ### может быть подвергнут прямой атаке (;
С логикой самоуничтожения. Может быть атакован в случае совместного вызова selfdestruct и create2.
)# Меры предосторожности против модели угроз II
Ключевым моментом является оценка того, является ли hook злонамеренным. В частности, для управляемых hook мы должны обратить внимание на поведение управления расходами; а для независимых hook основное внимание уделяется тому, можно ли их обновить.
![Почему Hook называют "двусторонним мечом" Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Заключение
В данной статье кратко описываются ключевые механизмы, связанные с проблемами безопасности Hook в Uniswap v4, предлагаются две модели угроз и обобщаются связанные с ними риски безопасности.
В последующих статьях мы проведем глубокий анализ проблем безопасности в каждой модели угроз.