Por que se diz que o Hook é uma "arma de dois gumes" no Uniswap V4?

Uniswap v4 está previsto para ser lançado em breve. Desta vez, a equipe da Uniswap estabeleceu metas ambiciosas, planejando introduzir diversas novas funcionalidades, incluindo suporte a um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design singleton, contabilidade relâmpago, Hook, e suporte ao padrão de token ERC1155. Com o uso de armazenamento transitório, espera-se que o Uniswap v4 seja lançado após a atualização Cancun do Ethereum.

Entre as várias inovações, o mecanismo Hook tem atraído ampla atenção devido ao seu grande potencial. Ele suporta a execução de código específico em pontos específicos do ciclo de vida do pool de liquidez, aumentando significativamente a escalabilidade e a flexibilidade do pool.

No entanto, o mecanismo Hook também pode ser uma faca de dois gumes. Embora seja poderoso e flexível, o uso seguro do Hook também representa um desafio considerável. A complexidade do Hook traz inevitavelmente novos vetores de ataque potenciais. Portanto, esperamos apresentar uma série de artigos que sistematicamente introduzam os problemas de segurança e os riscos potenciais associados ao mecanismo Hook, a fim de promover o desenvolvimento seguro da comunidade, acreditamos que essas percepções ajudarão a construir um Hook seguro para o Uniswap v4.

Como a obra inaugural desta série de artigos, este texto apresenta os conceitos relacionados ao mecanismo Hook no Uniswap v4 e descreve os riscos de segurança associados à existência do mecanismo Hook.

Mecanismo do Uniswap V4

Antes de aprofundarmos a discussão, precisamos ter uma compreensão básica do mecanismo do Uniswap v4. Hook, arquitetura singleton e contabilidade relâmpago são três funcionalidades importantes para a implementação de pools de liquidez personalizados e a realização de roteamento eficiente através de múltiplos pools.

1.1 Gancho

Hook refere-se a contratos que operam em diferentes estágios do ciclo de vida de um pool de liquidez. A equipe do Uniswap espera que, ao introduzir o Hook, qualquer pessoa possa tomar decisões de trade-off. Dessa forma, é possível implementar suporte nativo a taxas dinâmicas, adicionar ordens limite on-chain ou dispersar grandes ordens por meio de um market maker (TWAMM) ponderado no tempo.

Atualmente, existem oito callbacks de Hook, divididos em quatro grupos (cada grupo contém um par de callbacks):

• antesDeInicializar/depoisDeInicializar

• beforeModifyPosition/afterModifyPosition

• antesTroca/depoisTroca

• antesDoar/depoisDoar

1.2 Singleton, contabilidade relâmpago e mecanismo de bloqueio

A arquitetura singleton e a contabilidade em tempo real visam melhorar o desempenho reduzindo custos e garantindo eficiência. Introduz um novo contrato singleton, onde todos os pools de liquidez são mantidos no mesmo contrato inteligente. Este design singleton depende de um PoolManager para armazenar e gerenciar o estado de todos os pools.

Nas versões iniciais do protocolo Uniswap, operações como troca ou adição de liquidez envolviam transferências diretas de tokens, enquanto a versão v4 introduziu contabilidade relâmpago e mecanismos de bloqueio.

O funcionamento do mecanismo de bloqueio é o seguinte:

1. Um contrato de locker solicita o lock no PoolManager.

2. O PoolManager adiciona o endereço do contrato locker à fila lockData e chama seu callback lockAcquired.

3. O contrato locker executa sua lógica na callback. Durante o processo de execução, a interação do contrato locker com o pool pode resultar em um aumento de moeda não nulo. No entanto, ao final da execução, todos os aumentos devem ser liquidadas para zero. Além disso, se a fila lockData não estiver vazia, apenas o último contrato locker pode executar a operação.

4. O PoolManager verifica o estado da fila lockData e do incremento de moeda. Após a verificação, o PoolManager removerá o contrato locker.

Em resumo, o mecanismo de bloqueio impede o acesso concorrente e garante que todas as transações possam ser liquidadas. O contrato locker solicita o bloqueio em ordem e, em seguida, executa a transação através do callback lockAcquired. Antes e depois de cada operação no pool, os callbacks Hook correspondentes serão acionados. Por fim, o PoolManager verificará o estado.

Este método significa que o ajuste das operações é feito no saldo líquido interno, em vez de realizar transferências instantâneas. Qualquer modificação será registrada no saldo interno do pool, enquanto a transferência real ocorre ao final da operação. Este processo garante que não haja tokens não liquidadas, mantendo assim a integridade dos fundos.

Devido à existência do mecanismo de bloqueio, todas as contas externas (EOA) não podem interagir diretamente com o PoolManager. Em vez disso, qualquer interação deve ser realizada através de um contrato. Este contrato atua como um intermediário de bloqueio, e é necessário solicitar o bloqueio antes de realizar qualquer operação no pool.

Existem principalmente dois cenários de interação com contratos:

• Um contrato de locker vem do repositório de código oficial ou é implantado por um usuário. Nesse caso, podemos considerar a interação como sendo feita através de um roteador.

• Um determinado contrato de locker é integrado ao mesmo contrato que o Hook, ou controlado por uma entidade terceira. Para essa situação, podemos considerar a interação como sendo realizada através do Hook. Nesse caso, o Hook desempenha tanto o papel do contrato de locker quanto o de gerenciar o callback.

modelo de ameaça

Antes de discutir as questões de segurança relevantes, precisamos definir o modelo de ameaça. Consideramos principalmente as seguintes duas situações:

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

• Modelo de ameaça II: O Hook em si é malicioso.

Na próxima parte, discutiremos questões de segurança potenciais com base nesses dois modelos de ameaça.

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

O modelo de ameaça I foca nas vulnerabilidades relacionadas ao próprio Hook. Este modelo de ameaça assume que os desenvolvedores e seu Hook não são maliciosos. No entanto, as vulnerabilidades conhecidas existentes em contratos inteligentes também podem aparecer no Hook. Por exemplo, se o Hook for implementado como um contrato atualizável, ele pode enfrentar problemas relacionados semelhantes à vulnerabilidade UUPSUpgradeable da OpenZeppelin.

Dada a fatores acima, escolhemos focar nas vulnerabilidades potenciais específicas da versão v4. No Uniswap v4, o Hook é um contrato inteligente que pode executar lógica personalizada antes ou depois das operações do pool central (incluindo inicialização, modificação de posições, trocas e coleta). Embora se espere que o Hook implemente uma interface padrão, ele também permite a inclusão de lógica personalizada. Portanto, nosso escopo de discussão será limitado à lógica que envolve a interface padrão do Hook. Em seguida, tentaremos identificar as possíveis fontes de vulnerabilidades, como, por exemplo, como o Hook pode abusar dessas funções padrão do Hook.

Especificamente, iremos nos concentrar nas seguintes duas Hooks:

• O primeiro tipo de hook, guardar os fundos dos usuários. Neste caso, o atacante pode atacar este hook para transferir fundos, causando perdas de ativos.

• O segundo tipo de hook, armazena dados de estado crítico que dependem de usuários ou de outros protocolos. Nesse caso, o atacante pode tentar alterar o estado crítico. Quando outros usuários ou protocolos utilizam um estado incorreto, pode haver riscos potenciais.

Por favor, note que hooks fora dessas duas faixas não estão dentro do nosso escopo de discussão.

De um modo geral, encontramos 22 projetos relevantes (excluindo projetos que não estão relacionados com o Uniswap v4). Dentre esses projetos, acreditamos que 8 (36%) apresentam vulnerabilidades. Desses 8 projetos vulneráveis, 6 têm problemas de controle de acesso e 2 são suscetíveis a chamadas externas não confiáveis.

2.1.1 Problemas de controle de acesso

Nesta parte da discussão, focamos principalmente nos problemas que podem surgir das funções de callback no v4, incluindo 8 callbacks de hook e o callback de bloqueio. Claro, existem outras situações que precisam ser verificadas, mas essas variam de acordo com o design e não estão dentro do escopo da nossa discussão.

Estas funções devem ser chamadas apenas pelo PoolManager e não por outros endereços (incluindo EOA e contratos). Por exemplo, no caso em que a recompensa é distribuída pela chave do fundo, se a função correspondente puder ser chamada por qualquer conta, a recompensa pode ser recebida incorretamente.

Assim, para o hook, é crucial estabelecer um mecanismo robusto de controle de acesso, especialmente porque pode ser invocado por partes externas além do próprio pool. Ao gerenciar rigorosamente os direitos de acesso, o pool de liquidez pode reduzir significativamente os riscos associados a interações não autorizadas ou maliciosas com o hook.

2.1.2 Problemas de validação de entrada

No Uniswap v4, devido à existência de um mecanismo de bloqueio, os usuários devem obter um lock através do contrato antes de realizar qualquer operação no pool de fundos. Isso garante que o contrato atual que participa da interação seja o contrato de bloqueio mais recente.

No entanto, ainda existe um possível cenário de ataque, ou seja, chamadas externas não confiáveis devido à validação inadequada de entrada em algumas implementações de Hook vulneráveis:

• Primeiro, o hook não verifica o pool de fundos com o qual o usuário pretende interagir. Este pode ser um pool malicioso que contém tokens falsos e executa lógica prejudicial.

• Em segundo lugar, algumas funções hook chave permitem chamadas externas arbitrárias.

Chamadas externas não confiáveis são extremamente perigosas, pois podem levar a vários tipos de ataques, incluindo os ataques de reentrada que conhecemos bem.

Para atacar esses hooks vulneráveis, um atacante pode registrar um pool de liquidez malicioso para seu token falso e, em seguida, chamar o hook para executar operações no pool de liquidez. Ao interagir com o pool de liquidez, a lógica do token malicioso sequestra o fluxo de controle para realizar ações indesejadas.

2.1.3 Medidas de mitigação para o modelo de ameaça I

Para evitar problemas de segurança relacionados ao hook, é crucial validar a interação através da execução adequada do controle de acesso necessário a funções externas/públicas sensíveis e da validação dos parâmetros de entrada. Além disso, a proteção contra reentrância pode ajudar a garantir que o hook não seja executado repetidamente no fluxo lógico padrão. Ao implementar medidas de segurança adequadas, o pool de fundos pode reduzir os riscos associados a essas ameaças.

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

Neste modelo de ameaça, assumimos que os desenvolvedores e seus hooks são maliciosos. Dada a ampla gama de envolvimentos, focamos apenas nas questões de segurança relacionadas à versão v4. Portanto, a chave está em saber se o hook fornecido pode lidar com a transferência ou autorização de ativos criptográficos do usuário.

Uma vez que o método de acesso ao hook determina as permissões que podem ser concedidas ao hook, classificamos os hooks em duas categorias:

• Hook de custódia: o hook não é um ponto de entrada. Os usuários devem interagir com o hook através de um roteador (possivelmente fornecido pela Uniswap).

• Hook independente: o hook é o ponto de entrada, permitindo que os usuários interajam diretamente com ele.

2.2.1 Hook de Custódia

Neste caso, os ativos criptográficos do usuário (incluindo tokens nativos e outros tokens) são transferidos ou autorizados para o router. Como o PoolManager realiza uma verificação de saldo, não é fácil para um hook malicioso roubar diretamente esses ativos. No entanto, ainda existem potenciais superfícies de ataque. Por exemplo, o mecanismo de gestão de taxas da versão v4 pode ser manipulado por atacantes através de hooks.

2.2.2 Hook Independente

Quando o Hook é usado como ponto de entrada, a situação torna-se mais complexa. Nesses casos, como os usuários podem interagir diretamente com o hook, o hook ganha mais poder. Teoricamente, o hook pode executar qualquer operação desejada através dessa interação.

Na versão v4, a validação da lógica do código é extremamente crucial. O principal problema é se a lógica do código pode ser manipulada. Se o hook for atualizável, isso significa que um hook aparentemente seguro pode se tornar malicioso após a atualização, o que representa um risco significativo. Esses riscos incluem:

• Agentes escaláveis (que podem ser atacados diretamente);

• Com lógica de autodestruição. Pode ser atacado no caso de chamada conjunta de selfdestruct e create2.

2.2.3 Medidas de mitigação para o modelo de ameaça II

Um ponto crucial é avaliar se o hook é malicioso. Especificamente, para hooks geridos, devemos prestar atenção ao comportamento de gestão de custos; enquanto para hooks independentes, o foco principal está em saber se são atualizáveis.

Conclusão

Neste artigo, primeiro fazemos uma breve visão geral dos mecanismos centrais relacionados às questões de segurança do Hook do Uniswap v4. Em seguida, apresentamos dois modelos de ameaça e fazemos uma breve descrição dos riscos de segurança associados.

Nos artigos subsequentes, iremos abordar cada modelo de ameaça.