Mecanismo Hook de Uniswap v4: potencial y riesgos coexistentes
Uniswap v4 está a punto de lanzarse, esta actualización introduce varias nuevas funciones, incluyendo el soporte para un número ilimitado de grupos de liquidez por par de negociación y tarifas dinámicas, diseño de singleton, contabilidad instantánea, mecanismo Hook, y soporte para el estándar de tokens ERC1155. Entre ellos, el mecanismo Hook ha despertado un gran interés debido a su gran potencial.
El mecanismo Hook 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. Aunque es potente y flexible, usar Hook de manera segura también es un desafío considerable. La complejidad de Hook inevitablemente introduce nuevos vectores de ataque potenciales.
Este artículo presentará los conceptos relacionados con el mecanismo Hook en Uniswap v4 y esbozará los riesgos de seguridad que existen.
Mecanismo central 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 lograr piscinas de liquidez personalizadas y un enrutamiento eficiente a través de múltiples piscinas.
Mecanismo Hook
Hook se refiere a contratos que operan en diferentes etapas del ciclo de vida de un fondo de liquidez, con el objetivo de permitir que cualquier persona tome decisiones de compensación. De esta manera, se puede lograr un soporte nativo para tarifas dinámicas, agregar órdenes limitadas en cadena o dispersar grandes órdenes a través de un creador de mercado ponderado por tiempo (TWAMM).
Actualmente hay ocho callbacks Hook, divididos en cuatro grupos ( cada grupo contiene un par de callbacks ):
beforeInitialize/afterInitialize
beforeModifyPosition/afterModifyPosition
antes del intercambio/después del intercambio
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 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 la contabilidad 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 agrega 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. La interacción con el pool durante el proceso de ejecución puede resultar en un incremento monetario no nulo, pero al finalizar la ejecución, todos los incrementos deben liquidarse a cero.
PoolManager verifica el estado de la cola lockData y el incremento de la moneda. Después de la verificación, elimina el contrato del locker.
En general, el mecanismo de bloqueo previene el acceso concurrente y garantiza que todas las transacciones puedan ser liquidadas. Este enfoque significa que los ajustes operativos afectan el saldo neto interno, en lugar de ejecutar transferencias inmediatas. Cualquier modificación se registrará en el saldo interno del fondo, y la transferencia real se llevará a cabo al finalizar la operación.
Debido a la existencia del mecanismo de bloqueo, todas las cuentas externas (EOA) no pueden interactuar directamente con PoolManager. Cualquier interacción debe realizarse a través de contratos. Existen principalmente dos escenarios de interacción con contratos:
El contrato del locker proviene de la biblioteca de código oficial o es desplegado por el usuario. Esta situación puede considerarse como una interacción a través de un enrutador.
El contrato locker se integra en el mismo contrato que Hook, o es controlado por una entidad externa. Esta situación puede considerarse como una interacción a través de Hook.
Modelo de Amenaza
Antes de discutir los problemas de seguridad relacionados, necesitamos definir el modelo de amenaza. Las siguientes dos situaciones son las principales a considerar:
Modelo de amenaza I: Hook es benigno, pero tiene vulnerabilidades.
Modelo de amenaza II: Hook es malicioso en sí mismo.
Problemas de seguridad en el modelo de amenazas I
El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el Hook en sí. Este modelo de amenaza asume que los desarrolladores y su Hook son benignos. Sin embargo, las vulnerabilidades conocidas existentes en los contratos inteligentes también pueden aparecer en el Hook.
Nos enfocamos en las vulnerabilidades potenciales propias de la versión v4, prestando especial atención a los siguientes dos Hooks:
Hook para custodiar los fondos de los usuarios. Los atacantes podrían atacar este Hook para transferir fondos, causando pérdidas de activos.
Hook para almacenar datos de estado críticos que dependen de usuarios u otros protocolos. Un atacante podría intentar modificar el estado crítico, lo que podría presentar riesgos potenciales cuando otros usuarios o protocolos utilizan un estado incorrecto.
Tras la investigación, hemos descubierto varias vulnerabilidades graves, que provienen principalmente de la interacción de riesgos entre Hook, PoolManager y terceros externos, y se pueden clasificar en dos categorías: problemas de control de acceso y problemas de validación de entradas.
Problemas de control de acceso
Las funciones de callback en v4 pueden causar problemas, incluyendo 8 callbacks de Hook y callbacks de lock. Estas funciones solo deben ser llamadas por PoolManager y no por otras direcciones. Para los Hooks, es crucial establecer un mecanismo de control de acceso robusto, especialmente porque pueden ser llamados por partes diferentes al propio pool.
Problema de validación de entrada
A pesar de la existencia de un mecanismo de bloqueo, hay un posible escenario de ataque que se debe a llamadas externas no confiables provocadas por una verificación de entrada inadecuada en algunas implementaciones de Hook vulnerables:
Hook no ha verificado el fondo al que el usuario pretende interactuar. Este podría ser un fondo malicioso que contiene tokens falsos y ejecuta lógica dañina.
Algunas funciones Hook clave permiten llamadas externas arbitrarias.
Las llamadas externas no confiables son extremadamente peligrosas y pueden llevar a varios tipos de ataques, incluyendo ataques de reentrada.
Medidas de prevención
Para evitar problemas de seguridad relacionados con Hook, es crucial validar las interacciones mediante la ejecución adecuada de controles de acceso necesarios a funciones externas/públicas sensibles y la validación de los parámetros de entrada. Además, la protección contra reentradas puede ayudar a asegurar que Hook no se ejecute repetidamente en el flujo lógico estándar.
Problemas de seguridad en el modelo de amenazas II
En este modelo de amenaza, asumimos que el desarrollador y su Hook son maliciosos. La clave está en si el Hook proporcionado puede manejar los activos criptográficos de transferencia o autorización del usuario.
Según el método de acceso de Hook, dividimos Hook en dos categorías:
Hook de custodia: Hook no es un punto de entrada. El usuario debe interactuar con Hook a través del enrutador.
Hook independiente: Hook es el punto de entrada que permite a los usuarios interactuar directamente con él.
Hook de custodia
Los activos criptográficos del usuario son transferidos o autorizados al router. Debido a 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 un atacante a través de un Hook.
Gancho independiente
Cuando se utiliza Hook como punto de entrada, la situación se complica aún más. Hook ha ganado más poder y, en teoría, puede ejecutar cualquier operación deseada a través de esta interacción.
En la versión v4, la validación de la lógica del código es muy crítica. El problema principal 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 proxy escalable ( 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
Un punto crucial es evaluar si el Hook es malicioso. Específicamente, para el Hook de tipo gestionado, debemos prestar atención al comportamiento de gestión de tarifas; mientras que para el Hook independiente, el enfoque principal está en si son actualizables.
Conclusión
Este artículo presenta un resumen de los mecanismos centrales relacionados con los problemas de seguridad de Hook en Uniswap v4 y propone dos modelos de amenaza junto con los riesgos de seguridad asociados. Aunque el mecanismo Hook es poderoso, también presenta nuevos desafíos de seguridad. Tanto los desarrolladores como los usuarios deben ser plenamente conscientes de estos riesgos potenciales y tomar las medidas adecuadas para garantizar la seguridad de los activos al usar Uniswap v4.
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.
10 me gusta
Recompensa
10
6
Compartir
Comentar
0/400
NightAirdropper
· 08-06 06:42
Jugar hasta el final
Ver originalesResponder0
WenAirdrop
· 08-05 22:14
El potencial es realmente grande.
Ver originalesResponder0
consensus_failure
· 08-05 22:11
La seguridad es lo primero.
Ver originalesResponder0
CryptoPhoenix
· 08-05 22:06
El riesgo es nuevo
Ver originalesResponder0
GateUser-74b10196
· 08-05 22:05
No decepcionan las actualizaciones de nivel épico.
Mecanismo Hook de Uniswap v4: Desafíos de seguridad detrás de funciones poderosas
Mecanismo Hook de Uniswap v4: potencial y riesgos coexistentes
Uniswap v4 está a punto de lanzarse, esta actualización introduce varias nuevas funciones, incluyendo el soporte para un número ilimitado de grupos de liquidez por par de negociación y tarifas dinámicas, diseño de singleton, contabilidad instantánea, mecanismo Hook, y soporte para el estándar de tokens ERC1155. Entre ellos, el mecanismo Hook ha despertado un gran interés debido a su gran potencial.
El mecanismo Hook 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. Aunque es potente y flexible, usar Hook de manera segura también es un desafío considerable. La complejidad de Hook inevitablemente introduce nuevos vectores de ataque potenciales.
Este artículo presentará los conceptos relacionados con el mecanismo Hook en Uniswap v4 y esbozará los riesgos de seguridad que existen.
Mecanismo central 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 lograr piscinas de liquidez personalizadas y un enrutamiento eficiente a través de múltiples piscinas.
Mecanismo Hook
Hook se refiere a contratos que operan en diferentes etapas del ciclo de vida de un fondo de liquidez, con el objetivo de permitir que cualquier persona tome decisiones de compensación. De esta manera, se puede lograr un soporte nativo para tarifas dinámicas, agregar órdenes limitadas en cadena o dispersar grandes órdenes a través de un creador de mercado ponderado por tiempo (TWAMM).
Actualmente hay ocho callbacks 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 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 la contabilidad 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 agrega 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. La interacción con el pool durante el proceso de ejecución puede resultar en un incremento monetario no nulo, pero al finalizar la ejecución, todos los incrementos deben liquidarse a cero.
PoolManager verifica el estado de la cola lockData y el incremento de la moneda. Después de la verificación, elimina el contrato del locker.
En general, el mecanismo de bloqueo previene el acceso concurrente y garantiza que todas las transacciones puedan ser liquidadas. Este enfoque significa que los ajustes operativos afectan el saldo neto interno, en lugar de ejecutar transferencias inmediatas. Cualquier modificación se registrará en el saldo interno del fondo, y la transferencia real se llevará a cabo al finalizar la operación.
Debido a la existencia del mecanismo de bloqueo, todas las cuentas externas (EOA) no pueden interactuar directamente con PoolManager. Cualquier interacción debe realizarse a través de contratos. Existen principalmente dos escenarios de interacción con contratos:
El contrato del locker proviene de la biblioteca de código oficial o es desplegado por el usuario. Esta situación puede considerarse como una interacción a través de un enrutador.
El contrato locker se integra en el mismo contrato que Hook, o es controlado por una entidad externa. Esta situación puede considerarse como una interacción a través de Hook.
Modelo de Amenaza
Antes de discutir los problemas de seguridad relacionados, necesitamos definir el modelo de amenaza. Las siguientes dos situaciones son las principales a considerar:
Problemas de seguridad en el modelo de amenazas I
El modelo de amenaza I se centra en las vulnerabilidades relacionadas con el Hook en sí. Este modelo de amenaza asume que los desarrolladores y su Hook son benignos. Sin embargo, las vulnerabilidades conocidas existentes en los contratos inteligentes también pueden aparecer en el Hook.
Nos enfocamos en las vulnerabilidades potenciales propias de la versión v4, prestando especial atención a los siguientes dos Hooks:
Hook para custodiar los fondos de los usuarios. Los atacantes podrían atacar este Hook para transferir fondos, causando pérdidas de activos.
Hook para almacenar datos de estado críticos que dependen de usuarios u otros protocolos. Un atacante podría intentar modificar el estado crítico, lo que podría presentar riesgos potenciales cuando otros usuarios o protocolos utilizan un estado incorrecto.
Tras la investigación, hemos descubierto varias vulnerabilidades graves, que provienen principalmente de la interacción de riesgos entre Hook, PoolManager y terceros externos, y se pueden clasificar en dos categorías: problemas de control de acceso y problemas de validación de entradas.
Problemas de control de acceso
Las funciones de callback en v4 pueden causar problemas, incluyendo 8 callbacks de Hook y callbacks de lock. Estas funciones solo deben ser llamadas por PoolManager y no por otras direcciones. Para los Hooks, es crucial establecer un mecanismo de control de acceso robusto, especialmente porque pueden ser llamados por partes diferentes al propio pool.
Problema de validación de entrada
A pesar de la existencia de un mecanismo de bloqueo, hay un posible escenario de ataque que se debe a llamadas externas no confiables provocadas por una verificación de entrada inadecuada en algunas implementaciones de Hook vulnerables:
Hook no ha verificado el fondo al que el usuario pretende interactuar. Este podría ser un fondo malicioso que contiene tokens falsos y ejecuta lógica dañina.
Algunas funciones Hook clave permiten llamadas externas arbitrarias.
Las llamadas externas no confiables son extremadamente peligrosas y pueden llevar a varios tipos de ataques, incluyendo ataques de reentrada.
Medidas de prevención
Para evitar problemas de seguridad relacionados con Hook, es crucial validar las interacciones mediante la ejecución adecuada de controles de acceso necesarios a funciones externas/públicas sensibles y la validación de los parámetros de entrada. Además, la protección contra reentradas puede ayudar a asegurar que Hook no se ejecute repetidamente en el flujo lógico estándar.
Problemas de seguridad en el modelo de amenazas II
En este modelo de amenaza, asumimos que el desarrollador y su Hook son maliciosos. La clave está en si el Hook proporcionado puede manejar los activos criptográficos de transferencia o autorización del usuario.
Según el método de acceso de Hook, dividimos Hook en dos categorías:
Hook de custodia: Hook no es un punto de entrada. El usuario debe interactuar con Hook a través del enrutador.
Hook independiente: Hook es el punto de entrada que permite a los usuarios interactuar directamente con él.
Hook de custodia
Los activos criptográficos del usuario son transferidos o autorizados al router. Debido a 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 un atacante a través de un Hook.
Gancho independiente
Cuando se utiliza Hook como punto de entrada, la situación se complica aún más. Hook ha ganado más poder y, en teoría, puede ejecutar cualquier operación deseada a través de esta interacción.
En la versión v4, la validación de la lógica del código es muy crítica. El problema principal 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:
Medidas de prevención
Un punto crucial es evaluar si el Hook es malicioso. Específicamente, para el Hook de tipo gestionado, debemos prestar atención al comportamiento de gestión de tarifas; mientras que para el Hook independiente, el enfoque principal está en si son actualizables.
Conclusión
Este artículo presenta un resumen de los mecanismos centrales relacionados con los problemas de seguridad de Hook en Uniswap v4 y propone dos modelos de amenaza junto con los riesgos de seguridad asociados. Aunque el mecanismo Hook es poderoso, también presenta nuevos desafíos de seguridad. Tanto los desarrolladores como los usuarios deben ser plenamente conscientes de estos riesgos potenciales y tomar las medidas adecuadas para garantizar la seguridad de los activos al usar Uniswap v4.