La Fundación Ethereum recurre a la IA para detectar un fallo que podía dejar validadores fuera de servicio

La Fundación Ethereum ha puesto recientemente a trabajar a agentes de IA sobre el software que sostiene la red, con el objetivo de encontrar vulnerabilidades y seguir reforzando la mayor blockchain por valor bloqueado. La iniciativa permitió localizar fallos, aunque el equipo subraya que la revisión humana siguió siendo decisiva para separar incidencias reales de falsos positivos. El área de Protocol Security publicó además notas de campo con recomendaciones para que el ecosistema aplique buenas prácticas en sus propios flujos de trabajo con IA. Ethereum opera sobre miles de nodos —ordenadores que ejecutan el software de la red—, mantienen una copia de la cadena y se transmiten mensajes entre sí. Encima de esa capa se sitúan los validadores, los nodos que depositan ether en staking y votan qué bloques son válidos. Su funcionamiento depende de que los mensajes les lleguen de forma fiable. El error identificado se encontraba en gossipsub. La vulnerabilidad permitía que un sistema remoto provocara un "crash": el software del nodo entraba en un cálculo imposible, se detenía y se apagaba, dejando al validador fuera de línea hasta que un operador lo reiniciara. El problema se corrigió y divulgó con rapidez como "CVE202634219", atribuyendo el hallazgo al equipo. Más allá del parche, la Fundación destacó la dificultad de distinguir entre hallazgos auténticos y supuestos fallos presentados con gran seguridad por los agentes. "La sorpresa fue lo poco que se invirtió en encontrarlos y lo mucho que se invirtió en distinguir los fallos reales de los que solo lo parecían", escribió Nikos Baxevanis, autor de la publicación. Según explica, parte del reto está en el tipo de salida que generan estas herramientas. Un "fuzzer" —la técnica estándar que lanza datos malformados hasta que algo se rompe— devuelve un "crash" y el registro del punto exacto donde ocurre, algo que un ingeniero puede validar en minutos. Un agente, en cambio, entrega un relato construido: traza cómo se alcanzaría el fallo, argumenta su impacto, propone una severidad y aporta código funcional para demostrar el ataque. El problema es que ese texto llega con una prosa fluida que suena igual tanto si el fallo existe como si está inventado. La Fundación observó tres falsos positivos recurrentes. El primero: un "crash" que solo aparece en una compilación de prueba, donde el compilador activa controles de seguridad ausentes en la versión distribuida, de modo que los usuarios reales no se ven afectados. El segundo: un ataque que solo funciona si el valor peligroso se introduce manualmente en el programa, porque cualquier vía externa para entregarlo lo rechaza antes. El tercero: casos ligados a la verificación formal —demostrar matemáticamente que el código se comporta correctamente— en los que la prueba "pasa" por confirmar algo trivial, sin aportar información útil sobre el software. En la práctica, son pruebas que no prueban nada, y un agente puede redactar esa versión vacía con la misma rapidez y convicción que una válida. Otra limitación señalada es que los agentes razonan bien sobre un instante aislado, pero tienden a fallar al detectar vulnerabilidades que dependen de una secuencia de pasos, cada uno correcto por separado, donde el problema reside en el orden. Ese patrón encaja con muchos de los exploits que han drenado protocolos cripto este año: herramientas técnicas legítimas, utilizadas en cadena para producir un resultado malicioso. La Fundación citó ejemplos recientes. El exploit de Edel Finance a principios de mes eludió un feed de precios de Chainlink correcto mediante la capa de "wrapping" situada por encima. En el ataque de gobernanza de BONK, comprar tokens, votar y ejecutar una propuesta aprobada fueron transacciones ordinarias tomadas individualmente. Como respuesta, la Fundación plantea usar a los agentes para sugerir qué secuencias merece la pena someter a pruebas, y ejecutar esos tests de todos modos.