Decodificação DeFI: Uma Explicação do Gancho Uniswap V4 (Com TWAMM Como Exemplo) de Dentro Para Fora

Por tecnologia BitBlock Technology.

O desenvolvimento de contratos inteligentes não deveria necessitar de permissão. No entanto, apenas alguns contratos, como Uniswap, AAVE, MakerDAO, atraem regularmente milhões de usuários ativos. Uma razão é porque o desenvolvimento de ponta a ponta na cadeia, com eficiência de gás/seguro/fácil de usar é complicado. Agora imagine que existe uma solução para simplificar isso, e imagine que já exista um contrato testado que você pode conectar sua lógica personalizada e que já é usado por milhões de usuários. O ganho Uniswap V4 é uma dessas ferramentas/framework que nos permite alcançar isso.

Um jogo infinito não é jogado para vencer, mas para continuar o jogo.

-James Carse, Finite & Infinite Games (Jogos Finitos e Infinitos) 1986

O objetivo deste artigo não é como escrever um gancho (alguns materiais excelentes estão listados aqui), mas ajudá-lo a entender melhor e ligar os pontos a fim de que você escreva ganchos melhores.

Vamos começar!

Créditos da imagem. Adicionamos cor à DeFi, tornando-a mais compreensível.

Conteúdo

• Arquitetura geral dos ganchos V4 e como eles se conectam;
• Liquidação única suportada pelo callback (retorno de chamada) lock/lockAquired;
• Design de Ganchos TWAMM – Passo a passo sobre dados e lógica;
• Áreas de melhoria.

Arquitetura Geral dos Ganchos V4 e Como Eles se Conectam

Quando se desenvolve um gancho, é importante lembrar de alguns aspectos fundamentais, que estão abaixo:

• No momento em que você cria um gancho, você sempre cria implicitamente também um pool subjacente.
• Não existe uma maneira direta de vincular seu próprio gancho a outros pools.
• É possível chamar manualmente o swap de outros pools (para problemas como, por exemplo, seu próprio pool ser fino e você deseja usar a liquidez de outro pool).

Figura: cada gancho vem com seu próprio pool interno.

Em seguida, passamos a explorar o armazenamento de dados de ganchos individuais (ou pools de ganchos equivalentes). Com a personalização, todo o armazenamento de dados virá de duas fontes: as definidas pela Uniswap e as definidas por você mesmo:

• A parte azul é fornecida pela Uniswap. Inclui todos os dados relacionados ao pool de swap (na verdade, eles são iguais aos da V3).
• A parte amarela são seus dados e lógica personalizados. No exemplo TWAMM, os dados de customização incluem pools de pedidos TWAMM (por exemplo, você pode ter ETH/DAI e ETH/WBTC para diferentes pools TWAMM).

Figura: estrutura de dados de ganchos individuais (usando o TWAMM como exemplo). Observe que o PoolKey vincula tudo.

Observe a importância do PoolKey (ou PoolId), que une tudo. A definição de PoolKey e a conversão em poolKey são apresentads abaixo.

Figura: o PoolKey define um pool exclusivo (pode ser com ou sem gancho).

Figura: PoolKey para PoolId (para chave de mapeamento).

Observe que, além do armazenamento de dados, o gráfico também se aplica a funções e interfaces. Todas as interfaces de função de retorno de chamada (callback) são fornecidas (incluindo retorno de chamada de bloqueio e retorno de chamada de gancho), enquanto o usuário fornece apenas lógica específica de gancho e tal lógica é chamada por meio da ligação entre as funções de retorno de chamada. A ligação, conhecida como ciclo de vida do gancho, pode ser encontrada nas incríveis páginas de ganchos da Unsiwap e na captura de tela abaixo.

Figura: ciclo de vida do gancho da página incrível da Uniswap.

Liquidação Única Suportada pelo callback lock/lockAquired

O V4 também suporta liquidação única após múltiplas chamadas (pode ser swap, modificação de posição ou outras). A Uniswap implementa isso por meio do mecanismo de retorno de chamada lock/lockAquired. Antes de entrarmos em detalhes, vamos descobrir o porquê:

Pergunta:

Digamos que você descubra uma oportunidade de arbitragem, que exige a troca primeiro do USDC por ETH, depois do WBTC e, finalmente, de volta ao USDC. E agora que você é o designer do Swap V4 Protocol, como pode fazer com que esse gás funcione com eficiência?

Faça uma pausa… e pense um pouco aqui…

Existem algumas maneiras de fazer isto:

• Método 1: você fornece uma função Swap e toda vez que o usuário chamar Swap (token1, token2), você liquida. Isso é bom (e, na verdade, é o V3), mas consome gás a cada troca.
• Método 2: você fornece Swap e Settle separadamente e permite que os usuários chamem sequencialmente 3 swaps primeiro (de USDC →ETH →WBTC →USDC) e depois liquidem. Nesse método, você corre riscos: e se usuários externos simplesmente chamarem o primeiro swap e fugirem?
• Método 3: o método acima está apenas meio cozido e, para completá-lo, você precisa evitar a fuga magicamente. O retorno de chamada Lock é a mágica; dentro dele, o usuário pode fazer qualquer troca que desejar, seguida pela liquidação da chamada do usuário. Assim, quando ele retorna, o protocolo verifica e reverte se não for o caso.

O gráfico abaixo descreve a diferença entre V3 e V4 no retorno de chamada Lock.

Figura: retorno de chamada lock permite liquidação única para economia de gás.

De volta ao Solidity, a função lock é implementada em PoolManager.sol (link) e lockAquired (callback) é implementado no contrato BaseHook (link).

Figura: a função lock permite liquidação única.

Figura: retorno de chamada lockAquired no Basehook.

Design de Ganho TWAMM – Passo a Passo Sobre Dados e Lógica

O contrato TWAMM.sol foi bem desenhado.

Software = Dados + Lógica.

Por isso, vamos analisar essas duas partes.

Dados

A Uniswap minimiza o armazenamento de dados do TWAMM para gás. As necessidades finais de dados incluem apenas:

• Pedidos TWAMM consolidados em cada lado (State.OrderPool.State),
• Pedido TWAMM individual (para suportar modificação de pedido (State.orders),
• Coleção de todos os pools TWAMM individuais (twammStates).

Os usuários interessados ​​​​podem verificar mais os detalhes de OrderPool.State e pedidos. A Uniswap faz seus projetos de forma a minimizar as necessidades de atualização (custos de leitura/escrita de armazenamento!).

Lógica

A lógica crítica deste gancho é obter o preço de atendimento do pedido TWAMM. Por que? Com o preço, temos:

• A quantidade de token trocado de volta para ambos os lados dos pedidos TWAMM,
• Quanto sobra para potencializar as interações de pools.

Ao contrário do pensamento inicial, a matemática de implementação do TWAMM não é uma lógica simples de média de tempo devido a alguns motivos:

• O TWAMM precisa dividir o pedido em pequenos pedaços (chamados de pedidos virtuais) (este artigo sobre o paradigma é bom).
• Após cada pedido pequeno, o preço mudará. A média simples requer esta série de preços. No entanto, não queremos que o gás atenda a pedidos tão pequenos.
• O TWAMM projeta uma solução matemática elegante usando cálculo. Detalhes e a razão pela qual a simples intuição não funciona podem ser encontrados em meu artigo (DeFI Decode: Mathematics Behind the Uniswap V4 TWAMM Hook Price Calculation).
• A fórmula de preço encontrada pelo TWAMM é

Figura: a fórmula do preço de atendimento do pedido TWAMM, detalhes no link.

Agora, de volta ao código do Solidity, a função executeTWAMMOrders em TWAMM.sol faz esse atendimento. Como esperado, tem duas etapas principais:

1. Calcular o preço de preenchimento do TWAMM e registrar o ganho (valor obtido quando o pedido TWAMM for atendido).
2. Chamar o pool.swap para liquidar totalmente a execução da ordem TWAMM.

Por enquanto, explicamos a parte principal do Gancho Uniswap V4.

Áreas de Melhoria

Através da investigação do gancho TWAMM, identificamos três problemas principais:

1. O custo do gás dos ganchos é superior ao do pool sem gancho, além de quem deveria arcar economicamente com tal taxa de gás.
2. O pool interno pode ter pouca liquidez, levando a um preço de execução insatisfatório para os usuários do TWAMM. Será possível encontrar um pool melhor para o swap em vez de apenas o pool interno?
3. Qual é o momento certo para acionar a execução? O TWAMM deveria ser executado em um determinado intervalo de tempo. No entanto, o contrato não pode ser autodenominado e precisa do acionamento da EOA.

Observe que as questões acima estão interligadas. E estão relacionadas a qual EOA chamar (e pagar a taxa de gás) e quando chamar. O framework de abstração de conta para carteira inteligente foi projetado para resolver esse problema (temos um artigo aqui no link). A seguir, exploraremos a combinação dessas duas tecnologias e compartilharemos um repositório de código no Github para a solução.

O Fim

Até agora, você deve ter uma compreensão decente do Gancho Uniswap V4. Obrigado pelo seu tempo. Espero que seja útil!

A BITBLOCK Technology tem como objetivo ser especialista em desenvolvimento e auditoria de contratos inteligentes DeFI. Entre em contato conosco se precisar de ajuda ou tiver dúvidas.

Este artigo foi escrito por Ben Liu e traduzido por Isabela Curado Nehme. Seu original pode ser lido aqui.