CZ: Os Block Explorers Devem Filtrar Transações de Spam para Reduzir o Risco de Envenenamento de Endereços

14 de mar. de 2026

CZ: Os Block Explorers Devem Filtrar Transações de Spam para Reduzir o Risco de Envenenamento de Endereços

O envenenamento de endereços (também chamado de envenenamento do histórico de transações) tornou-se silenciosamente uma das ameaças mais persistentes na "camada de UI" em redes Ethereum e outras redes EVM. Os atacantes não precisam quebrar criptografia ou explorar contratos inteligentes; eles exploram hábitos humanos – especialmente a tendência de copiar um endereço do histórico de transações recentes após verificar apenas os primeiros e últimos caracteres. Para uma explicação clara de como esses golpes funcionam na prática, veja o explicador da Etherscan sobre ataques de envenenamento de endereços. (info.etherscan.com)

No início de 2026, a escala dessas campanhas é difícil de ignorar. Um estudo da Carnegie Mellon University CyLab (baseado em dados on-chain de vários anos) documentou centenas de milhões de tentativas de envenenamento e enfatizou que a causa raiz é a usabilidade: endereços hexadecimais longos, truncamento em interfaces e comportamentos inseguros de copiar e colar. (cylab.cmu.edu)

Neste contexto, CZ reacendeu recentemente a discussão em torno de uma ideia simples: parar de exibir transferências de spam óbvias em primeiro lugar. Embora grande parte da conversa pública se concentre em aplicativos de carteira, o mesmo princípio de UX se aplica a block explorers – porque os explorers são onde os usuários, equipes de suporte, analistas e até mesmo UIs de carteira frequentemente "leem" o histórico de transações.

Por que o envenenamento de endereços continua funcionando

A maioria dos ataques de envenenamento de endereços segue um padrão repetível:

Um golpista gera um endereço semelhante (geralmente correspondendo ao início e ao fim de um endereço de contraparte real).
Eles enviam uma transferência de poeira (valor minúsculo, às vezes até um evento de token que parece uma transferência) para que o histórico da vítima fique "poluído".
Mais tarde, a vítima copia o endereço errado do histórico e envia um pagamento real para o atacante.

A Etherscan observa que esses ataques não se limitam a uma única interface; eles podem aparecer em explorers, carteiras e outros front-ends Web3. (info.etherscan.com)

O ponto de CZ: filtrar spam é uma correção de UX, não uma mudança de protocolo

O argumento principal de CZ é direto: se uma interface pode identificar um padrão de envenenamento (ou um endereço de veneno conhecido), ela deve avisar ou bloquear – e se uma transação for spam efetivamente sem valor, ela deve ser ocultada por padrão para reduzir a chance de um erro de copiar e colar. Relatórios discutindo seus comentários destacam duas direções práticas:

Detectar e bloquear destinos de veneno conhecidos (uma "consulta de blockchain" mais inteligência de ameaças)
Não exibir transações de spam de valor insignificante em visualizações de histórico (financefeeds.com)

É aqui que os block explorers se tornam parte da solução: muitas carteiras e ferramentas de portfólio dependem de APIs de explorer e feeds de atividade no estilo explorer. Se os explorers apresentarem transferências de spam com o mesmo peso visual que os pagamentos reais, eles amplificam involuntariamente a "pegada de UI" do atacante.

Block Explorers já filtraram spam antes – isso não é novidade

A indústria já experimentou "controles de visibilidade" na camada do explorer. Por exemplo, o BlockBeats relatou anteriormente que a Etherscan atualizou sua visualização padrão para não exibir transferências de tokens sem valor em resposta a golpes do tipo envenenamento, permitindo que os usuários reabilitem a visibilidade nas configurações. (theblockbeats.info)

Este é um precedente importante: filtrar na camada de UI não altera a verdade on-chain. Muda o que é enfatizado, o que é colapsado e o que requer um clique extra – exatamente o tipo de atrito que pode prevenir erros caros.

A parte difícil: filtrar sem prejudicar casos de uso legítimos

Críticos da filtragem agressiva muitas vezes levantam uma preocupação válida: e se "pequenas transferências" forem legítimas?

Em 2025-2026, essa questão importa mais porque a indústria está caminhando para:

Taxas mais baixas e maior throughput em L2s e cadeias de alto desempenho
Automação on-chain (bots, keepers, resolvedores de intenção)
Agentes de IA que podem depender de micro-pagamentos ou liquidação de alta frequência

CZ reconheceu uma versão dessa troca: se o futuro inclui microtransações de IA para IA, a filtragem indiscriminada baseada apenas no valor pode ocultar atividade real – no entanto, as mesmas capacidades de IA também podem ser usadas para classificar spam com mais precisão quando esse futuro chegar (ou seja, detecção mais inteligente em vez de limites simples).

Um meio-termo razoável para os explorers é:

Ocultar por padrão "provavelmente spam", não "baixo valor"
Fornecer um alternador de "Mostrar atividade oculta" com um clique
Oferecer rótulos explicáveis (por que algo foi ocultado: valor 0, padrão de token falsificado, cluster de envenenamento conhecido, alta pontuação de similaridade, etc.)
Manter uma visualização de logs / eventos brutos para usuários avançados e auditores

Isso preserva a transparência enquanto protege a maioria dos usuários do modo de falha mais comum: copiar o endereço errado de um feed poluído.

O que explorers e carteiras devem fazer (checklist prático)

1) Pare de truncar endereços por padrão em contextos de alto risco

Se uma interface precisar truncar, ela deve suportar tocar para expandir, destacar diferenças e mostrar sinais visuais estáveis (identicons, tags de nome, rótulos de contato).

2) Adicione "avisos de similaridade" ao enviar

O momento mais seguro para intervir é antes de assinar. Se o destino for muito semelhante a um endereço usado recentemente (mas não idêntico), a UI deve forçar uma confirmação deliberada.

3) Trate a visibilidade do spam como uma configuração de segurança

"Ocultar spam suspeito" deve ser habilitado por padrão, com controles claros para revisar itens ocultos.

4) Use checksums sempre que possível

Para endereços no estilo Ethereum, a codificação checksum EIP-55 de caixa mista ajuda a detectar erros de digitação e reduz certas classes de erros de cópia. Veja a especificação ERC-55 (EIP-55). (eips-wg.github.io)

5) Mantenha uma agenda de endereços local (e incentive allowlists)

Uma entrada de contato salva é mais difícil de envenenar do que "o que quer que apareça por último no histórico".

O que os usuários podem fazer hoje para reduzir o risco de envenenamento de endereços

Mesmo que os explorers e carteiras melhorem a filtragem, os usuários devem assumir que as tentativas de envenenamento continuarão – porque enviar poeira é barato e os atacantes automatizam em escala. Aqui estão hábitos que reduzem significativamente o risco:

Nunca copie um endereço de destinatário do histórico de transações a menos que você o verifique completamente.
Para transferências grandes, envie uma pequena transação de teste primeiro.
Prefira fontes de endereço confiáveis (sua própria agenda, contrapartes verificadas, códigos QR de um canal autenticado).
Compare manualmente mais do que os primeiros/últimos 4 caracteres – verifique o segmento do meio também.
Use um fluxo de assinatura que o force a verificar o endereço completo em uma tela confiável.

Este último ponto é onde uma carteira de hardware muda significativamente o perfil de risco.

Onde a OneKey se encaixa neste modelo de segurança

O envenenamento de endereços é fundamentalmente um problema de engano de UI, portanto, a defesa mais robusta é separar "o que você vê em uma tela potencialmente comprometida" de "o que você aprova em uma tela confiável".

Uma carteira de hardware como a OneKey ajuda mantendo as chaves privadas offline e exigindo a confirmação de transações no dispositivo – assim, quando seu navegador, dApp ou histórico de transações for poluído por transferências de spam, você ainda terá a oportunidade de verificar o endereço do destinatário e o valor na tela do hardware antes de assinar.

Se você interage frequentemente com DeFi, envia stablecoins ou gerencia carteiras operacionais, a combinação de:

Filtragem de spam em nível de explorer/carteira, e
Verificação on-device baseada em hardware

é uma das maneiras mais práticas de reduzir as perdas por envenenamento de endereços sem sacrificar os benefícios de autocustódia das blockchains públicas.