Uniswap v4 скоро будет запущен, это обновление вводит множество новых функций, включая поддержку неограниченного количества пулов ликвидности для каждой торговой пары и динамических сборов, единую архитектуру, мгновенные расчеты, механизм Hook и поддержку стандарта токенов ERC1155. Среди них механизм Hook привлек широкое внимание благодаря своему мощному потенциалу.
Механизм Hook позволяет выполнять пользовательский код в определенные моменты жизненного цикла пула ликвидности, значительно увеличивая масштабируемость и гибкость пула. Однако механизм Hook также может быть двусторонним мечом. Хотя он мощный и гибкий, безопасное использование Hook также представляет собой немалую задачу. Сложность Hook неизбежно приводит к новым потенциальным вектором атак.
В этой статье будут представлены связанные с механизмом Hook концепции в Uniswap v4 и описаны существующие риски безопасности.
Основная механика Uniswap v4
Перед углубленным обсуждением нам нужно иметь базовое понимание механизмов Uniswap v4. Согласно официальному объявлению и белой книге, Hook, одиночная архитектура и молниеносное бухгалтерское учёт являются тремя важными функциями для реализации настраиваемых ликвидных пулов и эффективной маршрутизации через несколько пулов.
Механизм Hook
Hook - это контракты, которые работают на разных стадиях жизненного цикла ликвидных пулов, предназначенные для того, чтобы любой мог принимать взвешенные решения. Таким образом, можно реализовать нативную поддержку динамических сборов, добавление лимитных ордеров на цепочке или распределение крупных заказов через временно-взвешенного маркет-мейкера (TWAMM).
В настоящее время имеется восемь колбеков Hook, разделенных на четыре группы (, каждая группа содержит одну пару колбеков ):
beforeInitialize/afterInitialize
передИзменениемПозиции/послеИзмененияПозиции
до_обмена/после_обмена
передПожертвованием/послеПожертвования
Синглтон, молниеносная бухгалтерия и механизм блокировки
Архитектура с singleton и мгновенное бухгалтерское учёт направлены на повышение производительности за счёт снижения затрат и обеспечения эффективности. Она вводит новый контракт singleton, в котором все ликвидные пулы хранятся в одном и том же смарт-контракте. Этот дизайн singleton полагается на PoolManager для хранения и управления состоянием всех пулов.
Версия v4 вводит механизмы молниеносного учета и блокировки. Механизм блокировки работает следующим образом:
контракт locker запрашивает блокировку на 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, PoolManager и внешними третьими сторонами, которые можно разделить на две категории: проблемы контроля доступа и проблемы валидации ввода.
Проблемы с контролем доступа
Обратные функции в v4 могут вызвать проблемы, включая 8 хуков и блокировочные обратные вызовы. Эти функции должны вызываться только PoolManager и не должны вызываться другими адресами. Для хуков крайне важно установить надежный механизм контроля доступа, особенно потому, что ими могут вызывать другие стороны, кроме самого пула.
Вопросы проверки ввода
Несмотря на наличие механизма блокировки, существует потенциальная угроза атаки, связанная с ненадежными внешними вызовами, возникающими из-за недостаточной проверки входных данных в некоторых уязвимых реализациях Hook:
Hook не проверяет пул ликвидности, с которым пользователь намеревается взаимодействовать. Это может быть вредоносный пул с фальшивыми токенами и вредоносной логикой.
Некоторые ключевые функции Hook позволяют произвольные внешние вызовы.
Недоверительные внешние вызовы крайне опасны и могут привести к различным типам атак, включая атаки повторного входа.
Меры предосторожности
Чтобы избежать подобных проблем с безопасностью, связанных с Hook, крайне важно правильно выполнять необходимый контроль доступа к чувствительным внешним/публичным функциям и проверять входные параметры для верификации взаимодействия. Кроме того, защита от повторного входа может помочь гарантировать, что Hook не будет повторно выполнен в стандартном логическом процессе.
Проблемы безопасности в модели угроз II
В этой модели угроз мы предполагаем, что разработчик и его Hook являются злонамеренными. Ключевым моментом является то, сможет ли предоставленный Hook обрабатывать криптоактивы, передаваемые пользователем или авторизованные им.
В зависимости от метода доступа к Hook, мы делим Hook на два типа:
Хостинговый Hook: Hook не является точкой входа. Пользователи должны взаимодействовать с Hook через маршрутизатор.
Независимый Hook: Hook является точкой входа, позволяющей пользователям взаимодействовать непосредственно с ним.
Хук с управлением
Криптоактивы пользователя были переведены или авторизованы для маршрутизатора. Поскольку PoolManager выполняет проверку баланса, злоумышленникам не легко напрямую украсть эти активы. Тем не менее, существует потенциальная угроза, например, механизм управления комиссиями версии v4 может быть манипулирован злоумышленниками через Hook.
Независимый Hook
Когда Hook используется в качестве точки входа, ситуация становится более сложной. Hook получает больше власти и теоретически может выполнять любые операции через это взаимодействие.
В версии v4 проверка логики кода имеет большое значение. Основная проблема заключается в том, можно ли манипулировать логикой кода. Если Hook можно обновлять, это означает, что на первый взгляд безопасный Hook может стать вредоносным после обновления, что создает серьезные риски. Эти риски включают в себя:
Уязвимый прокси ( может быть атакован напрямую )
Имеет логику самоуничтожения. Может быть атакован в случае совместного вызова selfdestruct и create2.
Меры предосторожности
Ключевым моментом является оценка того, является ли Hook вредоносным. Конкретно, для управляемых Hook мы должны сосредоточиться на поведении управления расходами; а для независимых Hook основной акцент следует делать на том, можно ли их обновить.
Заключение
Данная статья кратко описывает основные механизмы, связанные с проблемами безопасности 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, разделенных на четыре группы (, каждая группа содержит одну пару колбеков ):
Синглтон, молниеносная бухгалтерия и механизм блокировки
Архитектура с singleton и мгновенное бухгалтерское учёт направлены на повышение производительности за счёт снижения затрат и обеспечения эффективности. Она вводит новый контракт singleton, в котором все ликвидные пулы хранятся в одном и том же смарт-контракте. Этот дизайн singleton полагается на PoolManager для хранения и управления состоянием всех пулов.
Версия v4 вводит механизмы молниеносного учета и блокировки. Механизм блокировки работает следующим образом:
контракт locker запрашивает блокировку на PoolManager.
PoolManager добавляет адрес этого контракта locker в очередь lockData и вызывает его обратный вызов lockAcquired.
Контракт locker выполняет свою логику в обратном вызове. В процессе выполнения взаимодействие с пулом может привести к ненулевому увеличению валюты, но по завершении выполнения все увеличения должны быть урегулированы до нуля.
PoolManager проверяет состояние очереди lockData и прирост валюты. После проверки удаляет контракт locker.
В целом, механизм блокировки предотвращает одновременный доступ и гарантирует, что все транзакции могут быть урегулированы. Этот подход означает, что операции корректируют внутренний чистый баланс, а не выполняют мгновенные переводы. Любые изменения будут зафиксированы во внутреннем балансе пула, в то время как фактические переводы происходят в конце операции.
Из-за существования механизма блокировки внешние все учетные записи (EOA) не могут напрямую взаимодействовать с PoolManager. Любое взаимодействие должно происходить через контракт. Существуют два основных сценария взаимодействия с контрактом:
контракт locker поступает из официальной кодовой базы или развёрнут пользователем. Эта ситуация может рассматриваться как взаимодействие через маршрутизатор.
locker контракт интегрирован с Hook в один и тот же контракт или контролируется третьими лицами. Эта ситуация может рассматриваться как взаимодействие через Hook.
Модель угроз
Перед тем как обсудить соответствующие проблемы безопасности, нам необходимо определить модель угроз. Основное внимание следует уделить следующим двум ситуациям:
Проблемы безопасности в модели угроз I
Модель угроз I сосредотачивается на уязвимостях, связанных с самим Hook. Эта модель угроз предполагает, что разработчик и его Hook не имеют злого умысла. Однако известные уязвимости существующих смарт-контрактов также могут проявляться в Hook.
Мы выбираем сосредоточиться на потенциальных уязвимостях, характерных для версии v4, в основном обращая внимание на следующие два типа Hook:
Хук для хранения пользовательских средств. Злоумышленник может атаковать этот Хук, чтобы перевести средства, что приведет к потере активов.
Хук для хранения ключевых статусных данных, на которые полагаются пользователи или другие протоколы. Злоумышленники могут попытаться изменить ключевой статус, что может привести к потенциальным рискам, когда другие пользователи или протоколы используют ошибочный статус.
В ходе исследования мы выявили несколько серьезных уязвимостей, которые в основном связаны с рисковыми взаимодействиями между Hook, PoolManager и внешними третьими сторонами, которые можно разделить на две категории: проблемы контроля доступа и проблемы валидации ввода.
Проблемы с контролем доступа
Обратные функции в v4 могут вызвать проблемы, включая 8 хуков и блокировочные обратные вызовы. Эти функции должны вызываться только PoolManager и не должны вызываться другими адресами. Для хуков крайне важно установить надежный механизм контроля доступа, особенно потому, что ими могут вызывать другие стороны, кроме самого пула.
Вопросы проверки ввода
Несмотря на наличие механизма блокировки, существует потенциальная угроза атаки, связанная с ненадежными внешними вызовами, возникающими из-за недостаточной проверки входных данных в некоторых уязвимых реализациях Hook:
Hook не проверяет пул ликвидности, с которым пользователь намеревается взаимодействовать. Это может быть вредоносный пул с фальшивыми токенами и вредоносной логикой.
Некоторые ключевые функции Hook позволяют произвольные внешние вызовы.
Недоверительные внешние вызовы крайне опасны и могут привести к различным типам атак, включая атаки повторного входа.
Меры предосторожности
Чтобы избежать подобных проблем с безопасностью, связанных с Hook, крайне важно правильно выполнять необходимый контроль доступа к чувствительным внешним/публичным функциям и проверять входные параметры для верификации взаимодействия. Кроме того, защита от повторного входа может помочь гарантировать, что Hook не будет повторно выполнен в стандартном логическом процессе.
Проблемы безопасности в модели угроз II
В этой модели угроз мы предполагаем, что разработчик и его Hook являются злонамеренными. Ключевым моментом является то, сможет ли предоставленный Hook обрабатывать криптоактивы, передаваемые пользователем или авторизованные им.
В зависимости от метода доступа к Hook, мы делим Hook на два типа:
Хостинговый Hook: Hook не является точкой входа. Пользователи должны взаимодействовать с Hook через маршрутизатор.
Независимый Hook: Hook является точкой входа, позволяющей пользователям взаимодействовать непосредственно с ним.
Хук с управлением
Криптоактивы пользователя были переведены или авторизованы для маршрутизатора. Поскольку PoolManager выполняет проверку баланса, злоумышленникам не легко напрямую украсть эти активы. Тем не менее, существует потенциальная угроза, например, механизм управления комиссиями версии v4 может быть манипулирован злоумышленниками через Hook.
Независимый Hook
Когда Hook используется в качестве точки входа, ситуация становится более сложной. Hook получает больше власти и теоретически может выполнять любые операции через это взаимодействие.
В версии v4 проверка логики кода имеет большое значение. Основная проблема заключается в том, можно ли манипулировать логикой кода. Если Hook можно обновлять, это означает, что на первый взгляд безопасный Hook может стать вредоносным после обновления, что создает серьезные риски. Эти риски включают в себя:
Меры предосторожности
Ключевым моментом является оценка того, является ли Hook вредоносным. Конкретно, для управляемых Hook мы должны сосредоточиться на поведении управления расходами; а для независимых Hook основной акцент следует делать на том, можно ли их обновить.
Заключение
Данная статья кратко описывает основные механизмы, связанные с проблемами безопасности Hook в Uniswap v4, и предлагает две модели угроз и связанные с ними риски безопасности. Хотя механизм Hook обладает мощными функциями, он также приносит новые проблемы безопасности. Разработчики и пользователи должны полностью осознавать эти потенциальные риски и принимать соответствующие меры предосторожности, чтобы обеспечить безопасность активов при использовании Uniswap v4.