El cliente Prysm de Ethereum sufrió un incidente en la red principal, agotando recursos y provocando una gran falta de bloques y validaciones.

Según ChainCatcher, el equipo de Prysm publicó un informe de revisión sobre el incidente en la mainnet, indicando que durante el periodo Fusaka de Ethereum el 4 de diciembre, casi todos los nodos beacon de Prysm experimentaron agotamiento de recursos al procesar ciertas attestations, lo que provocó que no pudieran responder a tiempo a las solicitudes de los validadores, resultando en una gran cantidad de bloques y attestations perdidos.

El alcance del incidente fue desde el epoch 411439 hasta el 411480, abarcando un total de 42 epochs, con 248 bloques perdidos en 1344 slots, lo que representa una tasa de pérdida de aproximadamente el 18,5%. La tasa de participación de la red cayó temporalmente al 75%, y los validadores perdieron alrededor de 382 ETH en recompensas de attestations. La causa raíz fue que Prysm recibió attestations provenientes de nodos posiblemente desincronizados con la mainnet, los cuales referenciaban la raíz de bloque del epoch anterior.

Para verificar su legitimidad, Prysm reproducía repetidamente el estado de epochs antiguos y ejecutaba transiciones de epoch de alto costo, lo que provocó el agotamiento de recursos bajo alta concurrencia. El defecto está relacionado con el PR 15965 de Prysm, que ya había sido implementado en la testnet un mes antes, pero no se había presentado el mismo escenario.

La solución temporal oficial fue habilitar el parámetro --disable-last-epoch-target en la versión v7.0; las versiones posteriores v7.1 y v7.1.0 ya incluyen una solución a largo plazo, utilizando el estado head para verificar las attestations y evitando la reproducción repetida de estados históricos.

Prysm indicó que el problema comenzó a aliviarse gradualmente después de las 4:45 UTC del 4 de diciembre, y para el epoch 411480 la tasa de participación de la red se recuperó a más del 95%.

El equipo de Prysm señaló que este incidente resalta la importancia de la diversidad de clientes: si un solo cliente supera un tercio de la participación, podría causar la imposibilidad temporal de alcanzar finalización; si supera dos tercios, existe el riesgo de una cadena inválida finalizada. También reflexionaron sobre la falta de comunicación clara sobre las funciones y la incapacidad del entorno de pruebas para simular nodos desincronizados a gran escala, comprometiéndose a mejorar las estrategias de prueba y la gestión de configuraciones en el futuro.