Análisis del evento de actualización Fusaka de Ethereum: El informe posterior de Prysm revela la causa raíz del fallo

El equipo de desarrollo de Prysm publicó recientemente un informe de análisis posterior, que explica en detalle el evento anómalo en la red principal ocurrido tras la actualización Fusaka el 4 de diciembre de 2025. Este problema amenazó la estabilidad de la red de Ethereum en su momento, pero finalmente fue mitigado gracias a la diversidad de clientes.

El informe indica que el problema ocurrió en el epoch 411,392 tras la activación de la actualización Fusaka (a las 21:49 UTC del 4 de diciembre). El cliente de consenso Prysm, al procesar ciertos datos de prueba, activó una repetición masiva de cálculos de estados históricos, lo que llevó a un rápido agotamiento de los recursos de CPU y memoria, provocando una degradación del rendimiento tipo denegación de servicio (DoS) en los nodos. Esto no fue un fallo en el diseño del protocolo, sino un problema de implementación en el cliente bajo condiciones límite específicas.

Los nodos validados de Prysm afectados representan aproximadamente entre el 15% y el 22.71% de toda la red. Durante el evento, la participación general de los validadores cayó repentinamente del más del 95% habitual a aproximadamente el 75%, y la red perdió la finalidad en 41 epochs consecutivos, lo que resultó en una pérdida de aproximadamente 382 ETH en recompensas de prueba y estuvo cerca de perder la finalización. Terence Tsao, desarrollador principal de Prysm, señaló que la cantidad de cálculo para la reproducción del estado histórico es muy grande y que, cuando se activa en paralelo mediante múltiples hilos, puede ralentizar significativamente el rendimiento del nodo.

Es importante destacar que la actualización Fusaka en sí fue exitosa. Esta actualización introdujo la tecnología PeerDAS (muestreo de disponibilidad de datos entre pares), cuyo objetivo era aumentar la capacidad de blobs en Layer 2 a ocho veces la original. El proceso de actualización no causó interrupciones ni bifurcaciones en el consenso.

La razón por la que la red de Ethereum evitó consecuencias más graves radica en la diversidad de clientes. Además de Prysm, otros diez clientes de consenso como Lighthouse, Teku y Nimbus mantuvieron la producción de bloques en todo momento, permitiendo que aproximadamente entre el 75% y el 85% de los validadores permanecieran en línea, asegurando que la finalización de la red no fuera comprometida. Si un problema similar ocurriera en clientes con mayor participación, las consecuencias podrían ser aún más severas, incluyendo la suspensión de la agregación en Layer 2 y obstáculos en los retiros de los validadores.

Tras el evento, la Fundación Ethereum publicó rápidamente directrices de emergencia, y el equipo de Prysm implementó primero una solución temporal en tiempo de ejecución, además de lanzar una solución permanente en las versiones v7.0.1 y v7.1.0. Para el 5 de diciembre, la participación en la red se había recuperado casi al 99%, y la red principal de Ethereum volvió a funcionar normalmente en 24 horas.