No mundo da blockchain, os utilizadores muitas vezes precisam de conceder permissões (autorizações) que permitem que os contratos inteligentes gastem tokens em seu nome. Por exemplo, ao utilizar uma bolsa descentralizada (DEX) para trocar tokens, um utilizador deve primeiro autorizar o contrato de troca a transferir uma quantidade específica de tokens da sua carteira. Sob oERC-20segundo o padrão, este processo requer duas transações separadas na cadeia: uma para aprovação e outra para a transferência real do token. Este processo de dois passos não só é complicado, como também acarreta taxas de gás adicionais. Para melhorar tanto a experiência do utilizador como a segurança, a comunidade Ethereum introduziu um mecanismo de autorização baseado em assinatura.Permissão (como EIP-2612), e posteriormente desenvolveu uma versão avançada chamada Permit2. Estes novos mecanismos permitem aos utilizadores conceder aprovações de token através de assinaturas fora da cadeia, evitando a necessidade de transações adicionais na cadeia.

Neste artigo, começaremos com o básico, explicando como funcionam as aprovações tradicionais do ERC-20 e suas limitações. Em seguida, mergulharemos em como a função Permit e Permit2, destacando seus benefícios e compensações, e discutiremos como eles aprimoram tanto a eficiência quanto a segurança. Também examinaremos os possíveis riscos de segurança, particularmente ataques de phishing envolvendo assinaturas maliciosase oferecer dicas para manter-se seguro. Se é novo no blockchain ou está apenas a começar a sua jornada de investimento em criptomoedas, este guia tem como objetivo ajudá-lo a compreender estas importantes inovações técnicas.

Fundamentos do Modelo de Autorização ERC-20

Antes de mergulharmos no Permit, vamos primeiro dar uma olhada em como o modelo tradicional de autorização de token ERC-20 funciona e nas limitações que apresenta.

Como funcionam as aprovações tradicionais ERC-20

ERC-20 é o padrão para tokens na Ethereum. Define funções como aprovar e transferirDe, que em conjunto permitem autorização de token. Autorização significa que um detentor de tokens (o proprietário) permite a outra conta, normalmente um contrato inteligente (o gastador), transferir uma certa quantidade de tokens em seu nome. O processo básico funciona assim:

1. O detentor do token chama a função approve(spender, amount) do contrato do token. Isso regista a permissão no mapeamento interno do contrato, geralmente expressa como allowance[owner][spender] = amount. Por exemplo, se o usuário A autorizar o contrato Uniswap a gastar até 100 tokens, o contrato irá armazenar allowance[A][Uniswap] = 100. Este passo requer uma transação on-chain e taxas de gás pagas por A.
2. DeleGate.iod Transfer (transferFrom): Mais tarde, quando a Uniswap (ou outra dApp) precisa gastar tokens em nome de A, ela chama transferFrom(A, B, quantidade) no contrato de token. O contrato verifica se a permissão[A][Uniswap] é suficiente. Se for, o contrato transfere a quantidade especificada de A para B e deduz essa quantidade da permissão.

Limitações e Desafios do Modelo de Aprovação

O modelo de dois passos acima permite que os utilizadores autorizem contratos para gerir os seus fundos, sem nunca partilharem as suas chaves privadas. No entanto, esta abordagem tradicional também vem com vários problemas práticos:

Duas transações necessárias, má experiência do utilizador
Cada vez que um utilizador pretende utilizar um novo token numa dApp, deve primeiro enviar uma transação de aprovação separada antes de poder efetivamente realizar a ação desejada (como trocar ou fazer staking). Isto significa que a sua carteira irá solicitar-lhes confirmação duas vezes e cobrar taxas de gás adicionais. Para iniciantes, este passo extra pode ser confuso e inconveniente.

Gestão fragmentada de aprovação
Quando os utilizadores interagem com múltiplos dAppsusando o mesmo token (por exemplo, negociando na Uniswap e depois depositando em um protocolo DeFi diferente), cada dApp requer uma aprovação separada, mesmo que seja o mesmo token na mesma carteira. Isso leva a aprovações repetitivas, desperdiçando tempo e gás.

Além disso, uma vez que cada dApp gere as suas próprias permissões de forma independente, os utilizadores têm pouco controlo centralizado sobre as suas aprovações. Algumas ferramentas, como Revoke.casheDeBank, permitindo aos utilizadores visualizar e gerir as permissões de tokens, mas muitos utilizadores não estão cientes delas. E mesmo que estejam, revogar as permissões ainda requer uma transação on-chain, o que adiciona custos. Como resultado, muitas aprovações antigas ou não utilizadas são simplesmente esquecidas.

Os riscos de aprovações ilimitadas
Para evitar transações de aprovação frequentes, muitas dApps sugerem que os utilizadores concedam uma aprovação ilimitada, permitindo que o contrato gaste todo o saldo de tokens do utilizador, sem expiração. Embora esta abordagem poupe esforço mais tarde, introduz sérios riscos de segurança: se a dApp ou o contrato forem comprometidos, um atacante poderá esgotar todos os tokens aprovados.

Estes desafios levaram os programadores a procurar melhores alternativas. Idealmente, os utilizadores só deveriam precisar de assinar uma vez (preferencialmente fora da cadeia e sem custos de gás) para completar tanto a aprovação como a ação. A aprovação também deve ser limitada em alcance e duração para minimizar riscos potenciais. Esta é a motivação por trás da introdução do ERC-20 Permit.

Permit: Autorização Baseada em Assinatura ERC-20 (EIP-2612)

O conceito de Permit foi introduzido pela primeira vez porDAIcontrato de stablecoin e posteriormente padronizado como EIP-2612. Em suma, o Permit permite aos utilizadores autorizar transferências de tokens usando assinaturas fora da cadeia, eliminando a necessidade de enviar uma transação de aprovação separada na cadeia. Vamos analisar mais de perto como funciona e suas características distintivas.

Como funciona o Permit

A permissão é um mecanismo de autorização baseado em assinaturas digitais. Segundo o padrão EIP-2612, os contratos de tokens ERC-20 que suportam a Permit adicionam uma função chamada permit() que se parece com isto:

função permitir(
proprietário do endereço, gastador do endereço,
uint256 valor, uint256 prazo,
uint8 v, bytes32 r, bytes32 s
) externo;

Aqui, proprietário, gastador e valor especificam quem dá permissão, quem recebe permissão e a quantidade permitida. O prazo indica quando a assinatura expira. Os parâmetros v, r e s formam oECDSAassinatura digital. Usando Permitir, os utilizadores contornam a aprovação separada on-chain - simplesmente assinam a mensagem (sem pagar Gas) e incluem esta assinatura com a sua transação para completar a autorização num só passo.

Fluxo de trabalho de permissão

Comparado com a aprovação tradicional, o Permit remove a necessidade de uma transação extra on-chain, poupando tempo e taxas de gás. Também permite um controle detalhado sobre as aprovações. Por exemplo, um usuário poderia assinar um Permit que permite gastar exatamente 50 USDC, válido por apenas 5 minutos. Mesmo que a assinatura seja exposta, ela se torna inutilizável após o prazo, reduzindo o risco. Hoje, muitos protocolos DeFi, como as exchanges descentralizadas e plataformas de empréstimos, já suportam o Permit. Exemplos conhecidos incluem Uniswap V2/V3tokens LP, DAI, eUSDC, que implementaram o padrão EIP-2612, permitindo aprovações baseadas em assinatura num único passo.

No entanto, a maior limitação do Permit é que deve ser implementado diretamente dentro do contrato do token. Se o desenvolvedor do token não adicionou o método permit() - o que significa que não suporta o EIP-2612 - então o Permit simplesmente não pode ser usado. Como o EIP-2612 foi introduzido apenas em 2020, muitos tokens mais antigos não o incluem e mesmo tokens mais recentes nem sempre o adotam. Isso restringe a aplicabilidade do Permit: tokens não suportados ainda requerem o fluxo de aprovação tradicional.

Outra questão é que o software da carteira deve lidar e exibir adequadamente as assinaturas de Permissão, que normalmente são formatadas usando EIP-712. A maioria das principais carteiras já suporta isso, mas algumas ainda mostram dados brutos em vez de mensagens legíveis, dificultando a compreensão do usuário sobre o que estão assinando. Sem uma interface clara para EIP-2612, as carteiras podem dificultar a compreensão dos usuários sobre aprovações baseadas em assinatura. Além disso, em casos de implantações paralelas (como contratos com endereços idênticos em diferentes cadeias), as assinaturas podem potencialmente ser reutilizadas em outros ambientes. Portanto, os usuários devem verificar se o ID da cadeia e o endereço do contrato em suas assinaturas correspondem ao ambiente atual para evitar que permissões concedidas para tokens na Cadeia A sejam usadas de forma indevida por endereços de contrato idênticos na Cadeia B.

Em essência, o Permit melhora significativamente a eficiência e flexibilidade das aprovações ERC-20, marcando um marco importante nos mecanismos de aprovação sem gás. No entanto, não é uma solução perfeita: requer suporte ao nível do token e introduz novos riscos. A seguir, examinaremos como o Permit2 da Uniswap se baseia e estende a base estabelecida pelo Permit.

Permit2: Contrato de Gestão de Autorização Universal

À medida que o mecanismo de Permissão ganhou popularidade, surgiu um novo desafio: como estender a conveniência da autorização baseada em assinatura para tokens que não suportam Permissão? Para resolver este problema e otimizar as experiências de autorização em vários cenários, a equipa Uniswap introduziu o Permit2 em 2022. Ao contrário de uma funcionalidade específica do token, o Permit2 é um contrato inteligente de gestão de autorização independente. Age como intermediário para autorizações de token, fornecendo funcionalidades de permissão unificadas e aprimoradas. Vamos analisar os princípios e características do Permit2.

Como Funciona o Permit2

O Permit2 funciona como um serviço de retransmissão de autorização. O seu conceito principal é simples: os utilizadores concedem uma aprovação única ao contrato do Permit2, que depois gere subautorizações subsequentes para várias aplicações. Eis como funciona:

1. Autorização de Permissão Única: Os utilizadores aprovam a Permissão2 para cada token utilizando o método tradicional approve(Permissão2, montante_máximo). Recomenda-se uma quantidade grande ou ilimitada, uma vez que esta é a aprovação principal. Uma vez concluído, o contrato da Permissão2 ganha a capacidade de chamar transferFrom em nome do utilizador para esse token. Isto requer uma transação on-chain, mas apenas precisa de ser feito uma vez.
2. Assinatura fora da cadeia para subautorização: Quando os utilizadores desejam interagir com uma DApp (por exemplo, usando o Roteador Universal Uniswap para trocas de vários tokens), assinam uma mensagem de autorização fora da cadeia seguindo as especificações do Permit2. Esta assinatura inclui detalhes como o token permitido, montante, gastador alvo (como um contrato DApp específico) e tempo de expiração.
3. Pedido de Transferência DApp Usando Assinatura: Quando um DApp recebe a assinatura do usuário e precisa usar tokens, em vez de chamar diretamente o contrato de token, ele chama as funções do Permit2 (como permitTransferFrom). Esta função verifica os dados de assinatura do usuário e confirma que a operação está dentro das permissões concedidas (token, montante, prazo). Após a verificação, o Permit2 utiliza sua aprovação principal para chamar transferFrom, movendo os tokens do usuário para o destinatário especificado. Ponto chave: o contrato do Permit2 atua como o gastador, usando sua própria autoridade para transferir tokens, com uma etapa adicional de verificação de assinatura.
4. Conclusão da operação: Uma vez que o Permit2 executa com sucesso a transferência de transferFrom, os fundos movem-se facilmente do utilizador para a DApp ou endereço especificado. Do ponto de vista do utilizador, eles apenas fornecem uma assinatura na transação, enquanto o contrato trata de todas as ações subsequentes.

O fluxo de autorização do Permit2 é direto: os utilizadores apenas precisam de conceder uma aprovação máxima ao Permit2 uma vez por token. Posteriormente, ao interagir com aplicações (como o Roteador Universal Uniswap ou outros protocolos), basta incluir uma assinatura do Permit2 na sua transação para concluir a autorização e a transferência, sem aprovações adicionais na cadeia. O contrato do Permit2 verifica a assinatura e executa a transferência utilizando a sua aprovação mestre. (Fonte:Apresentando Permit2 & Universal Router)

Através deste modelo, o Permit2 estende o conceito de autorização baseada em assinatura do EIP-2612 a todos os tokens ERC-20, independentemente de implementarem ou não o método permit(). Desde que os utilizadores autorizem inicialmente o contrato Permit2, podem utilizar assinaturas para operações subsequentes. É de salientar que a Uniswap projetou o Permit2 como um contrato sem proprietário e não atualizável, implantado com o mesmo endereço em toda a rede principal do Ethereum e em várias redes de Camada 2. Isto significa que todas as aplicações utilizam na realidade a mesma instância do Permit2, alcançando uma verdadeira funcionalidade de "aprovar uma vez, utilizar em todo o lado".

Principais características do Permit2

Como um sistema de autorização de próxima geração, o Permit2 não só permite aprovações com base em assinaturas para todos os tokens, mas também oferece recursos adicionais para melhorar a segurança e a usabilidade. Aqui estão suas principais características:

Expiração Automática
Todas as autorizações do Permit2 podem incluir um carimbo de data/hora de expiração. Os utilizadores podem especificar quando a sua subautorização deve expirar ao assinar. Uma vez ultrapassado o prazo, o Permit2 irá rejeitar a assinatura, mesmo que a aprovação principal ainda esteja ativa. Isto aborda eficazmente o risco de aprovações indefinidas ficarem sem uso.

Transferências de Assinatura de Uso Único
O Permit2 oferece um modo de transferência de assinatura direta onde os usuários podem autorizar uma transferência de token específica para um destinatário usando apenas uma assinatura, sem a necessidade de definir uma permissão primeiro. Isso é perfeito para cenários de pagamento único: os usuários podem assinar uma mensagem autorizando a transferência de 100 tokens para o endereço de um amigo, e o amigo ou intermediário pode executar a transferência usando essa assinatura. Uma vez usada, a assinatura se torna inválida, não deixando permissões pendentes.

Aprovações e transferências de lotes
O Permit2 prioriza a eficiência, permitindo o processamento em lote de várias aprovações ou transferências. Os utilizadores podem autorizar diferentes montantes de vários tokens para um único protocolo com uma única assinatura, ou executar transferências de vários tokens numa única transação. Isto poupa Gas e reduz passos para utilizadores avançados.

Revogação em lote
Além das aprovações em lote, os utilizadores podem revogar permissões para vários tokens/aplicações numa única transação. Isso torna a limpeza das aprovações históricas muito mais conveniente.

Testemunho de Dados Adicional
Permit2 inclui interfaces como permitirTransferênciaDeTestemunhaDeque permitem incluir dados adicionais de verificação em assinaturas. Isso suporta cenários mais complexos, como incluir detalhes específicos da transação nas assinaturas de ordem para evitar a reutilização de assinaturas em contextos diferentes.

Através destas funcionalidades, o Permit2 não só replica todos os benefícios do Permit, como também melhora a flexibilidade e os controlos de segurança. Em particular, a expiração automática e as transferências de assinaturas de utilização única tornam a autorização mínima necessária a norma, reduzindo os riscos a longo prazo.

Para resumir, o Permit2 funciona tanto como uma extensão quanto como um aprimoramento do mecanismo de Permissão tradicional. Vamos examinar as principais diferenças entre essas duas abordagens:

Adoção e Implementação do Ecossistema Permit2

Desde que a Uniswap introduziu o Permit2, inúmeros projetos integraram esse mecanismo, acelerando a padronização da indústria. De acordo com os dados mais recentes de Dune Analytics, até abril de 2025, mais de 3,1 milhões de endereços da mainnet Ethereum concederam autorização ao contrato Permit2, demonstrando sua ampla adoção.

Estado do Ecossistema e Implementação do Permit2. Fonte:Dune Analytics

Por exemplo, a Uniswap integrou o Permit2 no seu Roteador Universal, permitindo trocas de vários tokens e NFTs numa única transação. Através do Roteador Universal, os utilizadores podem encadear múltiplas operações numa única transação, como trocar três tokens por dois tokens alvo e comprar NFTs, com todos os requisitos de autorização tratados por assinaturas do Permit2. Isto simplifica significativamente o processo e reduz os custos totais de Gas, mostrando o impacto direto do Permit2 na melhoria da experiência do utilizador.

Além disso, com a implementação de código aberto do Permit2 em várias cadeias, um número crescente de carteiras e ferramentas DApp começaram a apoiá-lo. Ferramentas de segurança como Revoke.cash atualizaram seus serviços para permitir que os usuários visualizem e revoguem registros de autorização do Permit2. A Matcha também implementou o módulo de Transferência de Assinatura do Permit2, permitindo um mecanismo de "autorização única".

Apesar deste progresso, a adoção generalizada da Permit2 enfrenta desafios. Por um lado, os desenvolvedores precisam de tempo adicional para integração: em comparação com o uso direto da aprovação do ERC-20, a implementação do Permit2 requer lidar com a lógica de assinatura, aumentando a sobrecarga de desenvolvimento. Isto pode dissuadir equipas mais pequenas. Por outro lado, a educação do usuário é crucial: muitos DApps que usam o Permit2 precisam ensinar os usuários sobre o significado das assinaturas. Atualmente, as vantagens unificadas da Permit2 parecem superar esses pontos de atrito, mas a penetração total no mercado ainda levará tempo.

Comparando Permit2 com Novas Soluções: Chaves de Sessão e ERC-4337

Nos últimos 8 anos, os mecanismos de autorização ERC-20 evoluíram de múltiplas transações para assinaturas sem gás e agora para contas inteligentes. Cada avanço procurou otimizar o equilíbrio entre a experiência do usuário (reduzindo os requisitos de transação e assinatura) e os custos de gás. Aqui está uma comparação dessas tecnologias:

Para além do Permit2, duas soluções de autorização emergentes que valem a pena mencionar são as Chaves de Sessão e ERC-4337 Abstração de conta, cada um oferecendo abordagens distintas para o problema.

As chaves de sessão são particularmente exclusivas, pois não são um modelo de autorização estrito, mas sim um mecanismo de chave temporário no nível da carteira ou da conta. Em vez de modificar contratos de token, eles permitem que as carteiras gerem chaves privadas temporárias limitadas por tempo e quantidade restrita para operações específicas. Isso os torna ideais para compras de itens de jogos e micropagamentos únicos. Seu foco é reduzir os riscos de autorização única, projetados especificamente para interações temporárias do usuário, ao contrário da abordagem de modificação de contrato da Permit/Permit2.

O ERC-4337 adota uma abordagem diferente ao incorporar a lógica de autorização diretamente nas contas inteligentes, permitindo aos utilizadores personalizar as condições de autorização e potencialmente evitar etapas de aprovação tradicionais. Através de mecanismos flexíveis de UserOperation e Paymaster, alcança uma segurança aprimorada e uma experiência do utilizador mais satisfatória.

Ao observar as tendências futuras, essas diferentes soluções provavelmente coexistirão. A curto prazo, o Permit2 continuará a ser o padrão para DApps emergentes, melhorando a experiência do utilizador através de autorizações únicas, ao mesmo tempo que promove a educação em segurança e o suporte de ferramentas para reduzir os riscos de phishing. A médio prazo, à medida que o ERC-4337 e a abstração de contas se tornarem mais difundidos nos Layer 2s e mainnets, os utilizadores poderão libertar-se das limitações tradicionais de aprovação do ERC-20, gerindo autorizações de forma mais precisa e inteligente, potencialmente reduzindo a necessidade do Permit2.

A visão a longo prazo é criar uma experiência de autorização tão perfeita e intuitiva quanto a Web2, onde os usuários podem simplesmente clicar em um botão e todas as aprovações necessárias acontecem automaticamente em segundo plano, com avisos claros aparecendo apenas em situações de alto risco. Alcançar essa visão exigirá colaboração e inovação contínuas em protocolos, carteiras e dApps subjacentes. A Permit2 representa um passo importante nesta jornada de transição, mas ainda há um longo caminho a percorrer antes de chegar ao estado ideal. Ao longo do caminho, tanto a comunidade quanto os desenvolvedores devem manter uma abordagem pragmática, entendendo totalmente os pontos fortes e as limitações de cada solução e trabalhando juntos para construir um ambiente de autorização mais seguro e amigável.

No geral, o Permit2 oferece uma solução prática que pode ser implementada imediatamente, enquanto tecnologias como as Chaves de Sessão e o ERC-4337 apontam para melhorias mais fundamentais e a longo prazo na forma como a autorização é tratada.

Riscos de Segurança da Autorização Baseada em Assinatura

Tal como acontece com qualquer nova tecnologia, o Permit e o Permit2 introduzem não apenas novas eficiências, mas também novos riscos, especialmente em torno de ataques de autorização baseados em assinatura.

Em esquemas baseados em assinatura como Permit2 e EIP-2612 Permit, os designs de contrato principais incluem múltiplas camadas de proteção para se proteger contra o uso indevido e ataques de replay:

1. Proteção contra Repetição Baseada em Nonce

Permit2 mantém um contador nonce separado para cada tupla (proprietário, token, spender). Toda vez que um usuário assina uma nova autorização, o nonce correspondente é incrementado. Se um invasor tentar reutilizar uma assinatura antiga, ela falhará porque o contrato verifica se o nonce já foi usado.

2. Cumprimento do Prazo

Cada assinatura deve incluir um campo de prazo. Quando o contrato verifica a assinatura, garante que o tempo do bloco atual seja inferior ou igual ao prazo. Se a assinatura tiver expirado, mesmo que seja válida de outra forma, será rejeitada. Isso impede que autorizações de longa duração sejam exploradas posteriormente.

3. Controlo de Autorização Detalhado

As assinaturas Permit2 podem especificar um limite máximo. Antes de qualquer transferência de token ocorrer, o contrato verifica se o valor solicitado está dentro desse limite. O contrato não gasta automaticamente o montante total aprovado, permitindo que os utilizadores utilizem a sua franquia em partes e reduzindo o risco de uma exploração de esgotamento total.

4. Modos de Utilização Única e em Lote

Além das aprovações contínuas baseadas em licenças, a Permit2 também suporta assinaturas de uso único via SignatureTransfer. Estas assinaturas são válidas apenas para uma transação e tornam-se inválidas imediatamente após a execução. Isso é ideal para pagamentos únicos e evita que a assinatura seja reutilizada ou explorada posteriormente.

Estas proteções em camadas ajudam os esquemas de autorização do tipo Permit a melhorar a experiência do utilizador e poupar gás, ao mesmo tempo que minimizam riscos clássicos como "ataques de repetição", "sobreautorização" e "validade de assinatura indefinida".

No entanto, mesmo com proteções seguras ao nível do contrato, a engenharia social (especialmente phishing) continua a ser a ameaça mais difícil de defender. Na próxima secção, vamos analisar táticas comuns de phishing e como os atacantes enganam os utilizadores, levando-os a assinar aprovações maliciosas sem saber, que abusam do Permit2. Também daremos dicas sobre como se manter seguro.

Como acontecem os ataques de phishing por assinatura?

A pesca de assinaturas ocorre quando os atacantes enganam as vítimas para assinarem mensagens específicas para ganhar controle de seus ativos. Enquanto os ataques tradicionais podem envolver a execução de contratos ou transações maliciosas, na era do Permit, uma única autorização de assinatura maliciosa é suficiente para drenar fundos. Eis como esses ataques normalmente se desenrolam:

1. A vítima clica numa versão falsa de um site bem conhecido de DEX (site de phishing). Quando o utilizador tenta interagir, o site solicita uma assinatura de carteira, alegando ser para “confirmação de login” ou outros propósitos aparentemente legítimos. No entanto, este pedido é na realidade uma assinatura de autorização Permit2, concedendo ao contrato do atacante permissão ilimitada para retirar os USDC da vítima com um período de validade prolongado.
2. A vítima, carente de vigilância, assina o pedido diretamente. Neste ponto, nenhum gás é gasto e nenhuma atividade on-chain ocorre, não deixando rastros suspeitos.
3. Uma vez que o atacante obtém a assinatura, ele chama imediatamente a função permit() do contrato Permit2 para a submeter. Depois de o contrato Permit2 validar a assinatura, regista a autorização para o contrato do atacante sob o endereço da vítima (equivalente à vítima executar uma aprovação, mas concluída pelo atacante). Esta operação pode passar despercebida pela vítima, uma vez que a sua carteira não mostra despesas - apenas o mapeamento da autorização do token é atualizado na blockchain.
4. Posteriormente, o atacante inicia imediatamente uma transação transferFrom(vítima, endereço_do_atacante, quantidade) do seu endereço, transferindo com sucesso o USDC da vítima usando a recente autorização Permit2. A vítima só percebe o roubo quando já é tarde demais.

Nestes ataques, os utilizadores nunca executam quaisquer transações “de transferência” ou de “autorização” óbvias, no entanto, os seus ativos desaparecem misteriosamente. A chave está na própria assinatura tornar-se a autorização. Os atacantes disfarçam cuidadosamente os pedidos de assinatura para parecerem operações normais, baixando a guarda dos utilizadores. No entanto, uma vez assinado, é como entregar as chaves dos seus ativos.

Ainda pior, alguns atacantes utilizam métodos técnicos para aumentar a furtividade. Por exemplo, eles utilizam o mecanismo CREATE2 do Ethereum para gerar endereços de contrato maliciosos únicos para cada vítima. Isso torna as listas negras tradicionais ineficazes, uma vez que cada ataque usa um endereço diferente.

A maioria dos incidentes recentes de phishing de criptomoedas envolve autorização de assinatura. Por exemplo, Scam Sniffer’sestatísticasa partir do início de 2024, os dados mostram mais de 55 milhões de ativos roubados através de phishing de assinatura em apenas um mês. Desde a ativação do Permit2, os atacantes tornaram-se mais agressivos ao induzir os usuários a assinar autorizações do Permit/Permit2, levando a inúmeras vítimas num curto período. Claramente, quando a autorização de assinatura é abusada, pode ser devastadora e difícil de detetar.

Por que os riscos de phishing baseados em assinatura são mais altos do que os métodos tradicionais?

As autorizações maliciosas tradicionais requerem que os utilizadores executem uma transação on-chain, onde as carteiras geralmente exibem avisos claros como "Está a autorizar XXX a usar os seus tokens" e requerem taxas de gás. Os utilizadores experientes tendem a ser mais cautelosos em relação a estas situações. No entanto, os pedidos de assinatura nas interfaces das carteiras são frequentemente descritos apenas como "pedidos de assinatura de dados" em vez de ações financeiras, levando os utilizadores a baixar a guarda. Além disso, uma vez que as assinaturas não têm custos de gás, os atacantes podem lançar tentativas de phishing em grande escala sem se preocupar com despesas - eles lucram mesmo com apenas algumas tentativas bem-sucedidas.

Além disso, diferentes carteiras exibem mensagens EIP-712 de várias maneiras. Algumas carteiras modernas (como a mais recente MetaMask) analisar e exibir claramente os campos, mostrando mensagens como 'autorizar contrato para gastar X quantidade de seus tokens.' No entanto, muitas carteiras mostram apenas dados hexadecimais ou descrições simples, tornando difícil para os usuários comuns verificar a autenticidade. Os atacantes exploram isso ao incorporar descrições enganosas em mensagens (como fingir ser assinaturas de criação de NFT) para enganar os usuários a assinar.

Porque as autorizações de assinatura não afetam imediatamente os ativos, as vítimas podem não detetar imediatamente a ameaça. Os atacantes podem temporizar estrategicamente os seus ataques. Em vez de executarem imediatamente, podem esperar até que a carteira da vítima contenha mais ativos ou até um momento específico, o que complica os esforços de rastreamento. Com assinaturas que têm períodos de validade prolongados, os atacantes também podem explorar movimentos de preço para maximizar os seus ganhos, dando-lhes efetivamente uma opção de negociação gratuita. Este risco explica por que as assinaturas de permissão normalmente impõem prazos curtos.

A capacidade do Permit2 de autorizar vários tokens com uma única assinatura torna particularmente desafiador para os usuários entenderem completamente as implicações. Por exemplo, um site de phishing pode solicitar uma assinatura do Permit2 ao destacar permissões para apenas um ou dois tokens, mas secretamente incorporar autorizações extensas para tokens adicionais dentro da mesma assinatura. Os usuários podem facilmente ignorar essas permissões ocultas se suas carteiras não exibirem todos os detalhes claramente. Além disso, os atacantes muitas vezes usam nomes de contratos enganosos como “WalletGuard” em suas assinaturas, mascarando contratos maliciosos projetados para roubar permissões de tokens.

Como Podem os Utilizadores Proteger-se de Ataques de Assinatura?

Lembre-se de que assinar é equivalente a dar consentimento - nunca deixe a ausência de taxas de gás torná-lo descuidado. Quando a sua carteira solicitar uma assinatura, leia minuciosamente os detalhes da mensagem. Certifique-se de que o site ou DApp que solicita a assinatura é legítimo e que o conteúdo da mensagem está alinhado com as suas ações pretendidas. Por exemplo, se estiver apenas a fazer o login num site, a assinatura deve conter texto legível de login (como a maioria dos DApps usa), e não uma série de endereços e números de token.

Certifique-se de que o seu software de carteira suporta a exibição de dados EIP-712. Carteiras importantes como MetaMask,TrustWallet, eLedger Liveestão a melhorar a sua experiência de visualização de conteúdo de assinatura. Por exemplo, o MetaMask agora consegue analisar mensagens de permissão comuns em linguagem simples. Se a sua carteira apenas mostra dados hexadecimais longos ao assinar, considere mudar ou atualizar. Os utilizadores de carteiras de hardware também devem manter o firmware atualizado para suportar novos formatos, ou poderão não ver a informação corretamente no ecrã.

Quer esteja a utilizar assinaturas de Permissão ou Permissão2, geralmente pode ajustar os parâmetros de autorização. Não assine quantias ilimitadas (valor = 2^256-1) a menos que seja absolutamente necessário - em vez disso, autorize apenas a quantia necessária mais uma pequena reserva. Além disso, não defina prazos muito distantes no futuro. Desta forma, mesmo que a sua assinatura caia nas mãos erradas, as perdas potenciais são limitadas e a assinatura eventualmente expirará.

Desenvolva o hábito de verificar regularmente o status de autorização do seu endereço usando ferramentas como Revoke.cash, Etherscan Token Approval ou as funcionalidades incorporadas na sua carteira. Isso inclui aprovações tradicionais e permissões Permit2. Se identificar alguma autorização suspeita ou desnecessária, revogue-a imediatamente. Para o Permit2, esteja ciente de dois níveis de revogação: primeiro, a autorização principal (sua aprovação para o contrato Permit2 em si, que pode querer definir para 0 quando não estiver em uso); segundo, sub-autorizações (permissões do Permit2 para vários DApps, que geralmente expiram automaticamente, mas podem ser terminadas antecipadamente se tiverem longos períodos de validade). Se suspeitar que assinou um Permit suspeito, a ação mais segura é ajustar imediatamente o nonce: assine um novo permit para o mesmo gastador (mesmo com uma alocação de 0) para invalidar a antiga assinatura em posse do atacante.

Sempre seja cauteloso ao visitar websites desconhecidos ou ao baixar aplicações. Não clique em links desconhecidos, especialmente em "ofertas promocionais" ou "eventos de cunhagem" partilhados através de anúncios em redes sociais ou mensagens privadas. Muitas tentativas de phishing ocorrem através de contas oficiais falsas que publicam links de atividades fraudulentas, levando a pedidos de assinaturas. Faça o hábito de digitar diretamente os URLs oficiais do DApp ou utilizar marcadores para evitar cair em websites falsos.

Em conclusão, é crucial encontrar um equilíbrio entre conveniência e segurança. Embora as tecnologias de permissão sejam convenientes, os utilizadores devem permanecer vigilantes em relação à prevenção de riscos. À medida que o ecossistema amadurece, os produtos de carteira e os plugins de navegador estão a desenvolver proteção contra phishing de assinaturas, tais como avisos para assinaturas que envolvam grandes quantias. Pretendemos mitiGate.io tais ataques através de melhorias técnicas e educacionais no futuro.

Conclusão

Das limitações dos modelos tradicionais de autorização ERC-20 ao nascimento da Permissão e, em seguida, à inovadora Permissão 2 da Uniswap, testemunhamos os esforços do ecossistema Ethereum para melhorar a experiência e a segurança do usuário. O Permit2 simplifica significativamente o processo de autorização de token por meio de assinaturas off-chain, reduzindo os riscos de aprovações repetidas e permissões ilimitadas, ao mesmo tempo em que introduz recursos úteis, como mecanismos de expiração e operações em lote. No entanto, esses novos mecanismos vêm com novas responsabilidades — os usuários precisam melhorar sua consciência de segurança, enquanto carteiras e DApps devem trabalhar juntos para proteger os usuários contra ataques de assinatura. Olhando para o futuro, com novos desenvolvimentos tecnológicos, como a abstração de contas, espera-se que o gerenciamento de autorização de tokens se torne mais contínuo e seguro.