Uniswap v4 представляет хуки, позволяющие разработчикам настраивать поведение пулов, такое как динамические комиссии и внешние интеграции. Это перекладывает ответственность за безопасность на код приложений и хуков, как показали эксплойты Cork и Bunni на общую сумму более 20 миллионов долларов. Эти эксплойты возникли из-за логики на уровне приложений, а не из-за недостатков основного протокола Uniswap v4. Анализ аудитов выявил семь распространенных паттернов сбоев в коде хуков.PoolManager теперь хранит все состояние пула, а хуки действуют как независимые контракты, выполняющиеся в определенные моменты жизненного цикла. Идентификатор пула включает адрес его хука, что означает, что доверие неверному PoolKey влияет на пул, с которым происходит взаимодействие. Сессионная модель, аналогичная флэш-кредитам, гарантирует, что изменения валюты обнуляются к концу транзакции. Разработчики хуков должны проверять предположения, включая авторизацию вызывающего абонента, легитимные пулы, пользовательский учет и безопасность внешних интеграций.Критический сбой заключается в отсутствии проверки вызывающих абонентов, что позволяет напрямую совершать вредоносные вызовы функций хуков. Использование BaseHook и SafeCallback, а также onlyPoolManager, помогает обеспечить проверку вызывающих абонентов. Другая проблема заключается в том, что любой пул считается легитимным; хуки должны быть привязаны к каноническим пулам или поддерживать белый список и повторно проверять PoolIds. Ошибки в пользовательском учете могут незаметно привести к утечке средств, поскольку при расчете проверяются только общие изменения, а не точность внутреннего учета хука.Разработчики должны размещать логику в соответствующем хуке для предполагаемого состояния, поскольку beforeSwap использует данные до обмена, а afterSwap — данные после обмена. Сам адрес хука кодирует разрешения; разработчики должны синхронизировать эти биты с реализованными функциями, чтобы избежать ошибок. Наконец, сбои хуков могут блокировать действия пула; критически важная логика не должна откатываться и блокировать пользовательские потоки, а внешние зависимости должны обрабатываться осторожно, чтобы предотвратить отказ в обслуживании.
onlyPoolManager, помогает обеспечить проверку вызывающих абонентов. Другая проблема заключается в том, что любой пул считается легитимным; хуки должны быть привязаны к каноническим пулам или поддерживать белый список и повторно проверять PoolIds. Ошибки в пользовательском учете могут незаметно привести к утечке средств, поскольку при расчете проверяются только общие изменения, а не точность внутреннего учета хука.Разработчики должны размещать логику в соответствующем хуке для предполагаемого состояния, посколькуbeforeSwapиспользует данные до обмена, аafterSwap— данные после обмена. Сам адрес хука кодирует разрешения; разработчики должны синхронизировать эти биты с реализованными функциями, чтобы избежать ошибок. Наконец, сбои хуков могут блокировать действия пула; критически важная логика не должна откатываться и блокировать пользовательские потоки, а внешние зависимости должны обрабатываться осторожно, чтобы предотвратить отказ в обслуживании.