Por tecnología BitBlock Technology.

El desarrollo de contratos inteligentes no debería necesitar permiso. Sin embargo, solo algunos contratos, como Uniswap, AAVE, MakerDAO, atraen regularmente a millones de usuarios activos. Una razón es porque el desarrollo de punta a punta en cadena, con eficiencia de gas/seguro/fácil de usar es complicado. Ahora imagina que existe una solución para simplificar esto, e imagina que ya hay un contrato probado al que puedes conectar tu lógica personalizada y que ya es usado por millones de usuarios. El gancho Uniswap V4 es una de esas herramientas/framework que nos permite lograr esto.

Un juego infinito no se juega para ganar, sino para continuar jugando.
-James Carse, Juegos Finitos e Infinitos (Finite & Infinite Games) 1986

El objetivo de este artículo no es cómo escribir un gancho (algunos materiales excelentes están listados aquí), sino ayudarte a entender mejor y conectar los puntos para que puedas escribir mejores ganchos.

¡Empecemos!

Créditos de la imagen. Añadimos color a DeFi, haciéndola más comprensible.

Contenido

• Arquitectura general de los ganchos V4 y cómo se conectan;
• Liquidación única soportada por el callback (retorno de llamada) lock/lockAquired;
• Diseño de Ganchos TWAMM – Paso a paso sobre datos y lógica;
• Áreas de mejora.

Arquitectura General de los Ganchos V4 y Cómo se Conectan

Cuando se desarrolla un gancho, es importante recordar algunos aspectos fundamentales, que se detallan a continuación:

• En el momento en que creas un gancho, siempre creas implícitamente también un pool subyacente.
• No existe una manera directa de vincular tu propio gancho a otros pools.
• Es posible llamar manualmente el swap de otros pools (para problemas como, por ejemplo, que tu propio pool sea escaso y desees usar la liquidez de otro pool).

Figura: cada gancho viene con su propio pool interno.

Luego, exploramos el almacenamiento de datos de ganchos individuales (o pools de ganchos equivalentes). Con la personalización, todo el almacenamiento de datos proviene de dos fuentes: las definidas por Uniswap y las definidas por ti:

• La parte azul es proporcionada por Uniswap. Incluye todos los datos relacionados al pool de swap (de hecho, son iguales a los de V3).
• La parte amarilla son tus datos y lógica personalizados. En el ejemplo TWAMM, los datos de personalización incluyen pools de pedidos TWAMM (por ejemplo, puedes tener ETH/DAI y ETH/WBTC para diferentes pools TWAMM).

Figura: estructura de datos de ganchos individuales (usando el TWAMM como ejemplo). Observa que el PoolKey vincula todo.

Observa la importancia del PoolKey (o PoolId), que une todo. La definición de PoolKey y la conversión en poolKey se presentan a continuación.

Figura: el PoolKey define un pool único (puede ser con o sin gancho).

Figura: PoolKey para PoolId (para clave de mapeo).

Observa que, además del almacenamiento de datos, el gráfico también se aplica a funciones e interfaces. Todas las interfaces de función de retorno de llamada (callback) son proporcionadas (incluyendo retorno de llamada de bloqueo y retorno de llamada de gancho), mientras que el usuario solo proporciona lógica específica de gancho y tal lógica es llamada a través de la vinculación entre las funciones de retorno de llamada. La vinculación, conocida como ciclo de vida del gancho, se puede encontrar en las increíbles páginas de ganchos de Unsiwap y en la captura de pantalla a continuación.

Figura: ciclo de vida del gancho de la página increíble de Uniswap.

Liquidación Única Soportada por el callback lock/lockAquired

El V4 también soporta liquidación única después de múltiples llamadas (puede ser swap, modificación de posición u otras). Uniswap implementa esto a través del mecanismo de retorno de llamada lock/lockAquired. Antes de entrar en detalles, vamos a descubrir por qué:

Pregunta:

Digamos que descubres una oportunidad de arbitraje, que requiere intercambiar primero USDC por ETH, luego por WBTC y, finalmente, de vuelta a USDC. Y ahora que eres el diseñador del Protocolo de Swap V4, ¿cómo puedes hacer que esto funcione de manera eficiente con gas?

Haz una pausa... y piénsalo un poco aquí...

Hay algunas maneras de hacerlo:

• Método 1: proporcionas una función Swap y cada vez que el usuario llama a Swap (token1, token2), liquidas. Esto está bien (y, de hecho, es el V3), pero consume gas en cada intercambio.
• Método 2: proporcionas Swap y Settle por separado y permites que los usuarios realicen primero secuencialmente 3 swaps (de USDC →ETH →WBTC →USDC) y luego liquidar. En este método, corres riesgos: ¿y si usuarios externos simplemente llaman al primer swap y huyen?
• Método 3: el método anterior está solo medio cocido y, para completarlo, necesitas evitar la fuga mágicamente. El retorno de llamada Lock es la magia; dentro de él, el usuario puede realizar cualquier intercambio que desee, seguido por la liquidación de la llamada del usuario. Así, cuando retorna, el protocolo verifica y revierte si no es el caso.

El gráfico a continuación describe la diferencia entre V3 y V4 en el retorno de llamada Lock.

Figura: el retorno de llamada lock permite liquidación única para ahorro de gas.

De vuelta a Solidity, la función lock se implementa en PoolManager.sol (enlace) y lockAquired (retorno de llamada) se implementa en el contrato BaseHook (enlace).

Figura: la función lock permite liquidación única.

Figura: retorno de llamada lockAquired en Basehook."

Diseño del Gancho TWAMM – Paso a Paso Sobre Datos y Lógica

El contrato TWAMM.sol está bien diseñado.

Software = Datos + Lógica.

Por lo tanto, vamos a analizar estas dos partes.

Datos

Uniswap minimiza el almacenamiento de datos de TWAMM para ahorrar gas. Las necesidades finales de datos incluyen solo:

• Pedidos TWAMM consolidados en cada lado (State.OrderPool.State),
• Pedido TWAMM individual (para soportar la modificación de pedido (State.orders),
• Colección de todos los pools TWAMM individuales (twammStates).

Los usuarios interesados pueden verificar más detalles de OrderPool.State y pedidos. Uniswap diseña sus proyectos para minimizar las necesidades de actualización (¡costos de lectura/escritura de almacenamiento!).

Lógica

La lógica crítica de este gancho es obtener el precio de ejecución del pedido TWAMM. ¿Por qué? Con el precio, tenemos:

• La cantidad de token intercambiado de vuelta para ambos lados de los pedidos TWAMM,
• Cuánto queda para potenciar las interacciones de los pools.

Contrario a la intuición inicial, la matemática de implementación del TWAMM no es una lógica simple de promedio temporal debido a algunas razones:

• El TWAMM necesita dividir el pedido en pequeñas piezas (llamadas pedidos virtuales) (este artículo sobre el paradigma es bueno).
• Después de cada pedido pequeño, el precio cambiará. El promedio simple requiere esta serie de precios. Sin embargo, no queremos que el gas atienda pedidos tan pequeños.
• El TWAMM diseña una solución matemática elegante utilizando cálculo. Los detalles y la razón por la que la intuición simple no funciona se pueden encontrar en mi artículo (DeFI Decode: Matemáticas Detrás del Cálculo del Precio del Gancho TWAMM de Uniswap V4).
• La fórmula de precio encontrada por TWAMM es

Figura: la fórmula del precio de ejecución del pedido TWAMM, detalles en el enlace.

Ahora, volviendo al código de Solidity, la función execute TWAMMOrders en TWAMM.sol realiza esta ejecución. Como se espera, tiene dos pasos principales:

1. Calcular el precio de ejecución del TWAMM y registrar la ganancia (valor obtenido cuando se ejecuta el pedido TWAMM).
2. Llamar a pool.swap para liquidar completamente la ejecución del pedido TWAMM.

Por ahora, hemos explicado la parte principal del Gancho Uniswap V4.

Áreas de Mejora

A través de la investigación del gancho TWAMM, identificamos tres problemas principales:

1. El costo del gas de los ganchos es superior al del pool sin gancho, además de quién debería asumir económicamente tal tasa de gas.
2. El pool interno puede tener poca liquidez, llevando a un precio de ejecución insatisfactorio para los usuarios del TWAMM. ¿Será posible encontrar un pool mejor para el swap en lugar de solo el pool interno?
3. ¿Cuál es el momento adecuado para activar la ejecución? El TWAMM debería ejecutarse en un intervalo de tiempo determinado. Sin embargo, el contrato no puede autodesignarse y necesita la activación de una EOA.

Note que los problemas mencionados están interconectados. Y están relacionados con qué EOA llamar (y pagar la tarifa de gas) y cuándo llamar. El framework de abstracción de cuenta para la cartera inteligente fue diseñado para resolver este problema (tenemos un artículo aquí en el enlace). A continuación, exploraremos la combinación de estas dos tecnologías y compartiremos un repositorio de código en Github para la solución.

El Fin

Hasta ahora, debes tener una comprensión decente del Gancho Uniswap V4. Gracias por tu tiempo. ¡Espero que sea útil!

BITBLOCK Technology tiene como objetivo ser especialista en desarrollo y auditoría de contratos inteligentes DeFI. Contáctanos si necesitas ayuda o tienes preguntas.

Este artículo fue escrito por Ben Liu y traducido por Juan José Gouvêa. Su original se puede leer aquí.