¿Qué rompió la actualización Fusaka de Ethereum? La autopsia de Prysm revela la causa

Los desarrolladores de Prysm lanzaron un análisis post-mortem que explica el incidente en la cadena principal Fusaka del 4 de diciembre, que amenazó la estabilidad de la red Ethereum.
Resumen

• Un bug en Prysm tras Fusaka provocó 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 finalización gracias a la diversidad de clientes y correcciones rápidas.

El cliente de consenso sufrió un agotamiento de recursos debido a la costosa recomputación del estado al procesar attestaciones específicas, causando graves problemas operativos a los validadores.

El bug 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 ya que la participación de validadores se desplomó al 75%, resultando en aproximadamente 382 ETH en recompensas de prueba perdidas. Los desarrolladores de Prysm desplegaron banderas de ejecución de emergencia antes de implementar soluciones permanentes en las versiones v7.0.1 y v7.1.0.

El agotamiento de recursos empujó a 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 es muy pesado en memoria de cómputo, un nodo puede ser Dosed por un gran número de replays de estado que ocurren en paralelo.”

Los validadores que ejecutan Prysm, que representaban aproximadamente entre el 15% y el 22,71% de los validadores de la red, enfrentaron una degradación severa del rendimiento. La caída en participación, del nivel normal por encima del 95% al 75%, llevó a Ethereum peligrosamente cerca de perder la finalidad.

Si el bug 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 podría haber congelado las operaciones de Rollups de capa 2 y bloqueado los retiros de validadores hasta que los desarrolladores resolvieran el problema.

La actualización Fusaka introdujo en sí misma la tecnología PeerDAS (Muestreo de Disponibilidad de Datos Peer), diseñada para aumentar la capacidad de blob ocho veces para la escalabilidad de Capa 2.

La actualización se ejecutó con éxito sin tiempo de inactividad antes de que surgiera el bug en 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, incluidos Lighthouse, Nimbus y Teku, continuaron validando bloques sin interrupciones.

La estructura descentralizada de clientes significaba que aproximadamente entre el 75% y el 85% de los validadores mantenían operaciones normales durante toda la crisis. Esto evitó la pérdida de finalidad y permitió que la red siguiera 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 operaciones normales en 24 horas tras el incidente.