Mecanismo Hook do Uniswap v4: oportunidades e desafios

Uniswap v4 está prestes a ser lançado, e esta versão irá introduzir várias funções inovadoras, entre as quais o mecanismo Hook se destaca. O Hook permite a execução de código personalizado em pontos específicos do ciclo de vida da piscina de liquidez, aumentando significativamente a escalabilidade e flexibilidade da piscina. No entanto, essa poderosa funcionalidade também traz novos desafios de segurança.

Este artigo, como o início de uma série, tem como objetivo introduzir de forma sistemática as questões de segurança e os riscos potenciais relacionados ao mecanismo Hook, a fim de promover o desenvolvimento seguro da comunidade. Acreditamos que essas percepções ajudarão a construir um ecossistema Hook mais seguro para o Uniswap v4.

Mecanismo central do Uniswap V4

Antes de aprofundar nas questões de segurança, precisamos primeiro entender alguns dos mecanismos centrais do Uniswap v4:

Mecanismo Hook

Hook é um contrato que opera em diferentes fases do ciclo de vida do pool de fundos de liquidez. Atualmente, existem 8 callbacks de Hook, divididos em 4 grupos:

• beforeInitialize/afterInitialize
• antesModificarPosição/depoisModificarPosição
• antes da troca/depois da troca
• antesDoar/depoisDoar

Através do mecanismo Hook, é possível implementar suporte nativo para taxas dinâmicas, adicionar ordens de limite na cadeia e realizar a mediação de grandes ordens através de um market maker de média ponderada pelo tempo (TWAMM).

Arquitetura Singleton e Contabilidade Relâmpago

O Uniswap v4 adota uma arquitetura de singleton, onde todas as piscinas de liquidez são armazenadas no mesmo contrato inteligente. Isso depende de um PoolManager para armazenar e gerenciar o estado de todas as piscinas.

A contabilidade relâmpago é um novo mecanismo de contabilidade. As operações não transferem diretamente os tokens, mas ajustam o saldo líquido interno. A transferência real é realizada ao final da operação.

mecanismo de bloqueio

O mecanismo de bloqueio impede o acesso concorrente, garantindo que todas as transações possam ser liquidadas. O fluxo principal é o seguinte:

1. pedido de lock do contrato locker
2. O PoolManager adiciona o endereço do locker à fila e chama seu callback.
3. lógica de execução do locker, interação com o pool
4. O PoolManager verifica o estado e remove o locker

Devido ao mecanismo de bloqueio, contas externas não podem interagir diretamente com o PoolManager, devem fazê-lo através de um contrato.

Modelo de Ameaças

Consideramos principalmente dois modelos de ameaça:

• Modelo de Ameaça I: O Hook em si é benigno, mas possui vulnerabilidades
• Modelo de Ameaça II: O Hook em si é malicioso

Problemas de segurança no modelo de ameaças I

Estamos principalmente focados nas vulnerabilidades potenciais específicas da versão v4, especialmente aquelas relacionadas à lógica da interface padrão Hook. O foco está em duas categorias de Hook:

1. Hook para custodiar os fundos dos usuários
2. Hook para armazenar dados de estado críticos

Através da análise de projetos de exemplo da comunidade, descobrimos algumas vulnerabilidades graves, que se dividem principalmente em duas categorias:

Problemas de controlo de acesso

A função de callback Hook deve ser chamada apenas pelo PoolManager. A falta de controle de acesso pode levar a operações não autorizadas, como a recepção incorreta de recompensas, entre outras.

Problema de validação de entrada

Algumas implementações de Hook com validação de entrada inadequada podem levar a chamadas externas não confiáveis. Um atacante pode explorar esses Hooks registrando pools de fundos maliciosos.

Problemas de segurança no Modelo de Ameaça II

Vamos discutir o Hook em duas categorias:

Hook de custódia

Os usuários interagem com o Hook através do roteador. Embora seja difícil roubar ativos diretamente, pode haver manipulação do mecanismo de gestão de taxas.

Hook Independente

Os utilizadores podem interagir diretamente com o Hook, dando mais poder ao Hook. Se o Hook for atualizável, isso pode representar um risco significativo.

Medidas de Prevenção

Para o modelo de ameaça I:

• Implementar os controles de acesso necessários
• Verificar os parâmetros de entrada
• Adicionar proteção contra reentrada

Para o modelo de ameaça II:

• Avaliar se o Hook é malicioso
• Prestar atenção às práticas de gestão de custos ( tipo de custódia )
• Preste atenção se é possível atualizar ( modelo independente )

Este artigo faz uma discussão preliminar sobre os problemas de segurança do mecanismo Hook do Uniswap v4. Em artigos posteriores, iremos analisar mais profundamente os problemas de segurança sob cada modelo de ameaça.