O Uniswap v4 está prestes a ser lançado, o mecanismo Hook esconde riscos de segurança
A Uniswap v4 está prestes a ser lançada. Esta atualização traz muitas novas funcionalidades, incluindo suporte a um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design de instância única, contabilidade relâmpago, mecanismo Hook, e suporte ao padrão de token ERC1155. Espera-se que a v4 seja lançada após a atualização do Ethereum Cancun.
Entre as muitas inovações, o mecanismo Hook tem recebido atenção devido ao seu grande potencial. Ele permite a execução de código personalizado em pontos 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 desafios. A complexidade do Hook inevitavelmente traz novos vetores de ataque potenciais. Portanto, é especialmente importante apresentar sistematicamente os problemas de segurança e os riscos potenciais relacionados ao mecanismo Hook, o que ajudará a construir um Uniswap v4 Hook mais seguro.
Este artigo irá apresentar os conceitos relacionados ao mecanismo Hook no Uniswap v4 e descrever os riscos de segurança associados.
Mecanismo do Uniswap V4
Antes de aprofundarmos a 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, a arquitetura singleton e o registro relâmpago são três funcionalidades importantes para a implementação de pools de liquidez personalizados e roteamento eficiente entre múltiplos pools.
Gancho
Hook refere-se a contratos que operam em diferentes fases 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 ponderadas. Essa abordagem pode permitir suporte nativo para taxas dinâmicas, adicionar ordens limite on-chain ou realizar a liquidação de grandes ordens através de um market maker ponderado no tempo ( TWAMM ).
Atualmente, existem oito callbacks Hook, divididos em quatro grupos ( cada grupo contém um par de callbacks ):
antesDeInicializar/depoisDeInicializar
beforeModifyPosition/afterModifyPosition
antesTroca/depoisTroca
antesDoar/depoisDoar
Singleton, contabilidade relâmpago e mecanismo de bloqueio
A arquitetura singleton e a contabilidade em tempo real visam melhorar o desempenho ao reduzir custos e garantir 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.
A versão v4 introduziu o registo relâmpago e o mecanismo de bloqueio. O funcionamento do mecanismo de bloqueio é o seguinte:
O contrato locker solicita o bloqueio 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 no callback. Durante a execução, a interação do contrato locker com o pool pode resultar em um aumento de moeda não zero. No entanto, ao final da execução, todos os aumentos 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 incremento de moeda. Após a validação, o PoolManager eliminará o contrato do 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 da chamada de retorno 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 a operação ajusta o saldo líquido interno (, ou seja, delta ), em vez de executar uma transferência imediata. Qualquer modificação será registrada no saldo interno do pool, enquanto 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 à presença 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 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 de contratos:
O contrato locker vem do repositório de código oficial ou é implantado pelo usuário. Nesse caso, podemos considerar a interação como realizada através de um roteador.
O contrato locker e o Hook são integrados no mesmo contrato, ou controlados por uma entidade terceira. Para esta situação, podemos considerar a interação como feita através do Hook. Nesse caso, o Hook desempenha tanto o papel do contrato locker quanto é responsável por processar o callback.
Modelo de Ameaça
Antes de discutir as questões de segurança relevantes, precisamos determinar o modelo de ameaça. As principais situações a considerar são as seguintes:
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 as potenciais questões de segurança com base nesses dois modelos de ameaça.
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.
Focamos 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 operações principais do pool (, incluindo inicialização, modificação de posições, troca e coleta de ). Embora o Hook deva implementar uma interface padrão, ele também permite a inclusão de lógica personalizada. Portanto, o escopo da nossa discussão será limitado à lógica que envolve a interface padrão do Hook. Em seguida, tentaremos identificar possíveis fontes de vulnerabilidade, como o Hook pode abusar dessas funções padrão do Hook.
Especificamente, vamos focar nas seguintes duas Hooks:
O primeiro tipo de hook, que guarda 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íticos dependentes do usuário ou de outros protocolos. Nesse caso, o atacante pode tentar alterar o estado crítico. Quando outros usuários ou protocolos usam um estado incorreto, isso pode representar riscos potenciais.
Após uma análise aprofundada do repositório Awesome Uniswap v4 Hooks, descobrimos várias vulnerabilidades sérias. Essas vulnerabilidades decorrem principalmente da interação de risco entre hooks, PoolManager e terceiros externos, podendo ser classificadas em duas categorias: problemas de controle de acesso e problemas de validação de entrada.
No geral, identificamos 22 projetos relevantes ( excluindo projetos que não estão relacionados ao Uniswap v4 ). Dentre esses projetos, acreditamos que 8 (36%) projetos apresentam vulnerabilidades. Dentre esses 8 projetos vulneráveis, 6 apresentam problemas de controle de acesso e 2 são suscetíveis a chamadas externas não confiáveis.
Problemas de controle de acesso
Nesta parte da discussão, focamos principalmente nos problemas que as funções de callback no v4 podem causar, incluindo 8 hooks de callback e o callback de lock. Essas funções devem ser chamadas apenas pelo PoolManager e não podem ser chamadas por outros endereços (, incluindo EOA e contrato ). Por exemplo, no caso em que as recompensas são distribuídas pela chave do fundo, se a função correspondente puder ser chamada por qualquer conta, as recompensas poderão ser recebidas incorretamente.
Portanto, para o hook, é crucial estabelecer um mecanismo de controle de acesso robusto, especialmente porque ele pode ser chamado por outras 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.
Questões 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 executar qualquer operação no pool de fundos. Isso garante que o contrato que está atualmente participando da interação seja o contrato de bloqueio mais recente.
No entanto, ainda existe um cenário de ataque possível, que é a chamada externa não confiável resultante de validação de entrada inadequada em algumas implementações de Hook vulneráveis:
Primeiro, o hook não verificou o pool de liquidez que 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 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, um atacante pode registrar um pool de liquidez malicioso para seus tokens falsos 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 prejudiciais.
Medidas de prevençã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 do 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 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 tais ameaças.
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 alcance é 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 ou autorização de ativos criptográficos do usuário.
Devido ao fato de 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 gerido ( Managed Hooks ): 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(: um hook é um ponto de entrada que permite aos usuários interagir diretamente com ele.
)# 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 executa 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.
)# Hook independente
Quando o Hook é usado como ponto de entrada, a situação torna-se ainda mais complexa. Nesse caso, uma vez que os usuários podem interagir diretamente com o hook, ele 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 proxy atualizável ### pode ser atacado diretamente (;
Com lógica de autodestruição. Pode ser atacado no caso de uma chamada conjunta de selfdestruct e create2.
)# Medidas de mitigação para o modelo de ameaça II
Um ponto crucial é avaliar se o hook é malicioso. Especificamente, para hooks geridos, devemos nos concentrar no comportamento de gestão de custos; enquanto para hooks independentes, o foco principal está em saber 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 resume os mecanismos centrais relacionados aos problemas de segurança do Hook do Uniswap v4, apresenta dois modelos de ameaça e descreve os riscos de segurança associados.
Nos artigos seguintes, faremos uma análise aprofundada das questões de segurança em 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.
O mecanismo Hook do Uniswap v4 apresenta riscos de segurança. Especialistas alertam para um uso cauteloso.
O Uniswap v4 está prestes a ser lançado, o mecanismo Hook esconde riscos de segurança
A Uniswap v4 está prestes a ser lançada. Esta atualização traz muitas novas funcionalidades, incluindo suporte a um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design de instância única, contabilidade relâmpago, mecanismo Hook, e suporte ao padrão de token ERC1155. Espera-se que a v4 seja lançada após a atualização do Ethereum Cancun.
Entre as muitas inovações, o mecanismo Hook tem recebido atenção devido ao seu grande potencial. Ele permite a execução de código personalizado em pontos 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 desafios. A complexidade do Hook inevitavelmente traz novos vetores de ataque potenciais. Portanto, é especialmente importante apresentar sistematicamente os problemas de segurança e os riscos potenciais relacionados ao mecanismo Hook, o que ajudará a construir um Uniswap v4 Hook mais seguro.
Este artigo irá apresentar os conceitos relacionados ao mecanismo Hook no Uniswap v4 e descrever os riscos de segurança associados.
Mecanismo do Uniswap V4
Antes de aprofundarmos a 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, a arquitetura singleton e o registro relâmpago são três funcionalidades importantes para a implementação de pools de liquidez personalizados e roteamento eficiente entre múltiplos pools.
Gancho
Hook refere-se a contratos que operam em diferentes fases 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 ponderadas. Essa abordagem pode permitir suporte nativo para taxas dinâmicas, adicionar ordens limite on-chain ou realizar a liquidação de grandes ordens através de um market maker ponderado no tempo ( TWAMM ).
Atualmente, existem oito callbacks Hook, divididos em quatro grupos ( cada grupo contém um par de callbacks ):
Singleton, contabilidade relâmpago e mecanismo de bloqueio
A arquitetura singleton e a contabilidade em tempo real visam melhorar o desempenho ao reduzir custos e garantir 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.
A versão v4 introduziu o registo relâmpago e o mecanismo de bloqueio. O funcionamento do mecanismo de bloqueio é o seguinte:
O contrato locker solicita o bloqueio 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 no callback. Durante a execução, a interação do contrato locker com o pool pode resultar em um aumento de moeda não zero. No entanto, ao final da execução, todos os aumentos 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 incremento de moeda. Após a validação, o PoolManager eliminará o contrato do 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 da chamada de retorno 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 a operação ajusta o saldo líquido interno (, ou seja, delta ), em vez de executar uma transferência imediata. Qualquer modificação será registrada no saldo interno do pool, enquanto 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 à presença 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 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 de contratos:
O contrato locker vem do repositório de código oficial ou é implantado pelo usuário. Nesse caso, podemos considerar a interação como realizada através de um roteador.
O contrato locker e o Hook são integrados no mesmo contrato, ou controlados por uma entidade terceira. Para esta situação, podemos considerar a interação como feita através do Hook. Nesse caso, o Hook desempenha tanto o papel do contrato locker quanto é responsável por processar o callback.
Modelo de Ameaça
Antes de discutir as questões de segurança relevantes, precisamos determinar o modelo de ameaça. As principais situações a considerar são as seguintes:
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 as potenciais questões de segurança com base nesses dois modelos de ameaça.
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.
Focamos 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 operações principais do pool (, incluindo inicialização, modificação de posições, troca e coleta de ). Embora o Hook deva implementar uma interface padrão, ele também permite a inclusão de lógica personalizada. Portanto, o escopo da nossa discussão será limitado à lógica que envolve a interface padrão do Hook. Em seguida, tentaremos identificar possíveis fontes de vulnerabilidade, como o Hook pode abusar dessas funções padrão do Hook.
Especificamente, vamos focar nas seguintes duas Hooks:
O primeiro tipo de hook, que guarda 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íticos dependentes do usuário ou de outros protocolos. Nesse caso, o atacante pode tentar alterar o estado crítico. Quando outros usuários ou protocolos usam um estado incorreto, isso pode representar riscos potenciais.
Após uma análise aprofundada do repositório Awesome Uniswap v4 Hooks, descobrimos várias vulnerabilidades sérias. Essas vulnerabilidades decorrem principalmente da interação de risco entre hooks, PoolManager e terceiros externos, podendo ser classificadas em duas categorias: problemas de controle de acesso e problemas de validação de entrada.
No geral, identificamos 22 projetos relevantes ( excluindo projetos que não estão relacionados ao Uniswap v4 ). Dentre esses projetos, acreditamos que 8 (36%) projetos apresentam vulnerabilidades. Dentre esses 8 projetos vulneráveis, 6 apresentam problemas de controle de acesso e 2 são suscetíveis a chamadas externas não confiáveis.
Problemas de controle de acesso
Nesta parte da discussão, focamos principalmente nos problemas que as funções de callback no v4 podem causar, incluindo 8 hooks de callback e o callback de lock. Essas funções devem ser chamadas apenas pelo PoolManager e não podem ser chamadas por outros endereços (, incluindo EOA e contrato ). Por exemplo, no caso em que as recompensas são distribuídas pela chave do fundo, se a função correspondente puder ser chamada por qualquer conta, as recompensas poderão ser recebidas incorretamente.
Portanto, para o hook, é crucial estabelecer um mecanismo de controle de acesso robusto, especialmente porque ele pode ser chamado por outras 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.
Questões 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 executar qualquer operação no pool de fundos. Isso garante que o contrato que está atualmente participando da interação seja o contrato de bloqueio mais recente.
No entanto, ainda existe um cenário de ataque possível, que é a chamada externa não confiável resultante de validação de entrada inadequada em algumas implementações de Hook vulneráveis:
Primeiro, o hook não verificou o pool de liquidez que 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 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, um atacante pode registrar um pool de liquidez malicioso para seus tokens falsos 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 prejudiciais.
Medidas de prevençã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 do 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 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 tais ameaças.
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 alcance é 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 ou autorização de ativos criptográficos do usuário.
Devido ao fato de 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 gerido ( Managed Hooks ): 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(: um hook é um ponto de entrada que permite aos usuários interagir diretamente com ele.
)# 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 executa 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.
)# Hook independente
Quando o Hook é usado como ponto de entrada, a situação torna-se ainda mais complexa. Nesse caso, uma vez que os usuários podem interagir diretamente com o hook, ele 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 proxy atualizável ### pode ser atacado diretamente (;
Com lógica de autodestruição. Pode ser atacado no caso de uma chamada conjunta de selfdestruct e create2.
)# Medidas de mitigação para o modelo de ameaça II
Um ponto crucial é avaliar se o hook é malicioso. Especificamente, para hooks geridos, devemos nos concentrar no comportamento de gestão de custos; enquanto para hooks independentes, o foco principal está em saber 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 resume os mecanismos centrais relacionados aos problemas de segurança do Hook do Uniswap v4, apresenta dois modelos de ameaça e descreve os riscos de segurança associados.
Nos artigos seguintes, faremos uma análise aprofundada das questões de segurança em cada modelo de ameaça.