¿Qué rompió la actualización Fusaka de Ethereum? El análisis post-mortem de Prysm revela la causa
Los desarrolladores de Prysm publicaron un análisis post-mortem explicando el incidente del 4 de diciembre en la mainnet de Fusaka que amenazó la estabilidad de la red Ethereum.
- Un error de Prysm después de Fusaka causó que la participación de validadores cayera al 75%.
- La red perdió 41 épocas y aproximadamente 382 ETH en recompensas de prueba.
- Ethereum evitó la pérdida de finalidad gracias a la diversidad de clientes y correcciones rápidas.
El cliente de consenso sufrió agotamiento de recursos debido a la costosa recomputación de estados al procesar atestaciones específicas, causando que los validadores enfrentaran graves problemas operativos.
El error apareció inmediatamente después de que Fusaka se activara en la época 411392 el 4 de diciembre de 2025, a las 21:49 UTC.
La red perdió 41 épocas mientras la participación de validadores se desplomaba al 75%, resultando en aproximadamente 382 Ethereum (ETH) en recompensas de prueba perdidas. Los desarrolladores de Prysm implementaron flags de ejecución de emergencia antes de implementar correcciones permanentes en las versiones v7.0.1 y v7.1.0.
El agotamiento de recursos empujó la red hacia la pérdida de finalidad
La falla técnica se centró en estados históricos obsoletos que crearon condiciones de denegación de servicio en los nodos afectados.
El desarrollador principal de Prysm, Terence Tsao, explicó que "el estado histórico consume mucha memoria de cómputo, un nodo puede sufrir ataques DoS por un gran número de reproducciones de estado ocurriendo en paralelo."
Los validadores que ejecutaban Prysm, que representaban aproximadamente del 15% al 22,71% de los validadores de la red, enfrentaron una degradación paralizante del rendimiento. La caída de participación de niveles normales por encima del 95% al 75% empujó a Ethereum peligrosamente cerca de perder la finalidad.
Si el error hubiera afectado a un cliente de consenso diferente como Lighthouse en lugar de Prysm, la red podría haber perdido la finalidad por completo.
Tal evento potencialmente congelaría las operaciones de rollup de Capa 2 y bloquearía los retiros de validadores hasta que los desarrolladores resolvieran el problema.
La actualización Fusaka en sí introdujo la tecnología PeerDAS (Muestreo de Disponibilidad de Datos entre Pares) diseñada para aumentar la capacidad de blob ocho veces para el escalado de Capa 2.
La actualización se ejecutó con éxito sin tiempo de inactividad antes de que apareciera el error de Prysm.
Diez clientes de consenso evitaron el colapso de la red Ethereum
La arquitectura de diversidad de clientes de Ethereum evitó un fallo catastrófico. Mientras los validadores de Prysm luchaban, otros diez clientes de consenso incluyendo Lighthouse, Nimbus y Teku continuaron validando bloques sin interrupción.
La estructura de cliente descentralizada significó que aproximadamente del 75% al 85% de los validadores mantuvieron operaciones normales durante toda la crisis. Esto evitó la pérdida de finalidad y mantuvo a la red procesando transacciones a pesar del estado degradado de Prysm.
La Fundación Ethereum emitió rápidamente una guía de emergencia para los operadores de Prysm. Los validadores aplicaron la solución temporal mientras los desarrolladores de Prysm construían soluciones permanentes.
Para el 5 de diciembre, la participación en la red se recuperó a casi el 99%, restaurando las operaciones normales dentro de las 24 horas del incidente.
También te puede interesar
La otra cara de la fe; protectora animal explica por qué cientos de "perritos peregrinos" son abandonados
El precio de XRP mantiene soporte clave mientras la zona de liquidez de $3 gana atención
