La sorprendente caída en el uso de Ethereum sugiere que la red resolvió el problema equivocado con la actualización Fusaka

Fuente: CryptoNewsNet Título original: La sorprendente caída en el uso de Ethereum sugiere que la red resolvió el problema equivocado con la actualización Fusaka Enlace original: Ethereum activó la actualización Fusaka el 3 de diciembre de 2025, aumentando la capacidad de disponibilidad de datos de la red mediante Overrides de Parámetros de Blob que expandieron incrementalmente los objetivos y máximos de blob.

Dos ajustes posteriores elevaron el objetivo de 6 blobs por bloque a 10, luego a 14, con un techo máximo de 21. El objetivo era reducir los costos de los rollups de capa 2 aumentando el rendimiento para los datos de blob, los paquetes de transacciones comprimidas que los rollups publican en Ethereum para seguridad y finalización.

Tres meses después de la recopilación de datos, los resultados revelan una brecha entre capacidad y utilización. Un análisis de MigaLabs de más de 750,000 slots desde la activación de Fusaka muestra que la red no alcanza el objetivo de 14 blobs.

El uso mediano de blobs en realidad disminuyó después del primer ajuste de parámetros, y los bloques que contienen 16 o más blobs muestran tasas de fallo elevadas, lo que sugiere una degradación en la fiabilidad en los límites de la nueva capacidad.

La conclusión del informe es clara: no se realizarán más aumentos en el parámetro de blob hasta que las altas tasas de fallo de blobs se normalicen y la demanda materialice el espacio adicional ya creado.

Qué cambió Fusaka y cuándo ocurrió

La línea base previa a Fusaka en Ethereum, establecida mediante EIP-7691, fijaba el objetivo en 6 blobs por bloque con un máximo de 9. La actualización Fusaka introdujo dos ajustes secuenciales en los Parámetros de Blob.

El primero se activó el 9 de diciembre, elevando el objetivo a 10 y el máximo a 15. El segundo se activó el 7 de enero de 2026, llevando el objetivo a 14 y el máximo a 21.

Estos cambios no requirieron bifurcaciones duras, y el mecanismo permite a Ethereum ajustar la capacidad mediante coordinación de clientes en lugar de actualizaciones a nivel de protocolo.

El análisis de MigaLabs, que publicó código reproducible y metodología, rastreó el uso de blobs y el rendimiento de la red durante esta transición.

Encontró que la cantidad mediana de blobs por bloque cayó de 6 antes del primer override a 4 después, a pesar de la expansión de capacidad de la red. Los bloques con 16 o más blobs siguen siendo extremadamente raros, ocurriendo entre 165 y 259 veces en toda la ventana de observación, dependiendo del conteo específico de blobs.

La red tiene margen sin usar.

Una discrepancia en los parámetros: el texto de la línea de tiempo del informe describe que el primer override elevó el objetivo de 6 a 12, pero el anuncio de la mainnet de la Fundación Ethereum y la documentación del cliente describen el ajuste como de 6 a 10.

Usamos los parámetros de la Fundación Ethereum como fuente: línea base 6/9, después del primer override 10/15, después del segundo 14/21. Sin embargo, tratamos el conjunto de datos del informe para patrones de utilización observada y tasas de fallo como la base empírica.

Las tasas de fallo aumentan en blobs altos

La fiabilidad de la red, medida a través de slots fallidos, que son bloques que no se propagan o atestiguan correctamente, muestra un patrón claro.

A menores conteos de blobs, la tasa de fallo base ronda el 0.5%. Cuando los bloques alcanzan 16 o más blobs, las tasas de fallo suben a 0.77% a 1.79%. En 21 blobs, la capacidad máxima introducida en el segundo override, la tasa de fallo alcanza 1.79%, más del triple de la base.

El análisis desglosa esto en conteos de blobs de 10 a 21, mostrando una curva de degradación gradual que se acelera más allá del objetivo de 14 blobs.

Esta degradación importa porque sugiere que la infraestructura de la red, como hardware de validadores, ancho de banda de red y tiempos de atestación, tiene dificultades para manejar bloques en el extremo superior de la capacidad.

Si la demanda eventualmente aumenta para llenar el objetivo de 14 blobs o empujar hacia el máximo de 21 blobs, las tasas de fallo elevadas podrían traducirse en retrasos significativos en la finalización o en riesgos de reorganización. El informe enmarca esto como un límite de estabilidad: la red puede procesar técnicamente bloques de alto blob, pero hacerlo de manera consistente y fiable sigue siendo una cuestión abierta.

Economía de blobs: por qué importa el piso del precio de reserva

Fusaka no solo expandió la capacidad. También cambió la fijación de precios de blobs mediante EIP-7918, que introduce un piso de precio de reserva para evitar que las subastas de blobs colapsen a 1 wei.

Antes de este cambio, cuando los costos de ejecución dominaban y la demanda de blobs permanecía baja, la tarifa base de blobs podía caer en espiral hasta desaparecer como señal de precio efectiva. Los rollups de capa 2 pagan tarifas de blobs para publicar sus datos de transacción en Ethereum, y esas tarifas deben reflejar los costos computacionales y de red que imponen los blobs.

Cuando las tarifas caen cerca de cero, el ciclo de retroalimentación económica se rompe, y los rollups consumen capacidad sin pagar en proporción. Esto hace que la red pierda visibilidad sobre la demanda real.

El piso de precio de reserva de EIP-7918 vincula las tarifas de blobs a los costos de ejecución, asegurando que incluso cuando la demanda sea débil, el precio siga siendo una señal significativa.

Esto previene el problema del free-rider, donde blobs baratos fomentan un uso desperdiciado, y proporciona datos más claros para decisiones futuras de capacidad: si las tarifas de blobs permanecen elevadas a pesar del aumento de capacidad, la demanda es genuina; si colapsan al piso, existe margen adicional.

Datos tempranos del panel de control Dune de Hildobby, que rastrea los blobs de Ethereum, muestran que las tarifas de blobs se han estabilizado tras Fusaka en lugar de continuar la espiral descendente vista en períodos anteriores.

El conteo promedio de blobs por bloque confirma el hallazgo de MigaLabs de que la utilización no ha aumentado para llenar la nueva capacidad. Los bloques rutinariamente contienen menos de los 14 blobs objetivo, y la distribución sigue siendo muy sesgada hacia conteos menores.

Lo que revelan los datos sobre la efectividad

Fusaka logró ampliar la capacidad técnica y demostrar que el mecanismo de Overrides de Parámetros de Blob funciona sin requerir bifurcaciones duras controvertidas.

El piso de precio de reserva parece estar funcionando como se esperaba, evitando que las tarifas de blobs se vuelvan económicamente insignificantes. Pero la utilización se queda atrás de la capacidad, y la fiabilidad en los límites de la nueva capacidad muestra una degradación medible.

La curva de tasas de fallo sugiere que la infraestructura actual de Ethereum maneja cómodamente la línea base previa a Fusaka y los parámetros 10/15 del primer override, pero comienza a tensarse más allá de 16 blobs.

Esto crea un perfil de riesgo: si la actividad de capa 2 aumenta y empuja los bloques regularmente hacia el máximo de 21 blobs, la red podría enfrentar tasas de fallo elevadas que comprometan la finalización y la resistencia a reorganizaciones.

Los patrones de demanda ofrecen otra señal. La caída en el uso mediano de blobs tras el primer override, a pesar del aumento de capacidad, sugiere que los rollups de capa 2 no están actualmente limitados por la disponibilidad de blobs.

O bien sus volúmenes de transacción no han crecido lo suficiente para requerir más blobs por bloque, o están optimizando la compresión y el agrupamiento para ajustarse a la capacidad existente en lugar de expandir el uso.

Blobscan, un explorador dedicado a blobs, muestra que los rollups individuales publican conteos de blobs relativamente consistentes en el tiempo en lugar de aumentar para aprovechar el nuevo margen.

La preocupación previa a Fusaka era que la capacidad limitada de blobs sería un cuello de botella para la escalabilidad de Layer 2 y mantendría elevadas las tarifas de rollup mientras las redes compiten por la escasa disponibilidad de datos. Fusaka abordó la restricción de capacidad, pero el cuello de botella parece haberse desplazado.

Los rollups no están llenando el espacio disponible, lo que significa que o la demanda aún no ha llegado, o factores como la economía del secuenciador, la actividad del usuario y la fragmentación entre rollups están limitando el crecimiento más que la disponibilidad de blobs.

Qué sigue

La hoja de ruta de Ethereum incluye PeerDAS, un rediseño más fundamental del muestreo de disponibilidad de datos que ampliaría aún más la capacidad de blobs, mejorando la descentralización y las propiedades de seguridad.

Sin embargo, los resultados de Fusaka sugieren que la capacidad bruta no es la restricción principal en este momento.

La red tiene margen para crecer hasta los parámetros 14/21 antes de necesitar otra expansión, y la curva de fiabilidad en blobs altos indica que las actualizaciones de infraestructura podrían necesitar ponerse al día antes de que aumente nuevamente la capacidad.

Los datos de tasas de fallo proporcionan una condición límite clara. Si Ethereum impulsa la capacidad más allá y los bloques con 16+ blobs aún muestran tasas elevadas de fallo, corre el riesgo de introducir inestabilidad sistémica que podría manifestarse en períodos de alta demanda.

El camino más seguro es dejar que la utilización aumente hacia el objetivo actual, monitorear si las tasas de fallo mejoran a medida que los clientes optimizan para cargas mayores de blobs, y ajustar los parámetros solo cuando la red demuestre que puede manejar de manera confiable los casos límite.

La efectividad de Fusaka depende de la métrica. Expandió la capacidad con éxito y estabilizó el precio de blobs mediante el piso de reserva. No impulsó aumentos inmediatos en la utilización ni resolvió los desafíos de fiabilidad en capacidad máxima.

La actualización creó margen para un crecimiento futuro, pero si ese crecimiento se materializa o no, sigue siendo una pregunta abierta que los datos aún no han respondido.