Хуки: мощный инструмент для расширения функциональности приложений
Hooks — это способ программирования, который позволяет разработчикам вставлять пользовательский код в процессе выполнения системы. С помощью предопределенных функций или кодовых блоков разработчики могут расширять и настраивать поведение приложений, не изменяя исходный код. Этот подход широко применяется в операционных системах, фреймворках, библиотеках, веб-разработке и системах плагинов.
Использование Hooks может значительно повысить масштабируемость и гибкость программы. Разработчикам не нужно вносить большие изменения в существующий код при каждом изменении функциональности, что позволяет сохранить чистоту и стабильность кода. Этот элегантный механизм расширения делает Hooks незаменимой моделью программирования в дизайне программного обеспечения.
Стоит отметить, что аспектно-ориентированное программирование (AOP) часто сравнивают с Hook-программированием. AOP направлено на модульное управление сквозными аспектами, его цель также состоит в том, чтобы улучшить или изменить функции без ущерба для основной бизнес-логики. AOP можно рассматривать как более высокоуровневую абстракцию Hook-программирования.
Uniswap V4: Революция Hooks
В июне 2023 года Uniswap выпустил черновик белой книги V4, в которой самым заметным является введение механизма Hooks.
На самом деле, Hooks уже широко применяются в традиционных финансовых системах, в основном для удовлетворения требований высокой настройки и масштабируемости. Например, в процессе обработки транзакций можно вставить дополнительную логику проверки, такую как двухфакторная аутентификация, контроль рисков и стратегии по борьбе с отмыванием денег. Кроме того, Hooks могут использоваться для интеграции внешних API или микросервисов, расширяя такие функции, как аутентификация, конвертация валют и платежные шлюзы. Однако внедрение Hooks в сферу децентрализованных финансов (DeFi) безусловно было инициировано Uniswap.
Hooks в Uniswap V4 по своей сути являются внешним контрактом, который может быть связан с ликвидным пулом в момент его создания. Затем этот пул будет вызывать связанный контракт Hook на различных этапах жизненного цикла для выполнения конкретных операций, что обеспечивает очень высокий уровень настройки. Это позволяет разработчикам создавать более персонализированные торговые сценарии и функционально богатые децентрализованные приложения (DApp) на основе Hooks Uniswap.
Uniswap V4 в настоящее время поддерживает четыре группы Hook обратных вызовов, каждая группа содержит пару функций обратного вызова:
beforeInitialize/afterInitialize: используется для инициализации пула ликвидности
beforeModifyPosition/afterModifyPosition: используется для добавления, уменьшения или удаления ликвидности
beforeSwap/afterSwap: используется для обмена токенов
beforeDonate/afterDonate: используется для функции пожертвования (новая функция Uniswap V4, предоставляющая вознаграждения поставщикам ликвидности, находящимся в диапазоне торговли)
Эти хуки могут выполняться до начала и после завершения сделки, реализуя такие сложные функции, как лимитные ордера на блокчейне. Пользователи могут устанавливать лимитные ордера в контракте хуков, а затем в колбэке afterSwap определять, удовлетворяет ли цена условиям на основе пользовательских или управляемых оракулов, чтобы решить, выполнять сделку или отменить её.
С помощью Hooks Uniswap V4 тесно связывает ликвидность с развитием DApp, что не только усиливает функциональность DApp, но и укрепляет сетевой эффект Uniswap, делая его основной инфраструктурой экосистемы DeFi.
Безопасные вызовы Uniswap V4 Hooks
Некоторые специалисты по безопасности провели глубокий анализ потенциальных рисков безопасности механизма Hooks в Uniswap V4. Кроме рисков, связанных с вредоносными контрактами Hook, даже добросовестные контракты Hook могут содержать уязвимости. В ходе анализа было установлено, что более 30% проектов имеют проблемы с безопасностью. Эти уязвимости в основном обусловлены сложными взаимодействиями между Hook, PoolManager и внешними третьими сторонами, которые можно разделить на две основные категории:
Проблемы контроля доступа: В основном касаются функций обратного вызова в Uniswap V4, которые должны вызываться только PoolManager и не могут вызываться другими адресами (включая внешние учетные записи и контракты). Например, в сценарии распределения вознаграждений, если соответствующие функции могут быть вызваны произвольной учетной записью, вознаграждение может быть ошибочно получено. Поэтому для Hook крайне важно установить надежный механизм контроля доступа, особенно когда они могут быть вызваны другими сторонами, помимо пула.
Проблемы с валидацией ввода: Из-за неправильной валидации ввода в некоторых уязвимых реализациях Hook это может привести к различным типам атак, включая повторные атаки. Наиболее распространенный случай — это вызов ненадежных внешних контрактов в ключевых функциях Hook. Злоумышленник может зарегистрировать вредоносный пул ликвидности для фиктивных токенов, а затем вызвать Hook для выполнения операций в пуле ликвидности. При взаимодействии с пулом ликвидности логика вредоносных токенов может перехватить поток управления, что приведет к осуществлению неправомерных действий.
Даже если реализованы необходимые меры контроля доступа к чувствительным внешним/публичным функциям и проверены входные параметры, что снижает вышеупомянутые два типа связанных с Hook безопасностных рисков, уязвимости контракта все равно не могут быть полностью исключены. Особенно это касается случаев, когда Hook реализован как обновляемый контракт, что может привести к аналогичным проблемам с уязвимостями обновляемых контрактов, как у известной библиотеки смарт-контрактов.
Основная причина этих проблем с безопасностью заключается в том, что программирование Hook увеличивает сложность смарт-контрактов, тем самым расширяя поверхность атаки. Хотя некоторые библиотеки смарт-контрактов предоставляют лучшие практики, по сути они все равно добавляют разработчикам "ограничения безопасного использования". В отличие от обычных контрактов, контракты Hook требуют более строгих норм безопасности. Поэтому, чтобы программирование Hook стало широко распространенным, необходима комплексная структура, включая безопасную среду выполнения, подходящие для Hook программные парадигмы и более строгие ограничения на использование.
Нативный протокол определенной блокчейн-платформы: поддержка программирования Hook на уровне протокола
Учитывая, что хуки Uniswap V4 реализованы через смарт-контракты, вопросы безопасности также исходят из присущих смарт-контрактам ограничений. Существует ли решение, поддерживающее программирование хуков на уровне протокола? Коренной механизм расширения одной из блокчейн-платформ дает нам ответ.
Платформа представляет собой высокомасштабируемую и высокопроизводительную EVM-совместимую блокчейн-сеть Layer 1, специально разработанную для разработчиков для создания модульных, функционально богатых, масштабируемых и настраиваемых приложений. Платформа вводит новый тип программируемого модуля, называемого нативным модулем расширения, который инновационно внедряет аспектно-ориентированное программирование (AOP) в блокчейн-сеть.
Этот нативный расширение требует указания точки соединения, то есть места выполнения на протяжении всего жизненного цикла обработки транзакций, подобно обратному вызову Hook. Точки соединения включают:
Инициализация блока
Проверка транзакций
Перед выполнением
После выполнения
Окончательное подтверждение блока
В настоящее время это нативное расширение поддерживает только TypeScript, его код компилируется в WebAssembly (WASM) байт-код и развертывается в сети. После завершения развертывания владелец смарт-контракта может привязать контракт к нативному расширению. Владелец смарт-контракта — это учетная запись, чей внешний адрес (EOA) может быть проверен через isOwner(address) возвращает (bool).
Нативное расширение платформы реализовано в качестве хуков на уровне протокола и имеет значительные преимущества по сравнению с хуками Uniswap V4:
Во-первых, нативные расширения используют WASM для выполнения своего кода, что обеспечивает эффективность выполнения на несколько порядков выше, чем у EVM.
Во-вторых, нативное расширение может подключать весь жизненный цикл транзакции, а не только основную логику DeFi, что позволяет создавать более функциональные децентрализованные приложения.
В конце концов, и это самое важное, нативное расширение работает независимо в безопасной песочнице, что обеспечивает изоляцию и гарантирует, что выполнение расширения не повлияет на безопасность выполнения контракта.
Изолированность нативного расширения ограничивает взаимные вызовы между контрактами Hook, как обычными контрактами, так и внешними другими контрактами, эффективно решая болевые точки контроля доступа и валидации ввода в Uniswap V4 Hooks. Для таких DeFi контрактов, как Uniswap, развертывание на этой платформе позволяет наслаждаться более быстрым, мощным и безопасным опытом Hook.
Резюме
В качестве важного участника и лидера в области децентрализованных финансов, Uniswap сыграл ключевую роль в продвижении прогресса в отрасли и совершенствовании функций. Hooks, введенные в Uniswap V4, безусловно, будут указывать направление развития децентрализованных бирж и станут объектом подражания для последователей.
Тем не менее, Uniswap V4 Hooks ограничены самим умным контрактом; независимо от того, насколько тщательно спроектирован протокол и насколько совершенен инструментальный набор, он не сможет в корне предотвратить взаимные вызовы между контрактами Hook и другими внешними контрактами, что создает потенциальные риски безопасности.
Некоторая высокопроизводительная EVM-совместимая Layer 1 блокчейн-сеть с момента проектирования протокола учитывала независимый механизм расширения, работающий в WASM, обеспечивая нативную поддержку программирования Hooks, что значительно повышает безопасность. Это предоставляет продвинутое решение для децентрализованных финансовых протоколов, для которых безопасность является жизненно важной.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
15 Лайков
Награда
15
3
Поделиться
комментарий
0/400
GateUser-cff9c776
· 18ч назад
Шредингеровский крючок Повесить и не знать, рост или падение
Uniswap V4 Hooks и нативные расширения: новая глава безопасности и инноваций в Децентрализованных финансах
Хуки: мощный инструмент для расширения функциональности приложений
Hooks — это способ программирования, который позволяет разработчикам вставлять пользовательский код в процессе выполнения системы. С помощью предопределенных функций или кодовых блоков разработчики могут расширять и настраивать поведение приложений, не изменяя исходный код. Этот подход широко применяется в операционных системах, фреймворках, библиотеках, веб-разработке и системах плагинов.
Использование Hooks может значительно повысить масштабируемость и гибкость программы. Разработчикам не нужно вносить большие изменения в существующий код при каждом изменении функциональности, что позволяет сохранить чистоту и стабильность кода. Этот элегантный механизм расширения делает Hooks незаменимой моделью программирования в дизайне программного обеспечения.
Стоит отметить, что аспектно-ориентированное программирование (AOP) часто сравнивают с Hook-программированием. AOP направлено на модульное управление сквозными аспектами, его цель также состоит в том, чтобы улучшить или изменить функции без ущерба для основной бизнес-логики. AOP можно рассматривать как более высокоуровневую абстракцию Hook-программирования.
Uniswap V4: Революция Hooks
В июне 2023 года Uniswap выпустил черновик белой книги V4, в которой самым заметным является введение механизма Hooks.
На самом деле, Hooks уже широко применяются в традиционных финансовых системах, в основном для удовлетворения требований высокой настройки и масштабируемости. Например, в процессе обработки транзакций можно вставить дополнительную логику проверки, такую как двухфакторная аутентификация, контроль рисков и стратегии по борьбе с отмыванием денег. Кроме того, Hooks могут использоваться для интеграции внешних API или микросервисов, расширяя такие функции, как аутентификация, конвертация валют и платежные шлюзы. Однако внедрение Hooks в сферу децентрализованных финансов (DeFi) безусловно было инициировано Uniswap.
Hooks в Uniswap V4 по своей сути являются внешним контрактом, который может быть связан с ликвидным пулом в момент его создания. Затем этот пул будет вызывать связанный контракт Hook на различных этапах жизненного цикла для выполнения конкретных операций, что обеспечивает очень высокий уровень настройки. Это позволяет разработчикам создавать более персонализированные торговые сценарии и функционально богатые децентрализованные приложения (DApp) на основе Hooks Uniswap.
Uniswap V4 в настоящее время поддерживает четыре группы Hook обратных вызовов, каждая группа содержит пару функций обратного вызова:
Эти хуки могут выполняться до начала и после завершения сделки, реализуя такие сложные функции, как лимитные ордера на блокчейне. Пользователи могут устанавливать лимитные ордера в контракте хуков, а затем в колбэке afterSwap определять, удовлетворяет ли цена условиям на основе пользовательских или управляемых оракулов, чтобы решить, выполнять сделку или отменить её.
С помощью Hooks Uniswap V4 тесно связывает ликвидность с развитием DApp, что не только усиливает функциональность DApp, но и укрепляет сетевой эффект Uniswap, делая его основной инфраструктурой экосистемы DeFi.
Безопасные вызовы Uniswap V4 Hooks
Некоторые специалисты по безопасности провели глубокий анализ потенциальных рисков безопасности механизма Hooks в Uniswap V4. Кроме рисков, связанных с вредоносными контрактами Hook, даже добросовестные контракты Hook могут содержать уязвимости. В ходе анализа было установлено, что более 30% проектов имеют проблемы с безопасностью. Эти уязвимости в основном обусловлены сложными взаимодействиями между Hook, PoolManager и внешними третьими сторонами, которые можно разделить на две основные категории:
Проблемы контроля доступа: В основном касаются функций обратного вызова в Uniswap V4, которые должны вызываться только PoolManager и не могут вызываться другими адресами (включая внешние учетные записи и контракты). Например, в сценарии распределения вознаграждений, если соответствующие функции могут быть вызваны произвольной учетной записью, вознаграждение может быть ошибочно получено. Поэтому для Hook крайне важно установить надежный механизм контроля доступа, особенно когда они могут быть вызваны другими сторонами, помимо пула.
Проблемы с валидацией ввода: Из-за неправильной валидации ввода в некоторых уязвимых реализациях Hook это может привести к различным типам атак, включая повторные атаки. Наиболее распространенный случай — это вызов ненадежных внешних контрактов в ключевых функциях Hook. Злоумышленник может зарегистрировать вредоносный пул ликвидности для фиктивных токенов, а затем вызвать Hook для выполнения операций в пуле ликвидности. При взаимодействии с пулом ликвидности логика вредоносных токенов может перехватить поток управления, что приведет к осуществлению неправомерных действий.
Даже если реализованы необходимые меры контроля доступа к чувствительным внешним/публичным функциям и проверены входные параметры, что снижает вышеупомянутые два типа связанных с Hook безопасностных рисков, уязвимости контракта все равно не могут быть полностью исключены. Особенно это касается случаев, когда Hook реализован как обновляемый контракт, что может привести к аналогичным проблемам с уязвимостями обновляемых контрактов, как у известной библиотеки смарт-контрактов.
Основная причина этих проблем с безопасностью заключается в том, что программирование Hook увеличивает сложность смарт-контрактов, тем самым расширяя поверхность атаки. Хотя некоторые библиотеки смарт-контрактов предоставляют лучшие практики, по сути они все равно добавляют разработчикам "ограничения безопасного использования". В отличие от обычных контрактов, контракты Hook требуют более строгих норм безопасности. Поэтому, чтобы программирование Hook стало широко распространенным, необходима комплексная структура, включая безопасную среду выполнения, подходящие для Hook программные парадигмы и более строгие ограничения на использование.
Нативный протокол определенной блокчейн-платформы: поддержка программирования Hook на уровне протокола
Учитывая, что хуки Uniswap V4 реализованы через смарт-контракты, вопросы безопасности также исходят из присущих смарт-контрактам ограничений. Существует ли решение, поддерживающее программирование хуков на уровне протокола? Коренной механизм расширения одной из блокчейн-платформ дает нам ответ.
Платформа представляет собой высокомасштабируемую и высокопроизводительную EVM-совместимую блокчейн-сеть Layer 1, специально разработанную для разработчиков для создания модульных, функционально богатых, масштабируемых и настраиваемых приложений. Платформа вводит новый тип программируемого модуля, называемого нативным модулем расширения, который инновационно внедряет аспектно-ориентированное программирование (AOP) в блокчейн-сеть.
Этот нативный расширение требует указания точки соединения, то есть места выполнения на протяжении всего жизненного цикла обработки транзакций, подобно обратному вызову Hook. Точки соединения включают:
В настоящее время это нативное расширение поддерживает только TypeScript, его код компилируется в WebAssembly (WASM) байт-код и развертывается в сети. После завершения развертывания владелец смарт-контракта может привязать контракт к нативному расширению. Владелец смарт-контракта — это учетная запись, чей внешний адрес (EOA) может быть проверен через isOwner(address) возвращает (bool).
Нативное расширение платформы реализовано в качестве хуков на уровне протокола и имеет значительные преимущества по сравнению с хуками Uniswap V4:
Во-первых, нативные расширения используют WASM для выполнения своего кода, что обеспечивает эффективность выполнения на несколько порядков выше, чем у EVM.
Во-вторых, нативное расширение может подключать весь жизненный цикл транзакции, а не только основную логику DeFi, что позволяет создавать более функциональные децентрализованные приложения.
В конце концов, и это самое важное, нативное расширение работает независимо в безопасной песочнице, что обеспечивает изоляцию и гарантирует, что выполнение расширения не повлияет на безопасность выполнения контракта.
Изолированность нативного расширения ограничивает взаимные вызовы между контрактами Hook, как обычными контрактами, так и внешними другими контрактами, эффективно решая болевые точки контроля доступа и валидации ввода в Uniswap V4 Hooks. Для таких DeFi контрактов, как Uniswap, развертывание на этой платформе позволяет наслаждаться более быстрым, мощным и безопасным опытом Hook.
Резюме
В качестве важного участника и лидера в области децентрализованных финансов, Uniswap сыграл ключевую роль в продвижении прогресса в отрасли и совершенствовании функций. Hooks, введенные в Uniswap V4, безусловно, будут указывать направление развития децентрализованных бирж и станут объектом подражания для последователей.
Тем не менее, Uniswap V4 Hooks ограничены самим умным контрактом; независимо от того, насколько тщательно спроектирован протокол и насколько совершенен инструментальный набор, он не сможет в корне предотвратить взаимные вызовы между контрактами Hook и другими внешними контрактами, что создает потенциальные риски безопасности.
Некоторая высокопроизводительная EVM-совместимая Layer 1 блокчейн-сеть с момента проектирования протокола учитывала независимый механизм расширения, работающий в WASM, обеспечивая нативную поддержку программирования Hooks, что значительно повышает безопасность. Это предоставляет продвинутое решение для децентрализованных финансовых протоколов, для которых безопасность является жизненно важной.