Анализ Hook в Uniswap v4: Архитектура, распространенные уязвимости и практика защиты
С момента запуска Uniswap v4 механизм Hook стал одной из самых заметных инноваций в DeFi. Он позволяет разработчикам привязывать пользовательские смарт-контракты к ключевым событиям жизненного цикла пулов ликвидности (своп, добавление/удаление ликвидности, инициализация), встраивая произвольную логику.
Основные изменения в v4 включают: Singleton (единый контракт PoolManager для всех пулов), flash accounting (промежуточный учёт изменений) и неизменяемую привязку Hook к пулу. Безопасность каждого пула теперь зависит от его Hook, смещая модель доверия с уровня протокола на уровень отдельного пула.
Архитектура основана на модели unlock/callback в PoolManager. Hook-контракты развертываются с помощью CREATE2, чтобы их адрес имел определённые битовые флаги, указывающие, какие функции обратного вызова (например, beforeSwap) будет вызывать PoolManager. Критически важно, чтобы эти флаги соответствовали фактической реализации контракта.
Ключевые уязвимости включают: отсутствие контроля доступа к функциям обратного вызова (BaseHook по умолчанию защищает только unlockCallback), возможность привязки одного Hook к нежелательным пулам, ошибки в знаках или подстановке токенов при работе с Delta, а также риски, присущие асинхронным Hook, которые полностью заменяют логику свопа Uniswap своей. Механизм учёта Delta гарантирует только конечный баланс (NonzeroDeltaCount == 0), но не корректность состояния.
Атака на Cork Protocol показала, что безопасность Hook требует аудита не как отдельного контракта, а как целого подпротокола с учётом всех взаимодействий. Разработчики должны явно реализовывать контроль доступа, валидацию пулов и аккуратно управлять Delta.
marsbit06/22 08:07
