coindesk.com
Los desarrolladores de la Fundación Ethereum recientemente liberaron agentes de IA sobre el software en el que Ethereum funciona, con la esperanza de descubrir errores en un esfuerzo continuo por seguir fortaleciendo la mayor blockchain por valor bloqueado.
Y aunque se encontraron errores, todavía se requirió un juicio humano meticuloso para diferenciar entre lo que era real y lo que eran falsos positivos, con el equipo de Seguridad del Protocolo publicando notas de campo sobre consejos que el ecosistema en general debería seguir en sus propios flujos de trabajo de IA.
Ethereum funciona con miles de nodos, o computadoras ordinarias que ejecutan el software de la red, cada una manteniendo una copia de la cadena y enviando mensajes a sus vecinos.
Los validadores, los nodos que apuestan ether y votan sobre qué bloques son válidos, se sitúan sobre esa capa. Solo funcionan si los mensajes les llegan.
El fallo que estos ingenieros encontraron residía en gossipsub. La falla permitió que un sistema remoto provocara un fallo — en el cual el software del nodo realiza un cálculo imposible, se rinde y se apaga, desconectando a un validador hasta que un operador lo reinicie.
Esto se solucionó rápidamente y se divulgó como "CVE-2026-34219" con crédito al equipo. La preocupación más amplia, sin embargo, era diferenciar los verdaderos errores de los agentes de aquellos que se estaban haciendo pasar confiablemente por tales.
"La sorpresa fue lo poco que se dedicó a encontrarlos y lo mucho que se invirtió en diferenciar los errores reales de aquellos que solo parecían reales," escribió Nikos Baxevanis, autor del artículo.
La dificultad comenzó con lo que produce un agente. Un fuzzer, la herramienta estándar que lanza datos malformados al software hasta que algo falla, generó un bloqueo y un registro de dónde ocurrió, que un ingeniero puede confirmar en minutos.
Un agente, sin embargo, proporciona una narrativa creada. Rastrea cómo se podría alcanzar la vulnerabilidad, argumenta por qué es importante, propone una calificación de severidad y suministra código funcional que demuestra el ataque. Todo ello llega en una prosa fluida, que se lee igual tanto si el error es real como si es inventado.
Tres tipos de falsos positivos se repitieron con frecuencia, según la Fundación.
El primero fue un fallo que solo ocurre en una versión de prueba, donde el compilador activa verificaciones de seguridad que el software distribuido no incluye, por lo que nada se rompe para los usuarios reales.