Acredite ou não, Uniswap v4 em breve encontrará a todos!

Desta vez, a equipe da Uniswap definiu metas ambiciosas e planeja introduzir muitos novos recursos, incluindo um número ilimitado de pools de liquidez e taxas dinâmicas para cada par de negociação, design singleton, contabilidade rápida, Hook e suporte ao padrão de token ERC1155. Utilizando o armazenamento transitório introduzido pela EIP-1153, espera-se que o Uniswap v4 seja lançado após a atualização Cancun do Ethereum. Entre as muitas inovações, o mecanismo Hook ganhou ampla atenção devido ao seu grande potencial. O mecanismo Hook permite que um código específico seja executado em pontos específicos no ciclo de vida de uma pool de liquidez, melhorando significativamente a escalabilidade e flexibilidade das pools. No entanto, o mecanismo Hook também pode ser uma faca de dois gumes. Enquanto é poderoso e flexível, usar o Hook com segurança também é um desafio significativo. A complexidade do Hook inevitavelmente traz novos vetores de ataque potenciais. Portanto, esperamos escrever uma série de artigos para introduzir sistematicamente os problemas de segurança e os riscos potenciais relacionados ao mecanismo Hook, a fim de promover o desenvolvimento da segurança da comunidade. Acreditamos que essas informações ajudarão a construir Hooks seguros para o Uniswap v4. Como artigo de abertura desta série, este artigo apresenta os conceitos relacionados ao mecanismo Hook no Uniswap v4 e delineia os riscos de segurança associados ao mecanismo Hook.

- 1 - Mecanismo do Uniswap V4

Antes de aprofundar, precisamos de uma compreensão básica dos mecanismos por trás do Uniswap v4. De acordo com o anúncio oficial [1] e whitepaper [2], Hooks, arquitetura singleton e contabilidade flash são três recursos importantes que permitem piscinas de liquidez personalizadas e roteamento eficiente entre várias piscinas.

1.1 Gancho

Hooks referem-se a contratos que são executados em diferentes estágios do ciclo de vida de uma pool de liquidez. A equipe do Uniswap espera permitir que qualquer pessoa tome decisões de compensação introduzindo Hooks. Desta forma, o suporte nativo para taxas dinâmicas, ordens de limite on-chain ou market makers ponderados pelo tempo (TWAMMs) para dividir grandes pedidos pode ser implementado. Atualmente, existem oito Hooks de retorno de chamada, divididos em quatro pares (cada par contém um retorno de chamada antes e um depois):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• antes da troca/depois da troca
• antesDoar/depoisDoar

Abaixo está o fluxo do swap Hook introduzido no whitepaper [2].

Figura 1: Fluxo de Gancho de Troca

A equipe da Uniswap demonstrou a metodologia com alguns exemplos (por exemplo, TWAMM Hook [3]), e os participantes da comunidade também fizeram contribuições. A documentação oficial [4] também faz referência ao repositório Awesome Uniswap v4 Hooks [5], que reúne mais exemplos de Hooks.

1.2 Singleton, Contabilidade Flash e Mecanismo de Bloqueio

A arquitetura singleton e a contabilidade flash visam melhorar o desempenho reduzindo custos e garantindo eficiência. Ele introduz um novo contrato singleton onde todas as pools de liquidez são armazenadas no mesmo contrato inteligente. Este design singleton depende de um PoolManager para armazenar e gerenciar o estado de todas as 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 4 é diferente, pois introduz a contabilidade flash e um mecanismo de bloqueio.

👇🏻 O mecanismo de bloqueio funciona da seguinte forma: 1. Um contrato de armário solicita um bloqueio do PoolManager. 2. O PoolManager adiciona o endereço do contrato de armário à fila de dados de bloqueio e chama seu retorno de chamada de bloqueio adquirido. 3. O contrato de armário executa sua lógica no retorno de chamada. Interações com o pool durante a execução podem resultar em incrementos de moeda não nulos. No entanto, até o final da execução, todos os incrementos devem ser zerados. Além disso, se a fila de dados de bloqueio não estiver vazia, apenas o último contrato de armário pode executar operações. 4. O PoolManager verifica o estado da fila de dados de bloqueio e os incrementos de moeda. Após a verificação, o PoolManager remove o contrato de armário.

Em resumo, o mecanismo de bloqueio impede o acesso simultâneo e garante que todas as transações possam ser liquidadas. Os contratos Locker solicitam bloqueios em sequência, em seguida, executam negociações via callback lockAcquired. Os callbacks Hook correspondentes são acionados antes e depois de cada operação de pool. Por fim, o PoolManager verifica os estados. Isso significa que as operações ajustam os saldos líquidos internos (ou seja, delta) em vez de realizar transferências instantâneas. Quaisquer modificações são registradas nos saldos internos do pool, com as transferências reais ocorrendo quando a operação (ou seja, bloqueio) conclui. Esse processo garante que não haja tokens pendentes, mantendo a integridade dos fundos. Devido ao mecanismo de bloqueio, contas propriedade externa (EOAs) não podem interagir diretamente com o PoolManager. Em vez disso, qualquer interação deve passar por um contrato. Este contrato atua como um locker intermediário, solicitando um bloqueio antes de realizar qualquer operação de pool. (12/08)

👇🏻 Existem dois cenários principais de interação de contrato:

• Um contrato de bloqueio vem da base de código oficial ou é implantado por um usuário. Neste caso, podemos ver a interação como passando por um roteador.
• Um contrato de bloqueio e Hook são integrados no mesmo contrato, ou controlados por uma entidade de terceiros. Para este caso, podemos ver a interação como passando por um Hook. Aqui, o Hook desempenha o papel tanto do contrato de bloqueio quanto do tratamento dos callbacks.

- 2 -Modelo de Ameaças

Antes de discutirmos questões de segurança relacionadas, precisamos estabelecer o modelo de ameaças. Consideramos principalmente os seguintes dois casos:

• Modelo de Ameaça I: O gancho em si é benigno, mas contém vulnerabilidades.
• Modelo de Ameaça II: O próprio gancho é malicioso.

Nas seções seguintes, iremos discutir os possíveis problemas de segurança de acordo com esses dois modelos de ameaças.

2.1 Questões de Segurança no Modelo de Ameaças I

O Modelo de Ameaças I concentra-se nas vulnerabilidades associadas ao Próprio Hook. Este modelo de ameaças assume que o desenvolvedor e seu Hook não são maliciosos. No entanto, vulnerabilidades conhecidas existentes em contratos inteligentes também podem aparecer nos Hooks. Por exemplo, se um Hook for implementado como um contrato atualizável, pode encontrar problemas relacionados a vulnerabilidades como o OpenZeppelin UUPSUpgradeable. Dados os fatores acima, optamos por nos concentrar em vulnerabilidades potenciais exclusivas da versão 4. No Uniswap v4, os Hooks são contratos inteligentes que podem executar lógica personalizada antes ou depois das operações principais da pool (incluindo inicialização, modificação de posição, troca e coleta). Embora os Hooks devam implementar uma interface padrão, eles também permitem lógica personalizada. Portanto, nossa discussão será limitada à lógica envolvendo as interfaces padrão do Hook. Em seguida, tentaremos 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 seguintes dois tipos de Hooks:

• O primeiro tipo de gancho mantém os fundos do usuário. Neste caso, um atacante pode atacar este gancho para transferir fundos, causando perda de ativos.
• O segundo tipo de gancho armazena dados de estado críticos nos quais os usuários ou outros protocolos dependem. Neste caso, um atacante pode tentar alterar o estado crítico. Quando outros usuários ou protocolos utilizam o estado incorreto, podem haver riscos potenciais.

Note que ganchos fora desses dois escopos não são discutidos aqui. Como não há casos de uso de Hook do mundo real no momento desta escrita, vamos obter algumas informações do repositório Awesome Uniswap v4 Hooks. Após um estudo aprofundado do repositório Awesome Uniswap v4 Hooks (hash do commit 3a0a444922f26605ec27a41929f3ced924af6075), identificamos várias vulnerabilidades graves. Essas vulnerabilidades decorrem principalmente de interações arriscadas entre o gancho, PoolManager e terceiros externos, e podem ser divididas em duas categorias: problemas de controle de acesso e problemas de validação de entrada. Os resultados específicos são mostrados na tabela abaixo:

Em resumo, identificamos 22 projetos relevantes (excluindo aqueles não relacionados ao Uniswap v4). Entre esses projetos, acreditamos que 8 (36%) têm vulnerabilidades. Dos 8 projetos vulneráveis, 6 têm problemas de controle de acesso e 2 são vulnerá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 as funções de retorno de chamada na v4 podem causar, incluindo os 8 retornos de chamada de gancho e o retorno de bloqueio. Claro que existem outros casos que precisam de verificação, mas variam de acordo com o design e estão atualmente fora do escopo. Essas funções devem ser chamadas apenas pelo PoolManager, não por outros endereços (incluindo EOAs e contratos). Por exemplo, no caso em que as recompensas são distribuídas pelas chaves do pool, as recompensas poderiam ser reivindicadas incorretamente se as funções correspondentes fossem chamáveis por contas arbitrárias. Portanto, estabelecer mecanismos fortes de controle de acesso é crucial para os ganchos, já que podem ser invocados por partes que não sejam os próprios pools. Ao governar estritamente as permissões de acesso, os pools de liquidez podem reduzir significativamente os riscos associados a interações não autorizadas ou maliciosas com ganchos.

2.1.2 Problemas de Validação de Entrada

No Uniswap v4, devido ao mecanismo de bloqueio, os usuários devem obter um bloqueio através de um contrato antes de executar quaisquer operações de pool. Isso garante que o contrato atualmente interagindo seja o contrato de bloqueio mais recente. No entanto, ainda existe um cenário potencial de ataque de chamadas externas não confiáveis devido à validação de entrada inadequada em algumas implementações vulneráveis de Hook:

• Primeiro, o gancho não verifica a pool com a qual o usuário pretende interagir. Esta poderia ser uma pool maliciosa com tokens falsos executando lógica prejudicial.
• Em segundo lugar, algumas funções-chave de gancho 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 conhecidos ataques de reentrância. Para atacar esses ganchos vulneráveis, o atacante pode registrar um pool malicioso com tokens falsos para si mesmos, e então invocar o gancho para executar operações no pool. Ao interagir com o pool, a lógica de token malicioso sequestra o fluxo de controle para conduta indevida.

2.1.3 Contramedidas para o Modelo de Ameaças I

Para contornar tais problemas de segurança relacionados a ganchos, é crucial executar adequadamente o controle de acesso necessário em funções externas/públicas sensíveis e validar as entradas para verificar interações. Além disso, os guardas de reentrância podem ajudar a garantir que os ganchos não sejam reentrados durante os fluxos lógicos padrão. Ao implementar salvaguardas de segurança adequadas, as pools podem reduzir os riscos associados a tais ameaças.

2.2 Problemas de Segurança no Modelo de Ameaças II

Neste modelo de ameaça, assumimos que o desenvolvedor e seu gancho são maliciosos. Dada a ampla abrangência, focamos apenas em questões de segurança relacionadas à versão 4. A chave está em saber se os ganchos fornecidos podem lidar com transferências de usuários ou autorizações de criptomoedas. Uma vez que o método de acesso aos ganchos determina as permissões que podem ser concedidas aos ganchos, categorizamos os ganchos em dois tipos com base nisso:

• Hooks gerenciados: O gancho não é um ponto de entrada. Os usuários devem interagir com o gancho por meio de um roteador (possivelmente fornecido pela Uniswap).
• Hooks autônomos: O gancho é um ponto de entrada, permitindo que os usuários interajam diretamente com ele.

Figura 2: Exemplo de gancho malicioso

2.2.1 Ganchos Gerenciados

Neste caso, os ativos de criptomoeda dos usuários (incluindo tokens nativos e outros tokens) são transferidos ou aprovados para o roteador. Como o PoolManager realiza verificações de saldo, ganchos maliciosos não conseguem roubar diretamente esses ativos facilmente. No entanto, superfícies de ataque potenciais ainda existem. Por exemplo, o mecanismo de gerenciamento de taxas na versão 4 pode ser manipulado por um atacante por meio de ganchos.

2.2.2 Ganchos Autônomos

Quando os ganchos são usados como pontos de entrada, a situação se torna mais complexa. Aqui, como os usuários podem interagir diretamente com o gancho, o gancho recebe mais poder. Na teoria, o gancho pode executar quaisquer operações desejadas por meio dessas interações. Na versão 4, a verificação da lógica do código é extremamente crítica. O principal problema é se a lógica do código pode ser manipulada. Se o gancho for atualizável, isso significa que um gancho que parece seguro pode se tornar malicioso após uma atualização, representando riscos significativos. Esses riscos incluem:

• Proxies atualizáveis (que podem ser atacados diretamente)
• Lógica com autodestruições. Pode ser atacado em conjunto com a chamada de autodestruição e create2.

2.2.3 Contramedidas para Modelo de Ameaças II

Um ponto essencial é avaliar se os ganchos são maliciosos. Especificamente, para ganchos gerenciados, devemos observar o comportamento de gerenciamento de taxas; enquanto para ganchos autônomos, o foco principal é se eles são atualizáveis.

- 3 - Conclusão

Neste artigo, primeiro esboçamos brevemente os mecanismos principais relacionados às questões de segurança do Uniswap v4 Hook. Em seguida, propusemos dois modelos de ameaças e esboçamos brevemente os riscos de segurança associados. Em artigos de acompanhamento, faremos análises aprofundadas sobre as questões de segurança sob cada modelo de ameaça. Fique ligado!

Referências

[1] Nossa Visão para Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] Rascunho do whitepaper Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Gancho TWAMM Uniswap v4
https://blog.uniswap.org/v4-twamm-hook

[4] Exemplos de Hook
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Ganchos incríveis do Uniswap v4
https://github.com/fewwwww/awesome-uniswap-hooks

[6] Pós-Morte da Vulnerabilidade Atualizável UUPS
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

Sobre o BloquearSec O BloquearSec é uma empresa líder em segurança global de blockchain fundada em 2021 por renomados especialistas na indústria de segurança. A empresa dedica-se a aprimorar a segurança e usabilidade para o mundo Web3, a fim de promover a adoção generalizada do Web3. Para alcançar isso, o BloquearSec fornece serviços de auditoria de segurança de contratos inteligentes e cadeia EVM, um sistema de desenvolvimento, teste e interceptação de hackers chamado Phalcon para proprietários de projetos, uma plataforma de rastreamento de fundos e investigação chamada MetaSleuth, bem como plugins de eficiência para construtores web3 chamados MetaDock. Atualmente, a empresa atendeu a mais de 300 clientes, incluindo projetos conhecidos como MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, e recebeu dois rounds de financiamento totalizando dezenas de milhões de dólares de instituições de investimento como Oasis Capital, IDG Capital e Distributed Capital. Página inicial：www.blocksec.com

Twitter：https://twitter.com/BloquearSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Aviso Legal:

1. Este artigo é reproduzido a partir de [BloquearBloquearSec]. Todos os direitos autorais pertencem ao autor original [BloquearSec]. Se houver objeções a esta reimpressão, entre em contato com oGate Aprenderequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.