El lanzamiento de Uniswap v4 está cerca, el mecanismo Hook oculta riesgos de seguridad
Uniswap v4 se lanzará pronto, y esta actualización introduce numerosas funciones nuevas, incluyendo el soporte para un número ilimitado de grupos de liquidez por par de negociación y tarifas dinámicas, diseño único, contabilidad relámpago, mecanismo Hook y soporte para el estándar de token ERC1155. Se espera que v4 se lance después de la actualización de Ethereum Cancun.
Entre tantas innovaciones, el mecanismo Hook ha llamado la atención por su gran potencial. Permite ejecutar código personalizado en puntos específicos del ciclo de vida de un pool de liquidez, lo que mejora significativamente la escalabilidad y flexibilidad del pool.
Sin embargo, el mecanismo Hook también puede ser una espada de doble filo. A pesar de su potente y flexible funcionalidad, el uso seguro de Hook también enfrenta desafíos. La complejidad de Hook inevitablemente trae nuevos vectores de ataque potenciales. Por lo tanto, es especialmente importante presentar de manera sistemática los problemas de seguridad y los riesgos potenciales relacionados con el mecanismo Hook, lo que ayudará a construir un Uniswap v4 Hook más seguro.
Este artículo presentará los conceptos relacionados con el mecanismo Hook en Uniswap v4 y ofrecerá un resumen de los riesgos de seguridad que existen.
Mecanismo de Uniswap V4
Antes de profundizar en la discusión, necesitamos tener un entendimiento básico del mecanismo de Uniswap v4. Según el anuncio oficial y el libro blanco, Hook, la arquitectura de instancia única y la contabilidad relámpago son tres funciones importantes para implementar grupos de liquidez personalizados y enrutamiento eficiente a través de múltiples grupos.
Gancho
Hook se refiere a un contrato que opera en diferentes etapas del ciclo de vida de un fondo de liquidez. El equipo de Uniswap espera que, al introducir Hook, cualquier persona pueda tomar decisiones equilibradas. Este enfoque permite el soporte nativo para tarifas dinámicas, la adición de órdenes limitadas en cadena, o la dispersión de grandes órdenes a través de un creador de mercado ponderado por tiempo (TWAMM).
Actualmente hay ocho callbacks de Hook, divididos en cuatro grupos ( cada grupo contiene un par de callbacks ):
antes de inicializar/después de inicializar
antesModificarPosición/despuésModificarPosición
antes de intercambiar/después de intercambiar
antesDeDonar/despuésDeDonar
singleton, contabilidad relámpago y mecanismo de bloqueo
La arquitectura de singleton y la contabilidad relámpago están diseñadas para mejorar el rendimiento al reducir costos y garantizar la eficiencia. Introduce un nuevo contrato singleton, donde todos los grupos de liquidez se almacenan en el mismo contrato inteligente. Este diseño de singleton depende de un PoolManager para almacenar y gestionar el estado de todos los grupos.
La versión v4 introduce el registro relámpago y el mecanismo de bloqueo. El funcionamiento del mecanismo de bloqueo es el siguiente:
El contrato locker solicita un lock en PoolManager.
PoolManager añade la dirección del contrato locker a la cola lockData y llama a su callback lockAcquired.
El contrato locker ejecuta su lógica en la devolución de llamada. Durante el proceso de ejecución, la interacción del contrato locker con el fondo puede provocar un incremento monetario no nulo. Sin embargo, al finalizar la ejecución, todos los incrementos deben liquidarse a cero. Además, si la cola lockData no está vacía, solo el último contrato locker puede ejecutar operaciones.
PoolManager verifica el estado de la cola lockData y el incremento de moneda. Tras la verificación, PoolManager eliminará el contrato del locker.
En resumen, el mecanismo de bloqueo previene el acceso concurrente y garantiza que todas las transacciones puedan ser liquidadas. El contrato locker solicita el lock en orden y luego ejecuta la transacción a través del callback lockAcquired. Antes y después de cada operación en el pool, se activarán los callbacks Hook correspondientes. Al final, PoolManager verificará el estado.
Este método significa que la operación ajusta el saldo neto interno (, es decir, delta ), en lugar de realizar una transferencia instantánea. Cualquier modificación se registrará en el saldo interno del fondo, y la transferencia real se realizará al finalizar la operación (, es decir, lock ). Este proceso garantiza que no haya tokens no liquidados, manteniendo así la integridad de los fondos.
Debido a la existencia del mecanismo de bloqueo, todas las cuentas externas (EOA) no pueden interactuar directamente con PoolManager. En cambio, cualquier interacción debe realizarse a través de un contrato. Este contrato actúa como un intermediario de bloqueo, y se debe solicitar un bloqueo antes de realizar cualquier operación en la piscina.
Existen principalmente dos escenarios de interacción de contratos:
El contrato locker proviene del repositorio de código oficial o es desplegado por el usuario. En este caso, podemos considerar la interacción como si se realizara a través de un enrutador.
El contrato locker y Hook se integran en el mismo contrato, o son controlados por una entidad externa. Para este caso, podemos considerar la interacción como a través de Hook. En este caso, Hook cumple tanto con el papel del contrato locker como con la responsabilidad de manejar las devoluciones de llamada.
Modelo de amenazas
Antes de discutir los problemas de seguridad relacionados, necesitamos definir el modelo de amenazas. Las dos situaciones principales a considerar son las siguientes:
Modelo de amenaza I: Hook en sí es benigno, pero tiene vulnerabilidades.
Modelo de amenaza II: el Hook en sí es malicioso.
En la siguiente sección, discutiremos los problemas de seguridad potenciales según estos dos modelos de amenazas.
Problemas de seguridad en el modelo de amenazas I
El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el propio Hook. Este modelo de amenaza supone que los desarrolladores y su Hook no son maliciosos. Sin embargo, las vulnerabilidades conocidas existentes en los contratos inteligentes también pueden aparecer en el Hook.
Nos centramos en las vulnerabilidades potenciales específicas de la versión v4. En Uniswap v4, Hook es un contrato inteligente que puede ejecutar lógica personalizada antes o después de realizar operaciones en el pool central (, que incluyen inicialización, modificación de posiciones, intercambio y recolección ). Aunque se espera que Hook implemente una interfaz estándar, también permite incluir lógica personalizada. Por lo tanto, nuestro ámbito de discusión se limitará a la lógica que involucra la interfaz estándar de Hook. A continuación, intentaremos identificar posibles fuentes de vulnerabilidades, como cómo Hook podría abusar de estas funciones estándar de Hook.
En concreto, nos centraremos en los siguientes dos tipos de Hook:
El primer tipo de hook, que custodia los fondos del usuario. En este caso, el atacante podría atacar este hook para transferir fondos, causando pérdidas de activos.
Segundo tipo de hook, almacena datos de estado críticos de usuarios o de otros protocolos de los que depende. En este caso, un atacante podría intentar cambiar el estado crítico. Cuando otros usuarios o protocolos utilizan un estado incorrecto, esto podría conllevar riesgos potenciales.
Después de investigar a fondo el repositorio de Awesome Uniswap v4 Hooks, encontramos varios errores graves. Estos errores provienen principalmente de la interacción de riesgos entre hook, PoolManager y terceros externos, y se pueden clasificar principalmente en dos categorías: problemas de control de acceso y problemas de validación de entradas.
En general, hemos encontrado 22 proyectos relevantes ( excluyendo los proyectos no relacionados con Uniswap v4 ). De estos proyectos, consideramos que hay 8 (36%) proyectos que tienen vulnerabilidades. De estos 8 proyectos con vulnerabilidades, 6 tienen problemas de control de acceso y 2 son susceptibles a llamadas externas no confiables.
Problemas de control de acceso
En esta parte de la discusión, nos centraremos principalmente en los problemas que pueden surgir con las funciones de devolución de llamada en v4, incluyendo 8 devoluciones de llamada de hook y la devolución de llamada de bloqueo. Estas funciones solo deberían ser llamadas por PoolManager y no por otras direcciones (, incluyendo EOA y contratos ). Por ejemplo, en el caso de que las recompensas sean distribuidas por la clave del fondo, si las funciones correspondientes pueden ser llamadas por cualquier cuenta, entonces las recompensas podrían ser reclamadas incorrectamente.
Por lo tanto, para los hooks, es crucial establecer un mecanismo de control de acceso robusto, especialmente porque pueden ser invocados por otras partes además del propio grupo. Al gestionar estrictamente los permisos de acceso, los grupos de liquidez pueden reducir significativamente el riesgo de interacciones no autorizadas o maliciosas con los hooks.
Problema de verificación de entrada
En Uniswap v4, debido a la existencia de un mecanismo de bloqueo, los usuarios deben obtener un lock a través del contrato antes de realizar cualquier operación en el pool de liquidez. Esto asegura que el contrato que participa actualmente en la interacción sea el contrato de bloqueo más reciente.
A pesar de esto, existe un posible escenario de ataque, es decir, llamadas externas no confiables que resultan de una validación de entrada inadecuada en algunas implementaciones de Hook vulnerables:
Primero, el hook no ha verificado el fondo con el que el usuario pretende interactuar. Este podría ser un fondo malicioso que contiene tokens falsos y ejecuta lógica dañina.
En segundo lugar, algunas funciones hook clave permiten llamadas externas arbitrarias.
Las llamadas externas no confiables son extremadamente peligrosas, ya que pueden dar lugar a varios tipos de ataques, incluyendo el ataque de reentrada que conocemos bien.
Para atacar estos hooks vulnerables, un atacante puede registrar un pool de fondos malicioso para sus tokens falsos y luego llamar al hook para ejecutar operaciones en el pool de fondos. Al interactuar con el pool de fondos, la lógica del token malicioso secuestra el flujo de control para llevar a cabo comportamientos indebidos.
Medidas de prevención contra el modelo de amenaza I
Para evitar problemas de seguridad relacionados con los hooks, es crucial validar las interacciones mediante la implementación adecuada de controles de acceso necesarios a funciones externas/públicas sensibles y la verificación de los parámetros de entrada. Además, la protección contra reentradas puede ayudar a asegurar que los hooks no se ejecuten repetidamente en el flujo lógico estándar. Al implementar medidas de seguridad adecuadas, el fondo de liquidez puede reducir los riesgos asociados con tales amenazas.
Problemas de seguridad en el modelo de amenazas II
En este modelo de amenaza, asumimos que los desarrolladores y sus hooks son maliciosos. Dado que el alcance es amplio, solo nos enfocamos en los problemas de seguridad relacionados con la versión v4. Por lo tanto, la clave radica en si el hook proporcionado puede manejar los activos criptográficos de transferencia o autorización del usuario.
Debido a que el método de acceso a hook determina los permisos que se pueden otorgar a hook, lo clasificamos en dos categorías:
Hooks gestionados (: los hooks no son puntos de entrada. Los usuarios deben interactuar con el hook a través del router ) que puede ser proporcionado por Uniswap (.
Ganchos independientes)Standalone Hooks(: el gancho es un punto de entrada que permite a los usuarios interactuar directamente con él.
)# Hook de custodia
En este caso, los activos criptográficos del usuario ### incluyen tokens nativos y otros tokens ( que se transfieren o autorizan al router. Dado que el PoolManager realiza una verificación de saldo, no es fácil para un hook malicioso robar directamente estos activos. Sin embargo, todavía existe una superficie de ataque potencial. Por ejemplo, el mecanismo de gestión de tarifas de la versión v4 podría ser manipulado por atacantes a través de hooks.
)# Gancho independiente
Cuando se utiliza un Hook como punto de entrada, la situación se vuelve más compleja. En este caso, dado que los usuarios pueden interactuar directamente con el hook, este obtiene más poder. Teóricamente, el hook puede ejecutar cualquier operación deseada a través de esta interacción.
En la versión v4, la verificación de la lógica del código es muy crucial. El principal problema radica en si se puede manipular la lógica del código. Si el hook es actualizable, esto significa que un hook que parece seguro podría volverse malicioso después de la actualización, lo que representa un riesgo significativo. Estos riesgos incluyen:
El agente actualizable ### puede ser atacado directamente (;
Tiene lógica de autodestrucción. Puede ser atacado en el caso de la llamada conjunta a selfdestruct y create2.
)# Medidas de prevención contra el modelo de amenaza II
Un punto crucial es evaluar si el hook es malicioso. Específicamente, para los hooks gestionados, debemos prestar atención al comportamiento de gestión de costos; mientras que para los hooks independientes, el enfoque principal debe ser si son escalables.
![¿Por qué se dice que Hook es una "espada de doble filo" en Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusión
Este artículo resume los mecanismos centrales relacionados con los problemas de seguridad de Hook en Uniswap v4, presenta dos modelos de amenaza y describe los riesgos de seguridad asociados.
En los próximos artículos, realizaremos un análisis en profundidad de los problemas de seguridad bajo cada modelo de amenaza.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
El mecanismo Hook de Uniswap v4 presenta riesgos de seguridad, los expertos advierten sobre su uso cauteloso.
El lanzamiento de Uniswap v4 está cerca, el mecanismo Hook oculta riesgos de seguridad
Uniswap v4 se lanzará pronto, y esta actualización introduce numerosas funciones nuevas, incluyendo el soporte para un número ilimitado de grupos de liquidez por par de negociación y tarifas dinámicas, diseño único, contabilidad relámpago, mecanismo Hook y soporte para el estándar de token ERC1155. Se espera que v4 se lance después de la actualización de Ethereum Cancun.
Entre tantas innovaciones, el mecanismo Hook ha llamado la atención por su gran potencial. Permite ejecutar código personalizado en puntos específicos del ciclo de vida de un pool de liquidez, lo que mejora significativamente la escalabilidad y flexibilidad del pool.
Sin embargo, el mecanismo Hook también puede ser una espada de doble filo. A pesar de su potente y flexible funcionalidad, el uso seguro de Hook también enfrenta desafíos. La complejidad de Hook inevitablemente trae nuevos vectores de ataque potenciales. Por lo tanto, es especialmente importante presentar de manera sistemática los problemas de seguridad y los riesgos potenciales relacionados con el mecanismo Hook, lo que ayudará a construir un Uniswap v4 Hook más seguro.
Este artículo presentará los conceptos relacionados con el mecanismo Hook en Uniswap v4 y ofrecerá un resumen de los riesgos de seguridad que existen.
Mecanismo de Uniswap V4
Antes de profundizar en la discusión, necesitamos tener un entendimiento básico del mecanismo de Uniswap v4. Según el anuncio oficial y el libro blanco, Hook, la arquitectura de instancia única y la contabilidad relámpago son tres funciones importantes para implementar grupos de liquidez personalizados y enrutamiento eficiente a través de múltiples grupos.
Gancho
Hook se refiere a un contrato que opera en diferentes etapas del ciclo de vida de un fondo de liquidez. El equipo de Uniswap espera que, al introducir Hook, cualquier persona pueda tomar decisiones equilibradas. Este enfoque permite el soporte nativo para tarifas dinámicas, la adición de órdenes limitadas en cadena, o la dispersión de grandes órdenes a través de un creador de mercado ponderado por tiempo (TWAMM).
Actualmente hay ocho callbacks de Hook, divididos en cuatro grupos ( cada grupo contiene un par de callbacks ):
singleton, contabilidad relámpago y mecanismo de bloqueo
La arquitectura de singleton y la contabilidad relámpago están diseñadas para mejorar el rendimiento al reducir costos y garantizar la eficiencia. Introduce un nuevo contrato singleton, donde todos los grupos de liquidez se almacenan en el mismo contrato inteligente. Este diseño de singleton depende de un PoolManager para almacenar y gestionar el estado de todos los grupos.
La versión v4 introduce el registro relámpago y el mecanismo de bloqueo. El funcionamiento del mecanismo de bloqueo es el siguiente:
El contrato locker solicita un lock en PoolManager.
PoolManager añade la dirección del contrato locker a la cola lockData y llama a su callback lockAcquired.
El contrato locker ejecuta su lógica en la devolución de llamada. Durante el proceso de ejecución, la interacción del contrato locker con el fondo puede provocar un incremento monetario no nulo. Sin embargo, al finalizar la ejecución, todos los incrementos deben liquidarse a cero. Además, si la cola lockData no está vacía, solo el último contrato locker puede ejecutar operaciones.
PoolManager verifica el estado de la cola lockData y el incremento de moneda. Tras la verificación, PoolManager eliminará el contrato del locker.
En resumen, el mecanismo de bloqueo previene el acceso concurrente y garantiza que todas las transacciones puedan ser liquidadas. El contrato locker solicita el lock en orden y luego ejecuta la transacción a través del callback lockAcquired. Antes y después de cada operación en el pool, se activarán los callbacks Hook correspondientes. Al final, PoolManager verificará el estado.
Este método significa que la operación ajusta el saldo neto interno (, es decir, delta ), en lugar de realizar una transferencia instantánea. Cualquier modificación se registrará en el saldo interno del fondo, y la transferencia real se realizará al finalizar la operación (, es decir, lock ). Este proceso garantiza que no haya tokens no liquidados, manteniendo así la integridad de los fondos.
Debido a la existencia del mecanismo de bloqueo, todas las cuentas externas (EOA) no pueden interactuar directamente con PoolManager. En cambio, cualquier interacción debe realizarse a través de un contrato. Este contrato actúa como un intermediario de bloqueo, y se debe solicitar un bloqueo antes de realizar cualquier operación en la piscina.
Existen principalmente dos escenarios de interacción de contratos:
El contrato locker proviene del repositorio de código oficial o es desplegado por el usuario. En este caso, podemos considerar la interacción como si se realizara a través de un enrutador.
El contrato locker y Hook se integran en el mismo contrato, o son controlados por una entidad externa. Para este caso, podemos considerar la interacción como a través de Hook. En este caso, Hook cumple tanto con el papel del contrato locker como con la responsabilidad de manejar las devoluciones de llamada.
Modelo de amenazas
Antes de discutir los problemas de seguridad relacionados, necesitamos definir el modelo de amenazas. Las dos situaciones principales a considerar son las siguientes:
Modelo de amenaza I: Hook en sí es benigno, pero tiene vulnerabilidades.
Modelo de amenaza II: el Hook en sí es malicioso.
En la siguiente sección, discutiremos los problemas de seguridad potenciales según estos dos modelos de amenazas.
Problemas de seguridad en el modelo de amenazas I
El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el propio Hook. Este modelo de amenaza supone que los desarrolladores y su Hook no son maliciosos. Sin embargo, las vulnerabilidades conocidas existentes en los contratos inteligentes también pueden aparecer en el Hook.
Nos centramos en las vulnerabilidades potenciales específicas de la versión v4. En Uniswap v4, Hook es un contrato inteligente que puede ejecutar lógica personalizada antes o después de realizar operaciones en el pool central (, que incluyen inicialización, modificación de posiciones, intercambio y recolección ). Aunque se espera que Hook implemente una interfaz estándar, también permite incluir lógica personalizada. Por lo tanto, nuestro ámbito de discusión se limitará a la lógica que involucra la interfaz estándar de Hook. A continuación, intentaremos identificar posibles fuentes de vulnerabilidades, como cómo Hook podría abusar de estas funciones estándar de Hook.
En concreto, nos centraremos en los siguientes dos tipos de Hook:
El primer tipo de hook, que custodia los fondos del usuario. En este caso, el atacante podría atacar este hook para transferir fondos, causando pérdidas de activos.
Segundo tipo de hook, almacena datos de estado críticos de usuarios o de otros protocolos de los que depende. En este caso, un atacante podría intentar cambiar el estado crítico. Cuando otros usuarios o protocolos utilizan un estado incorrecto, esto podría conllevar riesgos potenciales.
Después de investigar a fondo el repositorio de Awesome Uniswap v4 Hooks, encontramos varios errores graves. Estos errores provienen principalmente de la interacción de riesgos entre hook, PoolManager y terceros externos, y se pueden clasificar principalmente en dos categorías: problemas de control de acceso y problemas de validación de entradas.
En general, hemos encontrado 22 proyectos relevantes ( excluyendo los proyectos no relacionados con Uniswap v4 ). De estos proyectos, consideramos que hay 8 (36%) proyectos que tienen vulnerabilidades. De estos 8 proyectos con vulnerabilidades, 6 tienen problemas de control de acceso y 2 son susceptibles a llamadas externas no confiables.
Problemas de control de acceso
En esta parte de la discusión, nos centraremos principalmente en los problemas que pueden surgir con las funciones de devolución de llamada en v4, incluyendo 8 devoluciones de llamada de hook y la devolución de llamada de bloqueo. Estas funciones solo deberían ser llamadas por PoolManager y no por otras direcciones (, incluyendo EOA y contratos ). Por ejemplo, en el caso de que las recompensas sean distribuidas por la clave del fondo, si las funciones correspondientes pueden ser llamadas por cualquier cuenta, entonces las recompensas podrían ser reclamadas incorrectamente.
Por lo tanto, para los hooks, es crucial establecer un mecanismo de control de acceso robusto, especialmente porque pueden ser invocados por otras partes además del propio grupo. Al gestionar estrictamente los permisos de acceso, los grupos de liquidez pueden reducir significativamente el riesgo de interacciones no autorizadas o maliciosas con los hooks.
Problema de verificación de entrada
En Uniswap v4, debido a la existencia de un mecanismo de bloqueo, los usuarios deben obtener un lock a través del contrato antes de realizar cualquier operación en el pool de liquidez. Esto asegura que el contrato que participa actualmente en la interacción sea el contrato de bloqueo más reciente.
A pesar de esto, existe un posible escenario de ataque, es decir, llamadas externas no confiables que resultan de una validación de entrada inadecuada en algunas implementaciones de Hook vulnerables:
Primero, el hook no ha verificado el fondo con el que el usuario pretende interactuar. Este podría ser un fondo malicioso que contiene tokens falsos y ejecuta lógica dañina.
En segundo lugar, algunas funciones hook clave permiten llamadas externas arbitrarias.
Las llamadas externas no confiables son extremadamente peligrosas, ya que pueden dar lugar a varios tipos de ataques, incluyendo el ataque de reentrada que conocemos bien.
Para atacar estos hooks vulnerables, un atacante puede registrar un pool de fondos malicioso para sus tokens falsos y luego llamar al hook para ejecutar operaciones en el pool de fondos. Al interactuar con el pool de fondos, la lógica del token malicioso secuestra el flujo de control para llevar a cabo comportamientos indebidos.
Medidas de prevención contra el modelo de amenaza I
Para evitar problemas de seguridad relacionados con los hooks, es crucial validar las interacciones mediante la implementación adecuada de controles de acceso necesarios a funciones externas/públicas sensibles y la verificación de los parámetros de entrada. Además, la protección contra reentradas puede ayudar a asegurar que los hooks no se ejecuten repetidamente en el flujo lógico estándar. Al implementar medidas de seguridad adecuadas, el fondo de liquidez puede reducir los riesgos asociados con tales amenazas.
Problemas de seguridad en el modelo de amenazas II
En este modelo de amenaza, asumimos que los desarrolladores y sus hooks son maliciosos. Dado que el alcance es amplio, solo nos enfocamos en los problemas de seguridad relacionados con la versión v4. Por lo tanto, la clave radica en si el hook proporcionado puede manejar los activos criptográficos de transferencia o autorización del usuario.
Debido a que el método de acceso a hook determina los permisos que se pueden otorgar a hook, lo clasificamos en dos categorías:
Hooks gestionados (: los hooks no son puntos de entrada. Los usuarios deben interactuar con el hook a través del router ) que puede ser proporcionado por Uniswap (.
Ganchos independientes)Standalone Hooks(: el gancho es un punto de entrada que permite a los usuarios interactuar directamente con él.
)# Hook de custodia
En este caso, los activos criptográficos del usuario ### incluyen tokens nativos y otros tokens ( que se transfieren o autorizan al router. Dado que el PoolManager realiza una verificación de saldo, no es fácil para un hook malicioso robar directamente estos activos. Sin embargo, todavía existe una superficie de ataque potencial. Por ejemplo, el mecanismo de gestión de tarifas de la versión v4 podría ser manipulado por atacantes a través de hooks.
)# Gancho independiente
Cuando se utiliza un Hook como punto de entrada, la situación se vuelve más compleja. En este caso, dado que los usuarios pueden interactuar directamente con el hook, este obtiene más poder. Teóricamente, el hook puede ejecutar cualquier operación deseada a través de esta interacción.
En la versión v4, la verificación de la lógica del código es muy crucial. El principal problema radica en si se puede manipular la lógica del código. Si el hook es actualizable, esto significa que un hook que parece seguro podría volverse malicioso después de la actualización, lo que representa un riesgo significativo. Estos riesgos incluyen:
El agente actualizable ### puede ser atacado directamente (;
Tiene lógica de autodestrucción. Puede ser atacado en el caso de la llamada conjunta a selfdestruct y create2.
)# Medidas de prevención contra el modelo de amenaza II
Un punto crucial es evaluar si el hook es malicioso. Específicamente, para los hooks gestionados, debemos prestar atención al comportamiento de gestión de costos; mientras que para los hooks independientes, el enfoque principal debe ser si son escalables.
![¿Por qué se dice que Hook es una "espada de doble filo" en Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusión
Este artículo resume los mecanismos centrales relacionados con los problemas de seguridad de Hook en Uniswap v4, presenta dos modelos de amenaza y describe los riesgos de seguridad asociados.
En los próximos artículos, realizaremos un análisis en profundidad de los problemas de seguridad bajo cada modelo de amenaza.