CZ: Los Exploradores de Bloques Deben Filtrar Transacciones Spam para Reducir el Riesgo de Envenenamiento de Direcciones
CZ: Los Exploradores de Bloques Deben Filtrar Transacciones Spam para Reducir el Riesgo de Envenenamiento de Direcciones
El envenenamiento de direcciones (también llamado envenenamiento del historial de transacciones) se ha convertido silenciosamente en una de las amenazas "a nivel de interfaz de usuario" más persistentes en Ethereum y otras redes EVM. Los atacantes no necesitan romper la criptografía ni explotar contratos inteligentes; explotan hábitos humanos, especialmente la tendencia a copiar una dirección del historial de transacciones recientes después de verificar solo los primeros y últimos caracteres. Para una explicación clara de cómo funcionan estas estafas en la práctica, consulta la explicación de Etherscan sobre ataques de envenenamiento de direcciones. (info.etherscan.com)
A principios de 2026, la escala de estas campañas es difícil de ignorar. Un estudio de Carnegie Mellon University CyLab (basado en datos en cadena de varios años) documentó cientos de millones de intentos de envenenamiento y enfatizó que la causa raíz es la usabilidad: direcciones hexadecimales largas, truncamiento en interfaces y comportamientos inseguros de copiar y pegar. (cylab.cmu.edu)
En este contexto, CZ ha reavivado recientemente la discusión en torno a una idea simple: dejar de mostrar transferencias obvias de spam en primer lugar. Si bien gran parte de la conversación pública se centra en las aplicaciones de billetera, el mismo principio de experiencia de usuario se aplica a los exploradores de bloques, ya que los exploradores son donde los usuarios, los equipos de soporte, los analistas e incluso las interfaces de las billeteras a menudo "leen" el historial de transacciones.
Por qué el envenenamiento de direcciones sigue funcionando
La mayoría de los ataques de envenenamiento de direcciones siguen un patrón repetible:
- Un estafador genera una dirección similar (a menudo coincidiendo con el principio y el final de una dirección de contraparte real).
- Envían una transferencia de polvo (valor diminuto, a veces incluso un evento de token que parece una transferencia) para que el historial de la víctima quede "contaminado".
- Más tarde, la víctima copia la dirección incorrecta del historial y envía un pago real al atacante.
Etherscan señala que estos ataques no se limitan a una sola interfaz; pueden aparecer en exploradores, billeteras y otras interfaces de Web3. (info.etherscan.com)
El argumento de CZ: filtrar spam es una solución de UX, no un cambio de protocolo
El argumento central de CZ es sencillo: si una interfaz puede identificar un patrón de envenenamiento (o una dirección de envenenamiento conocida), debería advertir o bloquear, y si una transacción es efectivamente spam sin valor, debería ocultarse por defecto para reducir la posibilidad de un error de copiar y pegar. Los informes que discuten sus comentarios resaltan dos direcciones prácticas:
- Detectar y bloquear destinos de envenenamiento conocidos (una "consulta de blockchain" más inteligencia de amenazas).
- No mostrar transacciones de spam de valor insignificante en las vistas del historial (financefeeds.com).
Aquí es donde los exploradores de bloques se convierten en parte de la solución: muchas billeteras y herramientas de cartera dependen de las API de los exploradores y de los feeds de actividad al estilo de los exploradores. Si los exploradores presentan transferencias de spam con el mismo peso visual que los pagos reales, amplifican involuntariamente la "huella de UI" del atacante.
Los exploradores de bloques han filtrado spam antes, esto no es nuevo
La industria ya ha experimentado con "controles de visibilidad" a nivel de explorador. Por ejemplo, BlockBeats informó anteriormente que Etherscan actualizó su vista predeterminada para no mostrar transferencias de tokens sin valor en respuesta a estafas de tipo envenenamiento, al tiempo que permite a los usuarios restablecer la visibilidad en la configuración. (theblockbeats.info)
Este es un precedente importante: filtrar a nivel de UI no cambia la verdad en la cadena. Cambia lo que se enfatiza, lo que se colapsa y lo que requiere un clic adicional, exactamente el tipo de fricción que puede prevenir errores costosos.
La parte difícil: filtrar sin dañar los casos de uso legítimos
Los críticos del filtrado agresivo a menudo plantean una preocupación válida: ¿qué pasa si las "transferencias pequeñas" son legítimas?
En 2025-2026, esta pregunta es más importante porque la industria tiende hacia:
- Tasas más bajas y mayor rendimiento en L2 y cadenas de alto rendimiento.
- Automatización en cadena (bots, guardianes, solucionadores de intenciones).
- Agentes de IA que pueden depender de micropagos o liquidación de alta frecuencia.
CZ reconoció una versión de este compromiso: si el futuro incluye microtransacciones de IA a IA, el filtrado generalizado basado solo en el valor podría ocultar actividad real; sin embargo, las mismas capacidades de IA también pueden usarse para clasificar el spam con mayor precisión cuando llegue ese futuro (es decir, detección más inteligente en lugar de umbrales simples).
Un punto medio razonable para los exploradores es:
- Ocultar por defecto "probablemente spam", no "de bajo valor".
- Proporcionar un conmutador de "Mostrar actividad oculta" con un solo clic.
- Ofrecer etiquetas explicables (por qué algo se ocultó: 0 valor, patrón de token falsificado, clúster de envenenamiento conocido, puntuación de alta similitud, etc.).
- Mantener una vista de registros / eventos sin procesar para usuarios avanzados y auditores.
Esto preserva la transparencia y al mismo tiempo protege a la mayoría de los usuarios del modo de falla más común: copiar la dirección incorrecta de un feed contaminado.
Qué deben hacer los exploradores y las billeteras (lista de verificación práctica)
1) Dejar de truncar direcciones por defecto en contextos de alto riesgo
Si una interfaz debe truncar, debería admitir tocar para expandir, resaltar diferencias y mostrar señales visuales estables (identiconos, etiquetas de nombre, etiquetas de contacto).
2) Añadir "advertencias de similitud" al enviar
El momento más seguro para intervenir es antes de firmar. Si el destino es muy similar a una dirección utilizada recientemente (pero no idéntica), la interfaz de usuario debería forzar una confirmación deliberada.
3) Tratar la visibilidad del spam como una configuración de seguridad
"Ocultar spam sospechoso" debe estar habilitado por defecto, con controles claros para revisar elementos ocultos.
4) Usar sumas de verificación siempre que sea posible
Para direcciones estilo Ethereum, la codificación de suma de verificación de mayúsculas y minúsculas mixtas EIP-55 ayuda a detectar errores tipográficos y reduce ciertas clases de errores de copia. Consulta la especificación ERC-55 (EIP-55). (eips-wg.github.io)
5) Mantener una libreta de direcciones local (y fomentar las listas blancas)
Una entrada de contacto guardada es más difícil de envenenar que "lo que sea que aparezca al final del historial".
Lo que los usuarios pueden hacer hoy para reducir el riesgo de envenenamiento de direcciones
Incluso si los exploradores y las billeteras mejoran el filtrado, los usuarios deben suponer que los intentos de envenenamiento continuarán, ya que enviar polvo es barato y los atacantes se automatizan a escala. Aquí hay hábitos que reducen significativamente el riesgo:
- Nunca copies una dirección de destinatario del historial de transacciones a menos que la verifiques por completo.
- Para transferencias grandes, envía primero una pequeña transacción de prueba.
- Prefiere fuentes de direcciones confiables (tu propia libreta de direcciones, contrapartes verificadas, códigos QR de un canal autenticado).
- Compara manualmente más allá de los primeros / últimos 4 caracteres, revisa también el segmento medio.
- Utiliza un flujo de trabajo de firma que te obligue a verificar la dirección completa en una pantalla de confianza.
Este último punto es donde una billetera de hardware cambia significativamente el perfil de riesgo.
Dónde encaja OneKey en este modelo de seguridad
El envenenamiento de direcciones es fundamentalmente un problema de engaño de interfaz de usuario, por lo que la defensa más sólida es separar "lo que ves en una pantalla potencialmente comprometida" de "lo que apruebas en una pantalla de confianza".
Un monedero de hardware como OneKey ayuda al mantener las claves privadas fuera de línea y requerir la confirmación de transacciones en el dispositivo, de modo que cuando tu navegador, dApp o historial de transacciones esté contaminado por transferencias de spam, aún tengas la oportunidad de verificar la dirección y el monto del destinatario en la pantalla del hardware antes de firmar.
Si interactúas frecuentemente con DeFi, envías stablecoins o administras billeteras operativas, combinar:
- filtrado de spam a nivel de explorador / billetera, y
- verificación basada en hardware en el dispositivo
es una de las formas más prácticas de reducir las pérdidas por envenenamiento de direcciones sin sacrificar los beneficios de autocustodia de las blockchains públicas.
Lectura adicional
- Etherscan: ¿Qué es un ataque de envenenamiento de direcciones?
- CMU CyLab: Estudio sobre el envenenamiento de direcciones de blockchain a escala (cylab.cmu.edu)
- Estándar de Ethereum: Direcciones con suma de verificación ERC-55 (EIP-55) (eips-wg.github.io)
