Por que o Hook é considerado uma “faca de dois gumes” do Uniswap V4?

Acredito que o Uniswap v4 estará disponível para todos em breve!
Desta vez, a equipe Uniswap tem objetivos ambiciosos e planos para introduzir muitos novos recursos [1], incluindo suporte para um número ilimitado de pools de liquidez e taxas dinâmicas para cada par de negociação, design singleton, contabilidade relâmpago, Hooks e suporte para o token ERC1155 padrão. Aproveitando o armazenamento transitório introduzido pelo EIP-1153, espera-se que o Uniswap v4 seja lançado após a atualização do Ethereum Cancun.
Entre muitas inovações, o mecanismo Hook atraiu ampla atenção devido ao seu poderoso potencial. O mecanismo Hook suporta a execução de código específico em pontos específicos do ciclo de vida do pool de liquidez, melhorando significativamente a escalabilidade e a flexibilidade do pool.
No entanto, o mecanismo de gancho também pode ser uma faca de dois gumes. Embora seja poderoso e flexível, usar o Hook com segurança também é um grande desafio. A complexidade dos ganchos traz inevitavelmente novos vetores de ataque potenciais. Portanto, esperamos escrever uma série de artigos para apresentar sistematicamente as questões de segurança e os riscos potenciais relacionados ao mecanismo Hook, de modo a promover o desenvolvimento da segurança da comunidade. Acreditamos que esses insights ajudarão a construir um Hook Uniswap v4 seguro.
Como início desta série de artigos, este artigo apresenta conceitos relacionados ao mecanismo Hook no Uniswap v4 e descreve os riscos de segurança do mecanismo Hook.
O mecanismo do Uniswap V4
Antes de começarmos, precisamos ter um conhecimento básico da mecânica do Uniswap v4. De acordo com o anúncio oficial [1] e o white paper [2], Hooks, arquitetura singleton e contabilidade relâmpago são três funções importantes para implementar pools de liquidez personalizados e obter roteamento eficiente em vários pools.
1.1 Gancho
Ganchos referem-se a contratos executados em diferentes estágios do ciclo de vida do pool de liquidez. A equipe do Uniswap espera permitir que qualquer pessoa tome decisões de trade-off introduzindo Ganchos. Dessa forma, é possível oferecer suporte nativo a taxas dinâmicas, adicionar pedidos com limite de preço na rede ou distribuir grandes pedidos por meio de um formador de mercado médio ponderado no tempo (TWAMM).
Existem atualmente oito retornos de chamada do Hook, divididos em quatro grupos (cada grupo contém um par de retornos de chamada):
antes de inicializar/depois de inicializar
beforeModifyPosition/afterModifyPosition
antesSwap/depoisSwap
antesDoar/depoisDoar
A seguir está o processo de troca de Hooks apresentado no white paper [2].
Figura 1: Processo Exchange Hook
A equipe do Uniswap apresentou como fazer isso com alguns exemplos (como o TWAMM Hook[3]), e os participantes da comunidade também fizeram algumas contribuições. A documentação oficial[4] também tem links para o repositório Awesome Uniswap v4 Hooks[5], que coleta mais exemplos de Hooks.
1.2 Singleton, contabilidade relâmpago e mecanismo de bloqueio
A arquitetura singleton e a contabilidade flash foram projetadas para 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 anteriores do protocolo Uniswap, operações como troca ou adição de liquidez envolviam transferências diretas de tokens. A versão v4 é diferente porque introduz contabilidade relâmpago e um mecanismo de bloqueio.
O mecanismo de bloqueio funciona da seguinte forma:
1. Um contrato de armário solicita um bloqueio no PoolManager.
2. PoolManager adiciona o endereço do contrato do armário à fila lockData e chama seu retorno de chamada lockAcquired.
3. O contrato locker executa sua lógica no retorno de chamada. Durante a execução, a interação do contrato locker com o pool pode resultar em incrementos de moeda diferentes de zero. Porém, ao final da execução, todos os deltas devem ser zerados. Além disso, se a fila lockData não estiver vazia, apenas o último contrato do armário poderá realizar operações.
4. PoolManager verifica o status da fila lockData e o incremento de moeda. Após a verificação, o PoolManager excluirá o contrato do armário.
Em resumo, o mecanismo de bloqueio impede o acesso simultâneo e garante que todas as transações possam ser compensadas. O contrato de armário se aplica a bloqueios em sequência e, em seguida, executa transações por meio do retorno de chamada lockAcquired. O retorno de chamada do Hook correspondente será acionado antes e depois de cada operação do pool. Finalmente, o PoolManager verifica o status.
Esta abordagem significa que a operação ajusta o saldo líquido interno (ou seja, delta) em vez de realizar uma transferência instantânea. Quaisquer modificações serão registradas no saldo interno do pool, e a efetiva transferência será feita no final da operação (ou seja, bloqueio). Este processo garante que não haja tokens pendentes, mantendo assim a integridade dos fundos.
Devido ao mecanismo de bloqueio, as Contas de Propriedade Externa (EOA) não podem interagir diretamente com o PoolManager. Em vez disso, qualquer interação deve ocorrer através de um contrato. Este contrato atua como um armário intermediário e precisa solicitar um bloqueio antes de realizar qualquer operação de pool.
Existem dois cenários principais de interação contratual:
Um determinado contrato de armário vem da base de código oficial ou é implantado pelos usuários. Nesse caso, podemos pensar na interação como ocorrendo através do roteador.
Um contrato de armário e um Hook são integrados no mesmo contrato ou controlados por uma entidade terceira. Neste caso, podemos pensar na interação como acontecendo através de Hooks. Nesse caso, o Hook desempenha o papel do contrato do armário e é responsável por lidar com os retornos de chamada.
Modelo de ameaça
Antes de discutir questões de segurança relacionadas, precisamos identificar o modelo de ameaça. Consideramos principalmente as duas situações a seguir:
Modelo de ameaça I: os próprios ganchos são benignos, mas apresentam vulnerabilidades.
Modelo de ameaça II: os ganchos são inerentemente maliciosos.
Nas seções a seguir, discutiremos possíveis problemas de segurança com base nesses dois modelos de ameaças.
2.1 Questões de segurança no modelo de ameaça I
O Modelo de Ameaça I concentra-se nas vulnerabilidades relacionadas ao próprio Gancho. Este modelo de ameaça pressupõe que os desenvolvedores e seus Hooks são inofensivos. No entanto, vulnerabilidades conhecidas existentes em contratos inteligentes também podem aparecer em Hooks. Por exemplo, se um Hook for implementado como um contrato atualizável, ele poderá encontrar problemas semelhantes à vulnerabilidade UUPSUpgradeable do OpenZeppelin.
Tendo em vista os fatores acima, optamos por focar nas vulnerabilidades potenciais exclusivas da versão v4. No Uniswap v4, Hooks são contratos inteligentes capazes de executar lógica personalizada antes ou depois das operações do pool principal, incluindo inicialização, modificação de posição, troca e coleta. Embora se espere que os Hooks implementem interfaces padrão, eles também permitem a inclusão de lógica personalizada. Portanto, nossa discussão será limitada à lógica que envolve a interface Hook padrão. Tentaremos então identificar possíveis fontes de vulnerabilidades, por exemplo, como os Hooks podem abusar dessas funções padrão do Hook.
Especificamente, vamos nos concentrar nos dois tipos de ganchos a seguir:
O primeiro gancho é manter os fundos dos usuários. Nesse caso, um invasor pode atacar esse gancho para transferir fundos, causando perda de ativos.
O segundo tipo de gancho armazena dados de status importantes dos quais os usuários ou outros protocolos dependem. Neste caso, o invasor pode tentar alterar o estado crítico. Riscos potenciais podem surgir quando o estado incorreto é usado por outros usuários ou protocolos.
Observe que ganchos fora desses dois escopos estão fora do escopo da nossa discussão.
Como não há casos de uso reais para Hooks no momento em que este livro foi escrito, extrairemos algumas informações do repositório Awesome Uniswap v4 Hooks.
Após um mergulho profundo no repositório Awesome Uniswap v4 Hooks (commit hash 3a0a444922f26605ec27a41929f3ced924af6075), descobrimos várias vulnerabilidades críticas. Estas vulnerabilidades originam-se principalmente de interações arriscadas entre ganchos, PoolManager e terceiros externos, e podem ser divididas principalmente em duas categorias: problemas de controle de acesso e problemas de validação de entrada. Consulte a tabela abaixo para conclusões específicas:
No total, encontramos 22 projetos relevantes (excluindo projetos não relacionados ao Uniswap v4). Dentre esses projetos, acreditamos que 8 (36%) projetos são vulneráveis. Dos oito projetos vulneráveis, seis tinham problemas de controlo de acesso e dois eram vulneráveis ​​a chamadas externas não confiáveis.
2.1.1 Problemas de controle de acesso
Nesta parte da discussão, nos concentramos principalmente nos problemas que podem ser causados ​​pelas funções de retorno de chamada na v4, incluindo retornos de chamada de 8 ganchos e retornos de chamada de bloqueio. É claro que existem outras situações que precisam ser verificadas, mas essas situações variam conforme o projeto e estão além do escopo da nossa discussão.
Estas funções só devem ser chamadas pelo PoolManager e não podem ser chamadas por outros endereços (incluindo EOA e contratos). Por exemplo, no caso em que as recompensas são distribuídas por chaves de pool, as recompensas podem ser reivindicadas incorretamente se a função correspondente puder ser chamada por qualquer conta.
Portanto, é crucial estabelecer mecanismos fortes de controle de acesso para ganchos, especialmente porque eles podem ser chamados por outras partes além do próprio pool. Ao gerenciar estritamente os direitos de acesso, os pools de liquidez podem reduzir significativamente o risco de interações não autorizadas ou maliciosas com ganchos.
2.1.2 Problemas de verificação de entrada
No Uniswap v4, devido ao mecanismo de bloqueio, os usuários devem obter um bloqueio por meio do contrato antes de realizar qualquer operação de pool de fundos. Isso garante que o contrato que participa atualmente da interação seja o contrato de armário mais recente.
Ainda assim, existe um possível cenário de ataque, nomeadamente chamadas externas não confiáveis ​​devido à validação de entrada inadequada em algumas implementações vulneráveis ​​do Hook:
Primeiro, o gancho não verifica o conjunto de fundos com o qual o usuário pretende interagir. Este pode ser um pool malicioso contendo tokens falsos e executando lógica prejudicial.
Em segundo lugar, algumas funções de gancho permitem chamadas externas arbitrárias.
Chamadas externas não confiáveis ​​são extremamente perigosas porque podem levar a vários tipos de ataques, incluindo o que conhecemos como ataques de reentrada.
Para atacar esses ganchos vulneráveis, um invasor pode registrar um pool de fundos malicioso para seus próprios tokens falsos e, em seguida, chamar o gancho para realizar operações no pool de fundos. Ao interagir com o pool, a lógica do token malicioso sequestra o fluxo de controle para se envolver em comportamento indesejável.
2.1.3 Medidas preventivas contra ameaças modelo I
Para contornar esses problemas de segurança relacionados aos ganchos, é crucial autenticar as interações, aplicando adequadamente os controles de acesso necessários a funções externas/públicas sensíveis e validando os parâmetros de entrada. Além disso, a proteção contra reentrada pode ajudar a garantir que o gancho não seja executado repetidamente no fluxo lógico padrão. Ao implementar salvaguardas de segurança adequadas, os pools podem reduzir os riscos associados a tais ameaças.
2.2 Questões de segurança no Modelo de Ameaças II
Neste modelo de ameaça, assumimos que o desenvolvedor e seu gancho são maliciosos. Devido ao amplo escopo, nos concentramos apenas em questões de segurança relacionadas à versão v4. Portanto, a chave é se o gancho fornecido pode lidar com os ativos criptográficos transferidos ou autorizados pelo usuário.
Como o método de acesso ao gancho determina as permissões que podem ser concedidas ao gancho, dividimos o gancho em duas categorias:
Ganchos Gerenciados: Ganchos não são pontos de entrada. Os usuários devem interagir com o gancho através de um roteador (possivelmente fornecido pela Uniswap).
Ganchos autônomos: Ganchos são pontos de entrada que permitem aos usuários interagir diretamente com eles.
Figura 2: Exemplo de Hook malicioso
2.2.1 Gancho Gerenciado
Nesse caso, os ativos criptográficos do usuário (incluindo tokens nativos e outros tokens) são transferidos ou autorizados para o roteador. Como o PoolManager realiza verificações de saldo, não é fácil para ganchos maliciosos roubarem diretamente esses ativos. No entanto, ainda existe uma superfície de ataque potencial. Por exemplo, o mecanismo de gerenciamento de despesas da versão v4 pode ser manipulado por invasores por meio de ganchos.
2.2.2 Gancho Independente
A situação é ainda mais complicada quando Ganchos são usados ​​como pontos de entrada. Nesse caso, o gancho ganha mais potência, pois o usuário pode interagir diretamente com ele. Em teoria, um gancho pode fazer o que quiser com essa interação.
Na versão v4, a verificação da lógica do código é muito crítica. A questão principal é se a lógica do código pode ser manipulada. Se um gancho puder ser atualizado, isso significa que um gancho aparentemente seguro pode se tornar malicioso após ser atualizado, representando um risco significativo. Esses riscos incluem:
Agentes atualizáveis ​​(podem ser atacados diretamente);
Com lógica de autodestruição. Pode ser atacado quando selfdestruct e create2 são chamados em conjunto.
2.2.3 Medidas preventivas contra ameaças modelo II
É crucial avaliar se o gancho é malicioso. Especificamente, para ganchos gerenciados, devemos nos concentrar no comportamento do gerenciamento de taxas, enquanto para ganchos autônomos, o foco principal é se eles são atualizáveis.
para concluir
Neste artigo, primeiro fornecemos uma breve visão geral dos principais mecanismos relacionados aos problemas de segurança do Hook do Uniswap v4. Posteriormente, propomos dois modelos de ameaças e descrevemos brevemente os riscos de segurança associados.
Nos artigos subsequentes, conduziremos uma análise aprofundada das questões de segurança em cada modelo de ameaça.