O mecanismo Hook do Uniswap v4: potencial e riscos coexistem
A Uniswap v4 está prestes a ser lançada, e esta atualização traz várias novas funcionalidades, incluindo suporte a um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design singleton, contabilidade relâmpago, mecanismo Hook, e suporte ao padrão de token ERC1155. Dentre elas, o mecanismo Hook chamou a atenção por seu grande potencial.
O mecanismo Hook permite executar 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. Embora seja poderoso e flexível, o uso seguro do Hook também é um desafio considerável. A complexidade do Hook inevitavelmente traz novos vetores de ataque potenciais.
Este artigo irá apresentar os conceitos relacionados ao mecanismo Hook no Uniswap v4 e resumir os riscos de segurança associados.
Mecanismo central 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 singleton e contabilidade relâmpago são três funções importantes para a implementação de pools de liquidez personalizados e roteamento eficiente entre múltiplos pools.
Mecanismo Hook
Hook refere-se a contratos que operam em diferentes fases do ciclo de vida de um pool de liquidez, com o objetivo de permitir que qualquer pessoa tome decisões ponderadas. Dessa forma, é possível implementar suporte nativo a taxas dinâmicas, adicionar ordens limitadas na cadeia, ou dispersar grandes ordens através de um formador de mercado ponderado pelo 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
antes da troca/depois da troca
antesDoar/depoisDoar
Singleton, contabilidade 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 de um PoolManager para armazenar e gerenciar o estado de todos os pools.
A versão v4 introduziu a contabilidade relâmpago 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 o callback lockAcquired.
O contrato locker executa sua lógica no callback. A interação com o pool durante a execução pode resultar em um aumento não nulo da moeda, mas ao final da execução, todos os aumentos devem ser liquidadas como zero.
O PoolManager verifica o estado da fila lockData e do aumento de moeda. Após a validação, elimina o contrato do locker.
No geral, o mecanismo de bloqueio impede o acesso concorrente e garante que todas as transações possam ser liquidadas. Este método significa que os ajustes operacionais afetam o saldo líquido interno, em vez de realizar transferências instantâneas. Quaisquer modificações serão registradas no saldo interno do pool, enquanto a transferência real ocorrerá no final da operação.
Devido à existência do mecanismo de bloqueio, todas as contas externas (EOA) não podem interagir diretamente com o PoolManager. Qualquer interação deve ser feita através de contratos. Existem principalmente dois cenários de interação com contratos:
O contrato locker vem do repositório oficial de código ou é implantado pelo usuário. Esta situação pode ser vista como uma interação através de um router.
O contrato locker e o Hook sã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.
Modelo de Ameaça
Antes de discutir questões de segurança relacionadas, precisamos definir o modelo de ameaça. As principais considerações são as seguintes duas situações:
Modelo de Ameaça I: O Hook em si é benigno, mas apresenta vulnerabilidades.
Modelo de Ameaça II: O Hook em si é malicioso.
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 seu Hook são benevolentes. No entanto, as vulnerabilidades conhecidas existentes em contratos inteligentes também podem aparecer no Hook.
Escolhemos focar nas vulnerabilidades potenciais específicas da versão v4, com ênfase nas seguintes duas Hooks:
Hook que guarda os fundos dos usuários. Um atacante pode atacar esse Hook para transferir fundos, resultando em perdas de ativos.
Hook que armazena dados de estado crítico dependentes de usuários ou outros protocolos. Um atacante pode tentar alterar o estado crítico, o que pode trazer riscos potenciais quando outros usuários ou protocolos utilizam um estado incorreto.
Após pesquisa, descobrimos várias vulnerabilidades graves, que resultam principalmente das interações de risco entre o Hook, PoolManager e terceiros externos, podendo ser classificadas em duas categorias: problemas de controle de acesso e problemas de validação de entrada.
Problemas de controlo de acesso
As funções de retorno de chamada no v4 podem causar problemas, incluindo 8 callbacks de Hook e callbacks de bloqueio. Essas funções devem ser chamadas apenas pelo PoolManager e não por outros endereços. Para os Hooks, é crucial estabelecer um mecanismo de controle de acesso robusto, especialmente porque eles podem ser chamados por outras partes além do próprio pool.
Questão de verificação de entrada
Apesar da existência de um mecanismo de bloqueio, ainda existe um cenário de ataque possível, nomeadamente chamadas externas não confiáveis devido a validação de entrada inadequada em algumas implementações de Hook vulneráveis:
O Hook não verificou a pool de fundos com a qual o usuário pretende interagir. Esta pode ser uma pool maliciosa contendo tokens falsos e executando lógica prejudicial.
Algumas funções Hook chave permitem chamadas externas arbitrárias.
Chamadas externas não confiáveis são extremamente perigosas e podem levar a vários tipos de ataques, incluindo ataques de reentrada.
Medidas de prevenção
Para evitar problemas de segurança relacionados ao Hook, é crucial validar as interações através da execução adequada do controle de acesso necessário a funções externas/públicas sensíveis e da validaçã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 novamente no fluxo lógico padrão.
problemas de segurança no Modelo de Ameaças II
Neste modelo de ameaça, presumimos que os desenvolvedores e seus Hooks são maliciosos. A chave está em saber se o Hook fornecido consegue lidar com a transferência ou autorização de ativos criptográficos do usuário.
De acordo com o método de acesso ao Hook, dividimos os Hooks em duas categorias:
Hook de custódia: o Hook não é um ponto de entrada. Os usuários devem interagir com o Hook através do router.
Hook independente: Hook é o ponto de entrada, permitindo que os usuários interajam diretamente com ele.
Hook Custodial
Os ativos criptográficos dos usuários foram 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, como o mecanismo de gestão de taxas da versão v4 que pode ser manipulado por atacantes através de Hooks.
Tipo Independente de Hook
Quando o Hook é usado como ponto de entrada, a situação torna-se mais complicada. O Hook ganha mais poder, podendo teoricamente realizar qualquer operação desejada através dessa interação.
Na versão v4, a validação da lógica do código é muito crucial. O principal problema é se a lógica do código pode ser manipulada. Se o Hook for atualizável, isso significa que um Hook que parece seguro pode se tornar malicioso após a atualização, representando assim um risco significativo. Esses riscos incluem:
O agente atualizável ( pode ser atacado diretamente )
Com lógica de autodestruição. Pode ser atacado na chamada conjunta de selfdestruct e create2.
Medidas de prevenção
Um ponto crucial é avaliar se o Hook é malicioso. Especificamente, para Hooks gerenciados, devemos nos concentrar nas práticas de gerenciamento de taxas; enquanto para Hooks independentes, o foco principal deve ser se são atualizáveis.
Conclusão
Este artigo fornece uma visão geral dos mecanismos fundamentais relacionados às questões de segurança dos Hooks do Uniswap v4 e apresenta dois modelos de ameaça e os riscos de segurança associados. Embora o mecanismo Hook seja poderoso, ele também traz novos desafios de segurança. Desenvolvedores e usuários precisam estar plenamente cientes desses riscos potenciais e tomar as medidas de precaução adequadas para garantir a segurança dos ativos ao usar o Uniswap v4.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
10 gostos
Recompensa
10
6
Partilhar
Comentar
0/400
NightAirdropper
· 08-06 06:42
Brincar até o fim
Ver originalResponder0
WenAirdrop
· 08-05 22:14
O potencial é realmente grande.
Ver originalResponder0
consensus_failure
· 08-05 22:11
A segurança em primeiro lugar.
Ver originalResponder0
CryptoPhoenix
· 08-05 22:06
O risco é o novo crescimento
Ver originalResponder0
GateUser-74b10196
· 08-05 22:05
Não é surpreendente que seja uma atualização épica
Mecanismo Hook do Uniswap v4: desafios de segurança por trás de funcionalidades poderosas
O mecanismo Hook do Uniswap v4: potencial e riscos coexistem
A Uniswap v4 está prestes a ser lançada, e esta atualização traz várias novas funcionalidades, incluindo suporte a um número ilimitado de pools de liquidez por par de negociação e taxas dinâmicas, design singleton, contabilidade relâmpago, mecanismo Hook, e suporte ao padrão de token ERC1155. Dentre elas, o mecanismo Hook chamou a atenção por seu grande potencial.
O mecanismo Hook permite executar 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. Embora seja poderoso e flexível, o uso seguro do Hook também é um desafio considerável. A complexidade do Hook inevitavelmente traz novos vetores de ataque potenciais.
Este artigo irá apresentar os conceitos relacionados ao mecanismo Hook no Uniswap v4 e resumir os riscos de segurança associados.
Mecanismo central 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 singleton e contabilidade relâmpago são três funções importantes para a implementação de pools de liquidez personalizados e roteamento eficiente entre múltiplos pools.
Mecanismo Hook
Hook refere-se a contratos que operam em diferentes fases do ciclo de vida de um pool de liquidez, com o objetivo de permitir que qualquer pessoa tome decisões ponderadas. Dessa forma, é possível implementar suporte nativo a taxas dinâmicas, adicionar ordens limitadas na cadeia, ou dispersar grandes ordens através de um formador de mercado ponderado pelo 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 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 de um PoolManager para armazenar e gerenciar o estado de todos os pools.
A versão v4 introduziu a contabilidade relâmpago 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 o callback lockAcquired.
O contrato locker executa sua lógica no callback. A interação com o pool durante a execução pode resultar em um aumento não nulo da moeda, mas ao final da execução, todos os aumentos devem ser liquidadas como zero.
O PoolManager verifica o estado da fila lockData e do aumento de moeda. Após a validação, elimina o contrato do locker.
No geral, o mecanismo de bloqueio impede o acesso concorrente e garante que todas as transações possam ser liquidadas. Este método significa que os ajustes operacionais afetam o saldo líquido interno, em vez de realizar transferências instantâneas. Quaisquer modificações serão registradas no saldo interno do pool, enquanto a transferência real ocorrerá no final da operação.
Devido à existência do mecanismo de bloqueio, todas as contas externas (EOA) não podem interagir diretamente com o PoolManager. Qualquer interação deve ser feita através de contratos. Existem principalmente dois cenários de interação com contratos:
O contrato locker vem do repositório oficial de código ou é implantado pelo usuário. Esta situação pode ser vista como uma interação através de um router.
O contrato locker e o Hook sã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.
Modelo de Ameaça
Antes de discutir questões de segurança relacionadas, precisamos definir o modelo de ameaça. As principais considerações são as seguintes duas situações:
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 seu Hook são benevolentes. No entanto, as vulnerabilidades conhecidas existentes em contratos inteligentes também podem aparecer no Hook.
Escolhemos focar nas vulnerabilidades potenciais específicas da versão v4, com ênfase nas seguintes duas Hooks:
Hook que guarda os fundos dos usuários. Um atacante pode atacar esse Hook para transferir fundos, resultando em perdas de ativos.
Hook que armazena dados de estado crítico dependentes de usuários ou outros protocolos. Um atacante pode tentar alterar o estado crítico, o que pode trazer riscos potenciais quando outros usuários ou protocolos utilizam um estado incorreto.
Após pesquisa, descobrimos várias vulnerabilidades graves, que resultam principalmente das interações de risco entre o Hook, PoolManager e terceiros externos, podendo ser classificadas em duas categorias: problemas de controle de acesso e problemas de validação de entrada.
Problemas de controlo de acesso
As funções de retorno de chamada no v4 podem causar problemas, incluindo 8 callbacks de Hook e callbacks de bloqueio. Essas funções devem ser chamadas apenas pelo PoolManager e não por outros endereços. Para os Hooks, é crucial estabelecer um mecanismo de controle de acesso robusto, especialmente porque eles podem ser chamados por outras partes além do próprio pool.
Questão de verificação de entrada
Apesar da existência de um mecanismo de bloqueio, ainda existe um cenário de ataque possível, nomeadamente chamadas externas não confiáveis devido a validação de entrada inadequada em algumas implementações de Hook vulneráveis:
O Hook não verificou a pool de fundos com a qual o usuário pretende interagir. Esta pode ser uma pool maliciosa contendo tokens falsos e executando lógica prejudicial.
Algumas funções Hook chave permitem chamadas externas arbitrárias.
Chamadas externas não confiáveis são extremamente perigosas e podem levar a vários tipos de ataques, incluindo ataques de reentrada.
Medidas de prevenção
Para evitar problemas de segurança relacionados ao Hook, é crucial validar as interações através da execução adequada do controle de acesso necessário a funções externas/públicas sensíveis e da validaçã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 novamente no fluxo lógico padrão.
problemas de segurança no Modelo de Ameaças II
Neste modelo de ameaça, presumimos que os desenvolvedores e seus Hooks são maliciosos. A chave está em saber se o Hook fornecido consegue lidar com a transferência ou autorização de ativos criptográficos do usuário.
De acordo com o método de acesso ao Hook, dividimos os Hooks em duas categorias:
Hook de custódia: o Hook não é um ponto de entrada. Os usuários devem interagir com o Hook através do router.
Hook independente: Hook é o ponto de entrada, permitindo que os usuários interajam diretamente com ele.
Hook Custodial
Os ativos criptográficos dos usuários foram 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, como o mecanismo de gestão de taxas da versão v4 que pode ser manipulado por atacantes através de Hooks.
Tipo Independente de Hook
Quando o Hook é usado como ponto de entrada, a situação torna-se mais complicada. O Hook ganha mais poder, podendo teoricamente realizar qualquer operação desejada através dessa interação.
Na versão v4, a validação da lógica do código é muito crucial. O principal problema é se a lógica do código pode ser manipulada. Se o Hook for atualizável, isso significa que um Hook que parece seguro pode se tornar malicioso após a atualização, representando assim um risco significativo. Esses riscos incluem:
Medidas de prevenção
Um ponto crucial é avaliar se o Hook é malicioso. Especificamente, para Hooks gerenciados, devemos nos concentrar nas práticas de gerenciamento de taxas; enquanto para Hooks independentes, o foco principal deve ser se são atualizáveis.
Conclusão
Este artigo fornece uma visão geral dos mecanismos fundamentais relacionados às questões de segurança dos Hooks do Uniswap v4 e apresenta dois modelos de ameaça e os riscos de segurança associados. Embora o mecanismo Hook seja poderoso, ele também traz novos desafios de segurança. Desenvolvedores e usuários precisam estar plenamente cientes desses riscos potenciais e tomar as medidas de precaução adequadas para garantir a segurança dos ativos ao usar o Uniswap v4.