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

Desta vez, a equipa Uniswap estabeleceu metas ambiciosas e planeia introduzir muitas novas funcionalidades, incluindo um número ilimitado de pools de liquidez e taxas dinâmicas para cada par de negociação, design singleton, contabilidade flash, Hook e suporte para o padrão de token ERC1155. Utilizando 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 as muitas inovações, o mecanismo Hook tem ganho ampla atenção devido ao seu grande potencial. O mecanismo Hook permite que um código específico seja executado em pontos específicos do 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 espada de dois gumes. Embora seja poderoso e flexível, o uso seguro do Hook 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 as questões de segurança e os riscos potenciais relacionados com o mecanismo Hook, de forma a promover o desenvolvimento de segurança da comunidade. Acreditamos que estas perceções ajudarão a construir Hooks Uniswap v4 seguros. Como primeiro artigo desta série, este artigo introduz os conceitos relacionados com o mecanismo Hook no Uniswap v4 e delineia os riscos de segurança associados com o mecanismo Hook.

- 1 - Mecanismo do Uniswap V4

Antes de aprofundarmos, 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 características importantes que permitem pools de liquidez personalizadas e roteamento eficiente entre várias pools.

1.1 Gancho

Hooks referem-se a contratos que são executados em diferentes fases do ciclo de vida de uma pool de liquidez. A equipa da Uniswap espera permitir a qualquer pessoa tomar decisões de compensação ao introduzir Hooks. Desta forma, o suporte nativo para taxas dinâmicas, ordens limitadas on-chain ou market makers médios ponderados no tempo (TWAMMs) para dividir grandes encomendas 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
• beforeDonate/afterDonate

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

Figura 1: Fluxo de Swap Hook

A equipe 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 está ligada ao repositório Awesome Uniswap v4 Hooks [5], que coleta mais exemplos de Hook.

1.2 Singleton, Contabilidade Flash e Mecanismo de Bloqueio

A arquitetura singleton e a contabilidade flash visam melhorar o desempenho ao reduzir custos e garantir eficiência. 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 gerir 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 ao introduzir a contabilidade flash e um mecanismo de bloqueio.

👇🏻 O mecanismo de bloqueio funciona da seguinte forma: 1. Um contrato de armazenamento solicita um bloqueio ao PoolManager. 2. O PoolManager adiciona o endereço do contrato de armazenamento à fila de dados de bloqueio e chama o seu retorno de bloqueio adquirido. 3. O contrato de armazenamento executa a sua lógica no retorno. As 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 resultar em zero líquido. Além disso, se a fila de dados de bloqueio não estiver vazia, apenas o último contrato de armazenamento 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 armazenamento.

Em resumo, o mecanismo de bloqueio previne o acesso concorrente e garante que todas as transações possam ser liquidadas. Os contratos Locker solicitam bloqueios em sequência, em seguida executam negociações através do callback lockAcquired. Os callbacks Hook correspondentes são acionados antes e depois de cada operação na 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 da pool, com as transferências reais ocorrendo quando a operação (ou seja, bloqueio) é concluída. Esse processo garante que não haja tokens pendentes, mantendo a integridade dos fundos. Devido ao mecanismo de bloqueio, as contas de propriedade externa (EOAs) não podem interagir diretamente com o PoolManager. Em vez disso, qualquer interação deve passar por um contrato. Este contrato age como um locker intermediário, solicitando um bloqueio antes de realizar qualquer operação na pool. (12/08)

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

• Um contrato de armário vem da base de código oficial, ou é implantado por um usuário. Neste caso, podemos ver a interação como passando por um router.
• Um contrato de armário 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 armário quanto do tratamento das chamadas de retorno.

- 2 -Modelo de Ameaça

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

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

Nas secções seguintes, discutiremos possíveis problemas de segurança de acordo com estes dois modelos de ameaças.

2.1 Problemas 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ça assume que o programador e o seu Hook não são maliciosos. No entanto, as vulnerabilidades conhecidas em contratos inteligentes podem também aparecer nos Hooks. Por exemplo, se um Hook for implementado como um contrato atualizável, poderá encontrar problemas relacionados com vulnerabilidades como a OpenZeppelin UUPSUpgradeable. Dado os factores acima, optamos por nos concentrar em potenciais vulnerabilidades 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 do pool (incluindo inicialização, modificação de posição, troca e recolha). Embora se espere que os Hooks implementem uma interface padrão, também permitem lógica personalizada. Portanto, a nossa discussão será limitada à lógica envolvendo as interfaces padrão do Hook. Tentaremos então identificar possíveis fontes de vulnerabilidades, por exemplo, como os Hooks podem abusar destas funções padrão do Hook.

👇🏻 Especificamente, vamos focar nos seguintes dois tipos de Hooks:

• O primeiro tipo de gancho mantém os fundos do utilizador. Neste caso, um atacante pode atacar este gancho para transferir fundos, causando perda de ativos.
• O segundo tipo de gancho armazena dados críticos do estado em que os utilizadores ou outros protocolos confiam. Neste caso, um atacante pode tentar alterar o estado crítico. Quando outros utilizadores ou protocolos utilizam o estado incorreto, podem surgir potenciais riscos.

Note que os ganchos fora destes dois âmbitos não são discutidos aqui. Uma vez que não há casos de uso de Hooks do mundo real no momento da escrita deste texto, iremos retirar algumas informações do repositório Awesome Uniswap v4 Hooks. Após um estudo aprofundado do repositório Awesome Uniswap v4 Hooks (hash de commit 3a0a444922f26605ec27a41929f3ced924af6075), identificamos várias vulnerabilidades graves. Estas vulnerabilidades derivam principalmente de interações arriscadas entre o gancho, PoolManager e terceiros externos, e podem ser divididas em duas categorias: problemas de controlo de acesso e problemas de validação de entrada. Os resultados específicos são apresentados na tabela abaixo:

Em resumo, identificámos 22 projetos relevantes (excluindo os não relacionados com o Uniswap v4). Entre esses projetos, acreditamos que 8 (36%) têm vulnerabilidades. Dos 8 projetos vulneráveis, 6 têm problemas de controlo de acesso e 2 são vulneráveis a chamadas externas não confiáveis.

2.1.1 Questões de Controlo de Acesso

Nesta parte da discussão, focamo-nos principalmente nos problemas que as funções de retorno de chamada na v4 podem causar, incluindo os 8 callbacks de gancho e o callback de bloqueio. Claro que existem outros casos que precisam de verificação, mas variam conforme o design e estão atualmente fora do âmbito. Estas funções só devem ser chamadas pelo PoolManager, não por outros endereços (incluindo EOAs e contratos). Por exemplo, no caso em que as recompensas são distribuídas a partir das chaves do pool, as recompensas poderiam ser reclamadas incorretamente se as funções correspondentes fossem chamadas por contas arbitrárias. Portanto, estabelecer mecanismos fortes de controlo de acesso é crucial para os ganchos, uma vez que podem ser invocados por partes que não os próprios pools. Ao governar estritamente as permissões de acesso, as pools de liquidez podem reduzir significativamente os riscos associados às interações não autorizadas ou maliciosas com ganchos.

Problemas de Validação de Entrada 2.1.2

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

• Primeiro, o gancho não verifica o pool com o qual o utilizador pretende interagir. Este poderia ser um pool malicioso com tokens falsos a executar 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 bem conhecidos ataques de reentrância. Para atacar esses ganchos vulneráveis, o atacante pode registrar um pool malicioso com tokens falsos para si próprio e, em seguida, invocar o gancho para executar operações no pool. Ao interagir com o pool, a lógica do token malicioso sequestra o fluxo de controle para má conduta.

2.1.3 Medidas de Contramedida para Modelo de Ameaça I

Para contornar problemas de segurança relacionados com hooks, é crucial executar adequadamente o controlo de acesso necessário nas 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 hooks não são 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 Questões de Segurança no Modelo de Ameaças II

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

• Hooks Geridos: O hook não é um ponto de entrada. Os utilizadores devem interagir com o hook através de um router (possivelmente fornecido pela Uniswap).
• Ganchos Autónomos: O gancho é um ponto de entrada, permitindo que os utilizadores interajam diretamente com ele.

Figura 2: Exemplo de gancho malicioso

2.2.1 Ganchos Geridos

Neste caso, os ativos de criptomoeda dos utilizadores (incluindo tokens nativos e outros tokens) são transferidos ou aprovados para o router. Uma vez que o PoolManager realiza verificações de saldo, hooks maliciosos não conseguem facilmente roubar diretamente esses ativos. No entanto, ainda existem superfícies de ataque potenciais. Por exemplo, o mecanismo de gestão de taxas na versão 4 pode ser manipulado por um atacante através de hooks.

2.2.2 Ganchos Autónomos

Quando os ganchos são usados como pontos de entrada, a situação torna-se mais complexa. Aqui, uma vez que os utilizadores podem interagir diretamente com o gancho, este tem mais poder. Na teoria, o gancho pode executar quaisquer operações desejadas através 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 diretamente atacados)
• 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ça II

Um ponto essencial é avaliar se os hooks são maliciosos. Especificamente, para os hooks geridos, devemos estar atentos ao comportamento de gestão de taxas; enquanto que para os hooks autónomos, o foco principal está em saber se são atualizáveis.

- 3 - Conclusão

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

Referências

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

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

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

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

[5] Ganchos Uniswap v4 incríveis
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 BlocoSec BlocoSec é uma empresa líder em segurança blockchain fundada em 2021 por especialistas renomados na indústria de segurança. A empresa dedica-se a melhorar a segurança e usabilidade para o mundo Web3, a fim de promover a adoção generalizada do Web3. Para alcançar isso, a BlocoSec 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 já atendeu mais de 300 clientes, incluindo projetos conhecidos como MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, e recebeu dois rounds de financiamento totalizando mais de 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/BlocoSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Aviso Legal：

1. Este artigo é reimpresso de [BlocoBlocoSec]. Todos os direitos de autor pertencem ao autor original [BlocoSec]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Aprenderequipa, e eles vão tratar disso prontamente.
2. Responsabilidade de Isenção: 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 mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.