Mecanismo Hook do Uniswap v4: inovação e desafios coexistem

A Uniswap v4 está prestes a ser lançada, e esta atualização trará várias inovações significativas, incluindo suporte para um número infinito de pools de liquidez e taxas dinâmicas, design de instância única, contabilidade relâmpago, mecanismo Hook, e suporte ao padrão de token ERC1155. Dentre eles, o mecanismo Hook é especialmente notável por sua poderosa escalabilidade e flexibilidade.

O mecanismo Hook permite a execução de código personalizado em nós específicos do ciclo de vida do pool de liquidez, aumentando significativamente a escalabilidade e flexibilidade do pool. No entanto, essa poderosa funcionalidade também traz novos desafios de segurança. Este artigo apresentará sistematicamente os problemas de segurança e os riscos potenciais relacionados ao mecanismo Hook, a fim de promover a construção de um Uniswap v4 Hook mais seguro pela comunidade.

Mecanismo central do Uniswap V4

Antes de entrar em uma discussão mais profunda, precisamos ter uma compreensão básica dos mecanismos centrais do Uniswap v4. Hooks, arquitetura singleton e contabilidade relâmpago são três funcionalidades-chave para implementar pools de liquidez personalizados e roteamento eficiente entre pools.

Mecanismo Hook

Hook é um contrato que opera em diferentes fases do ciclo de vida de um pool de liquidez, e ao introduzir o Hook, a equipe da Uniswap espera alcançar decisões de trade-off mais flexíveis. Atualmente, existem 8 callbacks de Hook, divididos em 4 grupos:

• antesDeInicializar/depoisDeInicializar
• beforeModifyPosition/afterModifyPosition
• antesTroca/depoisTroca
• antesDoar/depoisDoar

Singleton, contabilidade relâmpago e mecanismo de bloqueio

A arquitetura singleton e a contabilidade de relâmpago visam melhorar o desempenho reduzindo custos e aumentando a eficiência. O novo contrato singleton PoolManager foi introduzido para armazenar e gerenciar o estado de todas as pools.

O fluxo de trabalho do mecanismo de contabilidade relâmpago e de bloqueio é o seguinte:

1. O contrato locker solicita lock ao PoolManager
2. PoolManager adiciona o endereço do locker à fila e chama seu callback lockAcquired
3. O locker executa a lógica no callback, e a interação com o pool pode resultar em um aumento monetário não nulo.
4. O PoolManager verifica a fila e o estado do aumento de moeda, e após a validação, remove esse locker.

Este mecanismo garante que todas as transações possam ser liquidadas, mantendo a integridade dos fundos. Devido à existência do mecanismo de bloqueio, contas externas não podem interagir diretamente com o PoolManager, sendo necessário fazê-lo através de contratos.

Modelo de Ameaças

Consideramos principalmente dois modelos de ameaça:

• Modelo de Ameaça I: O Hook em si é benigno, mas apresenta vulnerabilidades
• Modelo de Ameaça II: O Hook é malicioso por si só

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

Estamos focados nas vulnerabilidades potenciais específicas da versão v4, que se dividem principalmente em duas categorias:

• Problemas de controle de acesso: A função de callback Hook pode ser chamada por entidades não autorizadas.
• Problemas de validação de entrada: A validação de entrada inadequada na implementação do Hook leva a chamadas externas não confiáveis.

Estas questões podem levar à perda de fundos ou à alteração de estados críticos.

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

De acordo com a forma de acesso do Hook, pode ser dividido em:

• Hook gerido: os usuários interagem com o Hook através do roteador
• Hook independente: os usuários podem interagir diretamente com o Hook

Os Hooks de custódia são difíceis de roubar diretamente, mas podem manipular o mecanismo de gestão de taxas. Os Hooks independentes obtêm mais permissões e, se forem atualizáveis, apresentam riscos de segurança significativos.

Medidas de Prevenção

Para o modelo de ameaça I, deve ser implementado um controle de acesso adequado e validação de entrada, considerando a proteção contra reentradas.

Em relação ao modelo de ameaça II, é necessário avaliar se o Hook é malicioso. Para Hooks geridos, a atenção deve ser dada ao comportamento de gestão de custos, enquanto para Hooks independentes, a atenção deve ser dada à possibilidade de atualização.

Construir um Hook seguro para o Uniswap v4 requer um esforço conjunto de desenvolvedores e utilizadores, buscando um equilíbrio entre inovação e segurança. No futuro, iremos realizar uma análise mais aprofundada dos problemas de segurança sob cada modelo de ameaça.