Un error de Ethereum casi provoca una crisis en la red después de la actualización de Fusaka

La actualización Fusaka de Ethereum se ejecutó perfectamente el 4 de diciembre de 2025, marcando un hito histórico ya que la red logró cero tiempo de inactividad mientras implementaba su expansión más significativa de disponibilidad de datos desde el EIP-4844.

Sin embargo, a las pocas horas de la activación, un error crítico en el cliente de consenso Prysm amenazó la estabilidad de la red, causando problemas de validación que ralentizaron la finalización de bloques antes de que las salvaguardas de diversidad de clientes evitaran una crisis potencial.

El incidente se desarrolló cuando los nodos Prysm experimentaron condiciones similares a la denegación de servicio desencadenadas por una generación excesiva de estados históricos.

El desarrollador principal de Prysm, Terence Tsao, explicó que "la generación de estados históricos consume mucha computación y memoria, y un nodo puede sufrir ataques DoS por un gran número de reproducciones de estado que ocurren en paralelo."

Durante dos horas, un aumento en las atestaciones obsoletas dirigidas a raíces de punto de control desde slots desactivados obligó a los nodos afectados a reconstruir estados históricos, empujando los sistemas a condiciones operativas comprometidas.

La Fundación Ethereum emitió rápidamente una guía de emergencia, mientras que otros diez clientes de consenso mantuvieron las operaciones de la red, evitando cualquier interrupción del servicio.

La diversidad de clientes demuestra su valor durante la crisis

Mientras los operadores de Prysm se apresuraban a implementar la bandera de solución de emergencia –disable-last-epoch-targets, los clientes alternativos, incluidos Lighthouse, Teku, Nimbus y Lodestar, continuaron validando bloques sin interrupción.

La red mantuvo el consenso durante todo el incidente, con la finalización continuando a pesar de que los validadores afectados experimentaban problemas de participación.

Lido Finance informó un impacto mínimo en comparación con otras soluciones de staking, atribuyendo su resiliencia a las operaciones de validador distribuidas donde Prysm alimenta aproximadamente el 15% de los operadores de nodos.

Las métricas del tercer trimestre de 2025 del protocolo demuestran un uso equilibrado de clientes como una estrategia deliberada para mitigar los riesgos de falla de un solo cliente.

La mayoría de las configuraciones de Prysm operadas por Lido se recuperaron en cuestión de horas después de aplicar los cambios de configuración recomendados o cambiar temporalmente a clientes alternativos.

El incidente reforzó los argumentos de larga data a favor de la diversidad de clientes como la principal defensa de Ethereum contra fallas de consenso.

El desarrollador Kydo captó la importancia, señalando que la actualización reforzó simultáneamente cuatro narrativas críticas:

• Operaciones sin tiempo de inactividad
• Capacidad de escalado de capa 2 a través de la activación de PeerDAS
• Protección de diversidad de clientes
• Potencial de generación de ingresos.

Ethereum alcanzó brevemente una tasa anual de $3.2 mil millones durante el incidente mientras los mecanismos de tarifas de blob se ajustaban a nuevos parámetros de precios.

PeerDAS y el escalado de Blob transforman la disponibilidad de datos

Más allá del incidente de Prysm, Fusaka entregó actualizaciones transformadoras a la capa de datos de Ethereum a través de la implementación de PeerDAS y el mecanismo de bifurcación Blob Parameter Only (BPO).

PeerDAS introdujo el muestreo de disponibilidad de datos, permitiendo a los nodos almacenar solo 1/8 de los datos de blob mientras mantienen garantías de seguridad.

Este cambio arquitectónico permite aumentos de rendimiento de hasta 8 veces la capacidad actual mientras mantiene los requisitos de hardware manejables para operadores independientes.

Vitalik Buterin enfatizó la importancia histórica de la actualización, afirmando: "PeerDAS en Fusaka es significativo porque literalmente es fragmentación."

Celebró el logro como un sueño que se remonta a 2015, señalando "Ethereum está llegando a un consenso sobre bloques sin requerir que ningún nodo vea más que una pequeña fracción de los datos."

La implementación representa un avance propuesto por primera vez en 2017, aunque Buterin reconoció los desafíos restantes, incluido el desarrollo de construcción de bloques distribuidos y mempool fragmentado.

El mecanismo BPO permite a Ethereum aumentar la capacidad de blob entre actualizaciones importantes en lugar de esperar bifurcaciones duras coordinadas.

Fusaka mantiene inicialmente el objetivo actual de 6 blobs, pero los ajustes programados elevarán los límites a 10/15 el 9 de diciembre de 2025 y a 14/21 el 7 de enero de 2026.

Esto aborda la creciente presión a medida que la demanda de capa 2 empujó la capacidad de blob de Ethereum hacia la saturación durante todo 2024.

EIP-7918 vincula las tarifas base de blob a los costos de ejecución, evitando el colapso del mercado. Las tarifas de blob aumentaron 1.500 veces inmediatamente después de la activación, subiendo de 1 wei a 1.500 wei.

El desarrollador Kydo explicó que este aumento "restaura un mercado de tarifas funcional para blobs, por lo que el protocolo puede usar realmente el precio para dirigir la demanda de blobs en lugar de estar atascado en 1 wei."

El cambio asegura que los operadores de capa 2 paguen costos significativos por los recursos computacionales que sus operaciones imponen a los nodos de la red.

Notablemente, Matt Hougan, CIO de Bitwise, también elogió el impulso, señalando: "Que Ethereum entregue dos actualizaciones importantes en un año es impresionante. El gigante está despierto y haciendo las cosas correctas."

Entre las principales L2, según la información compartida con Cryptonews, Optimism ha anunciado planes para adoptar las características de Fusaka en el OP Stack a principios de 2026, con Base, Soneium y otros equipos de capa 2 contribuyendo a las pruebas durante todo el desarrollo.