A dualidade do mecanismo Hook do Uniswap v4: inovação e riscos potenciais coexistem
Uniswap v4 está prestes a ser lançado, e esta atualização é, sem dúvida, ambiciosa. A nova versão irá introduzir várias novas funcionalidades, incluindo suporte para um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design singleton, contabilidade relâmpago, mecanismo Hook, bem como suporte ao padrão de token ERC1155. Utilizando a tecnologia de armazenamento transitório, 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 tem recebido atenção devido ao seu grande potencial. Este mecanismo 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, o mecanismo Hook também pode ser uma espada de dois gumes. Apesar de ser poderoso e flexível, o uso seguro do Hook enfrenta igualmente desafios significativos. A complexidade do Hook traz inevitavelmente novos vetores de ataque potenciais. Portanto, é necessário apresentar sistematicamente as questões de segurança e os riscos potenciais associados ao mecanismo Hook, a fim de promover o desenvolvimento seguro da comunidade; essas percepções ajudarão a construir um Hook mais seguro para o Uniswap v4.
Este artigo irá apresentar os conceitos relacionados ao mecanismo Hook no Uniswap v4 e resumir os riscos de segurança que ele apresenta.
Mecanismo do Uniswap V4
Antes de aprofundarmos na discussão, precisamos ter uma compreensão básica do mecanismo do Uniswap v4. De acordo com o anúncio oficial e o white paper, Hook, arquitetura de instância única e contabilidade relâmpago são três funcionalidades importantes para a implementação de pools de liquidez personalizados e roteamento eficiente entre vários pools.
1.1 Gancho
Hook refere-se a contratos que operam em diferentes fases do ciclo de vida de um pool de liquidez. A equipe da Uniswap espera que, ao introduzir o Hook, qualquer pessoa possa tomar decisões de ponderação. Essa abordagem pode permitir suporte nativo a taxas dinâmicas, adicionar ordens limitadas na cadeia ou dispersar grandes ordens através de um market maker de média ponderada no tempo (TWAMM).
Atualmente, existem oito callbacks Hook, divididos em quatro grupos (, cada grupo contém um par de callbacks ):
antes de inicializar/depois de inicializar
beforeModifyPosition/afterModifyPosition
beforeSwap/afterSwap
beforeDonate/afterDonate
A equipe do Uniswap forneceu alguns exemplos ( como o TWAMM Hook ) que introduz o método de operação, e os participantes da comunidade também contribuíram. A documentação oficial também linkou para o repositório Awesome Uniswap v4 Hooks, que coleta mais exemplos de Hooks.
1.2 Singleton, contabilização relâmpago e mecanismo de bloqueio
A arquitetura singleton e a contabilidade relâmpago 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 do PoolManager para armazenar e gerenciar o estado de todos os pools.
A versão v4 do Uniswap introduziu o sistema de contabilidade instantânea e o mecanismo de bloqueio. O funcionamento do mecanismo de bloqueio é o seguinte:
O contrato locker solicita lock no PoolManager.
O PoolManager adiciona o endereço do contrato locker à fila lockData e chama seu callback lockAcquired.
O contrato locker executa sua lógica na chamada de retorno. Durante a execução, a interação do contrato locker com o pool pode resultar em um aumento não nulo de moeda. Mas ao final da execução, todos os incrementos devem ser liquidadas como zero. Além disso, se a fila lockData não estiver vazia, apenas o último contrato locker pode executar a operação.
O PoolManager verifica o estado da fila lockData e do aumento da moeda. Após a validação, o PoolManager irá remover o contrato locker.
Em suma, 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 retorno de chamada lockAcquired. Antes e depois de cada operação na piscina, os retornos de chamada correspondentes do Hook serão acionados. Por fim, o PoolManager verificará o estado.
Este método significa que a operação ajusta o saldo líquido interno (, ou seja, delta ), em vez de executar uma transferência instantânea. Quaisquer alterações serão registradas no saldo interno do pool, e a transferência real ocorrerá no final da operação (, ou seja, lock ). 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 feita através do contrato. Este contrato atua como um intermediário de bloqueio, sendo necessário solicitar o bloqueio antes de realizar qualquer operação de pool.
Existem principalmente dois cenários de interação de contratos:
O contrato locker vem do repositório de código oficial ou é implantado pelo usuário. Esta situação pode ser vista como uma interação através de um roteador.
O contrato locker e o Hook estão integrados no mesmo contrato, ou controlados por uma entidade terceira. Esta situação pode ser vista como uma interação através do Hook. Neste caso, o Hook desempenha tanto o papel do contrato locker quanto é responsável pelo tratamento do callback.
Modelo de Ameaças
Antes de discutir as questões de segurança relevantes, precisamos definir o modelo de ameaças. As duas principais situações a considerar são:
Modelo de ameaça I: O Hook em si é benigno, mas contém vulnerabilidades.
Modelo de ameaça II: O Hook em si é malicioso.
A seguir, serão discutidos potenciais problemas de segurança com base nesses dois modelos de ameaça.
2.1 Problemas de segurança no Modelo de Ameaça 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 seus Hooks não são maliciosos. No entanto, as vulnerabilidades conhecidas existentes nos contratos inteligentes também podem aparecer no Hook. Por exemplo, se o Hook for implementado como um contrato atualizável, ele pode encontrar problemas relacionados a vulnerabilidades semelhantes às do OpenZeppelin UUPSUpgradeable.
Dada a fatores acima, escolhemos focar nas potenciais vulnerabilidades específicas da versão v4. No Uniswap v4, o Hook é um contrato inteligente que pode executar lógica personalizada antes ou depois de operar no pool central (, incluindo inicialização, modificação de posição, troca e coleta de ). 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, por exemplo, como o Hook pode abusar dessas funções padrão do Hook.
Especificamente, vamos nos concentrar em dois tipos de Hook:
O primeiro tipo de hook, que armazena os fundos dos usuários. Neste caso, o atacante pode atacar este hook para transferir fundos, causando perda de ativos.
O segundo tipo de hook, armazena dados críticos de estado que dependem do usuário 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, isso pode trazer riscos potenciais.
Por favor, note que hooks fora destes dois âmbitos não estão dentro do nosso alcance de discussão.
Após uma análise aprofundada do repositório Awesome Uniswap v4 Hooks, identificámos várias vulnerabilidades graves. Estas vulnerabilidades são principalmente originadas da interação de risco entre hooks, PoolManager e terceiros externos, podendo ser divididas em duas categorias principais: problemas de controlo de acesso e problemas de validação de entrada.
No geral, encontramos 22 projetos relevantes ( excluindo os projetos não relacionados ao Uniswap v4 ). Dentre esses projetos, acreditamos que 8 (36%) apresentam vulnerabilidades. Desses 8 projetos com vulnerabilidades, 6 apresentam problemas de controle de acesso e 2 são suscetíveis a chamadas externas não confiáveis.
2.1.1 Problemas de controlo de acesso
Nesta parte da discussão, focamos principalmente nos problemas que as funções de callback no v4 podem causar, incluindo 8 callbacks hook e callbacks de lock. Claro que existem outras situações que precisam ser verificadas, mas estas variam conforme 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 de recompensas distribuídas pela chave do fundo, se a função correspondente puder ser chamada por qualquer conta, as recompensas podem ser recebidas incorretamente.
Portanto, para o hook, é essencial estabelecer um forte mecanismo de controle de acesso, especialmente porque ele pode ser chamado por partes além do próprio pool. Ao gerenciar rigorosamente as permissões de acesso, o pool de liquidez pode reduzir significativamente o risco de 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 liquidez. Isso garante que o contrato atual envolvido na interação seja o contrato de bloqueio mais recente.
Apesar disso, existe um cenário de ataque possível, ou seja, chamadas externas não confiáveis devido a uma validação de entrada inadequada em algumas implementações de Hook vulneráveis:
Primeiro, o hook não validou o pool de liquidez com o qual o usuário pretende interagir. Isso pode ser um pool malicioso contendo tokens falsos e executando 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 o ataque de reentrada que conhecemos bem.
Para atacar esses hooks vulneráveis, os atacantes podem registrar um pool de liquidez malicioso para seus tokens falsos e, em seguida, chamar os hooks para executar operações no pool. Ao interagir com o pool de liquidez, a lógica do token malicioso sequestra o fluxo de controle para realizar comportamentos indevidos.
2.1.3 Medidas de proteção contra o modelo de ameaça I
Para evitar problemas de segurança relacionados a hooks, é crucial validar as interações através da implementação adequada de controle de acesso necessário às funções externas/públicas sensíveis e da verificação dos parâmetros de entrada. Além disso, a proteção contra reentradas pode ajudar a garantir que os hooks não sejam executados 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ças II
Neste modelo de ameaça, assumimos que os desenvolvedores e seus hooks são maliciosos. Dado que o escopo é amplo, 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 de ativos criptográficos ou autorizações dos usuários.
Como o método de acesso ao hook determina as permissões que podem ser atribuídas ao hook, classificamos os hooks em duas categorias:
Hook Gerido(Managed Hooks): o hook não é um ponto de entrada. Os usuários devem interagir com o hook através do router( que pode ser fornecido pela Uniswap).
Hooks Independentes(: hook é um ponto de entrada que permite aos usuários interagir diretamente com ele.
)# 2.2.1 Hook de Custódia
Neste caso, os ativos criptográficos do usuário ### incluem tokens nativos e outros tokens ( que são transferidos ou autorizados ao router. Como o PoolManager executou uma verificação de saldo, não é fácil para um hook malicioso roubar esses ativos diretamente. No entanto, ainda existem superfícies de ataque potenciais. 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 Tipo Independente de Hook
Quando o Hook é usado como ponto de entrada, a situação torna-se mais complexa. Nesse caso, como os usuários podem interagir diretamente com o hook, o hook ganha mais poder. Em teoria, 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 crítica. O principal problema reside na possibilidade de manipulação da lógica do código. Se o hook for atualizável, isso significa que um hook aparentemente seguro pode se tornar malicioso após a atualização, representando um risco significativo. Esses riscos incluem:
O agente atualizável ### pode ser atacado diretamente (;
Possui lógica de autodestruição. Pode ser atacado na chamada conjunta de selfdestruct e create2.
)# 2.2.3 Medidas de prevenção para o modelo de ameaça II
Um ponto crucial é avaliar se o hook é malicioso. Especificamente, para hooks geridos, devemos nos concentrar nas práticas de gestão de custos; enquanto para hooks independentes, o foco principal deve ser se eles são atualizáveis.
![Por que se diz que o Hook é uma "arma de dois gumes" do Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusão
Este artigo começa por apresentar uma breve visão geral dos mecanismos centrais relacionados aos problemas de segurança do Hook no Uniswap v4. Em seguida, propomos dois modelos de ameaça e resumimos os riscos de segurança associados.
Nos artigos seguintes, faremos uma análise aprofundada das questões de segurança sob cada modelo de ameaça.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
17 Curtidas
Recompensa
17
5
Compartilhar
Comentário
0/400
OfflineValidator
· 07-31 11:18
Ainda tem que se entender bem o V4
Ver originalResponder0
MetaMisery
· 07-30 04:35
Ainda não é tão estável quanto o v3. Já quer especular sobre conceitos, não é?
Ver originalResponder0
SatoshiNotNakamoto
· 07-30 04:24
Aguardando a v4 aparecer com bugs
Ver originalResponder0
TokenGuru
· 07-30 04:17
Versão evoluída do antigo projeto, os idiotas que embarcam sem pensar vão sofrer novamente.
Análise de segurança do mecanismo Hook do Uniswap v4: inovação e coexistência de riscos
A dualidade do mecanismo Hook do Uniswap v4: inovação e riscos potenciais coexistem
Uniswap v4 está prestes a ser lançado, e esta atualização é, sem dúvida, ambiciosa. A nova versão irá introduzir várias novas funcionalidades, incluindo suporte para um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design singleton, contabilidade relâmpago, mecanismo Hook, bem como suporte ao padrão de token ERC1155. Utilizando a tecnologia de armazenamento transitório, 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 tem recebido atenção devido ao seu grande potencial. Este mecanismo 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, o mecanismo Hook também pode ser uma espada de dois gumes. Apesar de ser poderoso e flexível, o uso seguro do Hook enfrenta igualmente desafios significativos. A complexidade do Hook traz inevitavelmente novos vetores de ataque potenciais. Portanto, é necessário apresentar sistematicamente as questões de segurança e os riscos potenciais associados ao mecanismo Hook, a fim de promover o desenvolvimento seguro da comunidade; essas percepções ajudarão a construir um Hook mais seguro para o Uniswap v4.
Este artigo irá apresentar os conceitos relacionados ao mecanismo Hook no Uniswap v4 e resumir os riscos de segurança que ele apresenta.
Mecanismo do Uniswap V4
Antes de aprofundarmos na discussão, precisamos ter uma compreensão básica do mecanismo do Uniswap v4. De acordo com o anúncio oficial e o white paper, Hook, arquitetura de instância única e contabilidade relâmpago são três funcionalidades importantes para a implementação de pools de liquidez personalizados e roteamento eficiente entre vários pools.
1.1 Gancho
Hook refere-se a contratos que operam em diferentes fases do ciclo de vida de um pool de liquidez. A equipe da Uniswap espera que, ao introduzir o Hook, qualquer pessoa possa tomar decisões de ponderação. Essa abordagem pode permitir suporte nativo a taxas dinâmicas, adicionar ordens limitadas na cadeia ou dispersar grandes ordens através de um market maker de média ponderada no tempo (TWAMM).
Atualmente, existem oito callbacks Hook, divididos em quatro grupos (, cada grupo contém um par de callbacks ):
A equipe do Uniswap forneceu alguns exemplos ( como o TWAMM Hook ) que introduz o método de operação, e os participantes da comunidade também contribuíram. A documentação oficial também linkou para o repositório Awesome Uniswap v4 Hooks, que coleta mais exemplos de Hooks.
1.2 Singleton, contabilização relâmpago e mecanismo de bloqueio
A arquitetura singleton e a contabilidade relâmpago 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 do PoolManager para armazenar e gerenciar o estado de todos os pools.
A versão v4 do Uniswap introduziu o sistema de contabilidade instantânea e o mecanismo de bloqueio. O funcionamento do mecanismo de bloqueio é o seguinte:
O contrato locker solicita lock no PoolManager.
O PoolManager adiciona o endereço do contrato locker à fila lockData e chama seu callback lockAcquired.
O contrato locker executa sua lógica na chamada de retorno. Durante a execução, a interação do contrato locker com o pool pode resultar em um aumento não nulo de moeda. Mas ao final da execução, todos os incrementos devem ser liquidadas como zero. Além disso, se a fila lockData não estiver vazia, apenas o último contrato locker pode executar a operação.
O PoolManager verifica o estado da fila lockData e do aumento da moeda. Após a validação, o PoolManager irá remover o contrato locker.
Em suma, 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 retorno de chamada lockAcquired. Antes e depois de cada operação na piscina, os retornos de chamada correspondentes do Hook serão acionados. Por fim, o PoolManager verificará o estado.
Este método significa que a operação ajusta o saldo líquido interno (, ou seja, delta ), em vez de executar uma transferência instantânea. Quaisquer alterações serão registradas no saldo interno do pool, e a transferência real ocorrerá no final da operação (, ou seja, lock ). 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 feita através do contrato. Este contrato atua como um intermediário de bloqueio, sendo necessário solicitar o bloqueio antes de realizar qualquer operação de pool.
Existem principalmente dois cenários de interação de contratos:
O contrato locker vem do repositório de código oficial ou é implantado pelo usuário. Esta situação pode ser vista como uma interação através de um roteador.
O contrato locker e o Hook estão integrados no mesmo contrato, ou controlados por uma entidade terceira. Esta situação pode ser vista como uma interação através do Hook. Neste caso, o Hook desempenha tanto o papel do contrato locker quanto é responsável pelo tratamento do callback.
Modelo de Ameaças
Antes de discutir as questões de segurança relevantes, precisamos definir o modelo de ameaças. As duas principais situações a considerar são:
Modelo de ameaça I: O Hook em si é benigno, mas contém vulnerabilidades.
Modelo de ameaça II: O Hook em si é malicioso.
A seguir, serão discutidos potenciais problemas de segurança com base nesses dois modelos de ameaça.
2.1 Problemas de segurança no Modelo de Ameaça 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 seus Hooks não são maliciosos. No entanto, as vulnerabilidades conhecidas existentes nos contratos inteligentes também podem aparecer no Hook. Por exemplo, se o Hook for implementado como um contrato atualizável, ele pode encontrar problemas relacionados a vulnerabilidades semelhantes às do OpenZeppelin UUPSUpgradeable.
Dada a fatores acima, escolhemos focar nas potenciais vulnerabilidades específicas da versão v4. No Uniswap v4, o Hook é um contrato inteligente que pode executar lógica personalizada antes ou depois de operar no pool central (, incluindo inicialização, modificação de posição, troca e coleta de ). 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, por exemplo, como o Hook pode abusar dessas funções padrão do Hook.
Especificamente, vamos nos concentrar em dois tipos de Hook:
O primeiro tipo de hook, que armazena os fundos dos usuários. Neste caso, o atacante pode atacar este hook para transferir fundos, causando perda de ativos.
O segundo tipo de hook, armazena dados críticos de estado que dependem do usuário 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, isso pode trazer riscos potenciais.
Por favor, note que hooks fora destes dois âmbitos não estão dentro do nosso alcance de discussão.
Após uma análise aprofundada do repositório Awesome Uniswap v4 Hooks, identificámos várias vulnerabilidades graves. Estas vulnerabilidades são principalmente originadas da interação de risco entre hooks, PoolManager e terceiros externos, podendo ser divididas em duas categorias principais: problemas de controlo de acesso e problemas de validação de entrada.
No geral, encontramos 22 projetos relevantes ( excluindo os projetos não relacionados ao Uniswap v4 ). Dentre esses projetos, acreditamos que 8 (36%) apresentam vulnerabilidades. Desses 8 projetos com vulnerabilidades, 6 apresentam problemas de controle de acesso e 2 são suscetíveis a chamadas externas não confiáveis.
2.1.1 Problemas de controlo de acesso
Nesta parte da discussão, focamos principalmente nos problemas que as funções de callback no v4 podem causar, incluindo 8 callbacks hook e callbacks de lock. Claro que existem outras situações que precisam ser verificadas, mas estas variam conforme 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 de recompensas distribuídas pela chave do fundo, se a função correspondente puder ser chamada por qualquer conta, as recompensas podem ser recebidas incorretamente.
Portanto, para o hook, é essencial estabelecer um forte mecanismo de controle de acesso, especialmente porque ele pode ser chamado por partes além do próprio pool. Ao gerenciar rigorosamente as permissões de acesso, o pool de liquidez pode reduzir significativamente o risco de 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 liquidez. Isso garante que o contrato atual envolvido na interação seja o contrato de bloqueio mais recente.
Apesar disso, existe um cenário de ataque possível, ou seja, chamadas externas não confiáveis devido a uma validação de entrada inadequada em algumas implementações de Hook vulneráveis:
Primeiro, o hook não validou o pool de liquidez com o qual o usuário pretende interagir. Isso pode ser um pool malicioso contendo tokens falsos e executando 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 o ataque de reentrada que conhecemos bem.
Para atacar esses hooks vulneráveis, os atacantes podem registrar um pool de liquidez malicioso para seus tokens falsos e, em seguida, chamar os hooks para executar operações no pool. Ao interagir com o pool de liquidez, a lógica do token malicioso sequestra o fluxo de controle para realizar comportamentos indevidos.
2.1.3 Medidas de proteção contra o modelo de ameaça I
Para evitar problemas de segurança relacionados a hooks, é crucial validar as interações através da implementação adequada de controle de acesso necessário às funções externas/públicas sensíveis e da verificação dos parâmetros de entrada. Além disso, a proteção contra reentradas pode ajudar a garantir que os hooks não sejam executados 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ças II
Neste modelo de ameaça, assumimos que os desenvolvedores e seus hooks são maliciosos. Dado que o escopo é amplo, 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 de ativos criptográficos ou autorizações dos usuários.
Como o método de acesso ao hook determina as permissões que podem ser atribuídas ao hook, classificamos os hooks em duas categorias:
Hook Gerido(Managed Hooks): o hook não é um ponto de entrada. Os usuários devem interagir com o hook através do router( que pode ser fornecido pela Uniswap).
Hooks Independentes(: hook é um ponto de entrada que permite aos usuários interagir diretamente com ele.
)# 2.2.1 Hook de Custódia
Neste caso, os ativos criptográficos do usuário ### incluem tokens nativos e outros tokens ( que são transferidos ou autorizados ao router. Como o PoolManager executou uma verificação de saldo, não é fácil para um hook malicioso roubar esses ativos diretamente. No entanto, ainda existem superfícies de ataque potenciais. 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 Tipo Independente de Hook
Quando o Hook é usado como ponto de entrada, a situação torna-se mais complexa. Nesse caso, como os usuários podem interagir diretamente com o hook, o hook ganha mais poder. Em teoria, 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 crítica. O principal problema reside na possibilidade de manipulação da lógica do código. Se o hook for atualizável, isso significa que um hook aparentemente seguro pode se tornar malicioso após a atualização, representando um risco significativo. Esses riscos incluem:
O agente atualizável ### pode ser atacado diretamente (;
Possui lógica de autodestruição. Pode ser atacado na chamada conjunta de selfdestruct e create2.
)# 2.2.3 Medidas de prevenção para o modelo de ameaça II
Um ponto crucial é avaliar se o hook é malicioso. Especificamente, para hooks geridos, devemos nos concentrar nas práticas de gestão de custos; enquanto para hooks independentes, o foco principal deve ser se eles são atualizáveis.
![Por que se diz que o Hook é uma "arma de dois gumes" do Uniswap V4?]###https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp(
Conclusão
Este artigo começa por apresentar uma breve visão geral dos mecanismos centrais relacionados aos problemas de segurança do Hook no Uniswap v4. Em seguida, propomos dois modelos de ameaça e resumimos os riscos de segurança associados.
Nos artigos seguintes, faremos uma análise aprofundada das questões de segurança sob cada modelo de ameaça.