Ethereum activó la actualización de Fusaka el 3 de diciembre de 2025, aumentando la capacidad de disponibilidad de datos de la red a través de Anulaciones de Parámetros de Blob que expandieron incrementalmente los objetivos y máximos de los blobs.
Dos ajustes posteriores elevaron el objetivo de 6 blobs por bloque a 10, luego a 14, con un límite máximo de 21. El objetivo era reducir los costos de acumulación de capa 2 aumentando el rendimiento de los datos de blob, los paquetes de transacciones comprimidos que los paquetes acumulativos se publican en Ethereum por motivos de seguridad y finalidad.
Tres meses después de la recopilación de datos, los resultados revelan una brecha entre la capacidad y la utilización. Un análisis de MigaLabs de más de 750.000 espacios desde la activación de Fusaka muestra que la red no está alcanzando el recuento objetivo de 14 blobs.
El uso medio de blobs en realidad disminuyó después del primer ajuste de parámetros, y los bloques que contienen 16 o más blobs exhiben tasas de error elevadas, lo que sugiere una degradación de la confiabilidad en los límites de la nueva capacidad.
La conclusión del informe es directa: no habrá más aumentos en el parámetro blob hasta que se normalicen las altas tasas de errores de blobs y se materialice la demanda para el margen ya creado.
Qué cambió Fusaka y cuándo sucedió
La línea de base anterior a Fusaka de Ethereum, establecida a través de EIP-7691, establecía el objetivo en 6 blobs por bloque con un máximo de 9. La actualización de Fusaka introdujo dos ajustes secuenciales de anulación de 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, elevando el objetivo a 14 y el máximo a 21.
Estos cambios no requirieron bifurcaciones duras y el mecanismo permite a Ethereum marcar capacidad a través de la coordinación del cliente en lugar de actualizaciones a nivel de protocolo.
El análisis de MigaLabs, que publicó código y metodología reproducibles, realizó un seguimiento del uso de blobs y del rendimiento de la red durante esta transición.
Descubrió que el recuento medio de blobs por bloque cayó de 6 antes de la primera anulación a 4 después, a pesar de que la capacidad de la red se expandió. Los bloques que contienen 16 o más manchas siguen siendo extremadamente raros y ocurren entre 165 y 259 veces cada uno en la ventana de observación, dependiendo del recuento de manchas específico.
La red tiene un margen de maniobra que no está utilizando.
Una discrepancia de parámetro: el texto de la línea de tiempo del informe describe la primera anulación como un aumento del objetivo de 6 a 12, pero el anuncio de la red principal 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 de base del 9/6, 15/10 después de la primera anulación, 21/14 después de la segunda. Sin embargo, tratamos el conjunto de datos del informe sobre patrones de utilización observados y tasas de error como la columna vertebral empírica.
Las tasas de fallos aumentan cuando el número de blobs es elevado
La confiabilidad de la red medida a través de ranuras perdidas, que son bloques que no se propagan o no certifican correctamente, muestra un patrón claro.
En recuentos de blobs más bajos, la tasa de fallos de referencia se sitúa en torno al 0,5%. Una vez que los bloques alcanzan 16 o más blobs, las tasas de fallas aumentan del 0,77% al 1,79%. Con 21 blobs, la capacidad máxima introducida en la segunda anulación, la tasa de fallos alcanza el 1,79%, más del triple del valor inicial.
El análisis desglosa esto en recuentos de blobs de 10 a 21, lo que muestra una curva de degradación gradual que se acelera más allá del objetivo de 14 blobs.
Esta degradación es importante porque sugiere que la infraestructura de la red, como el hardware del validador, el ancho de banda de la red y el tiempo de certificación, tiene dificultades para manejar bloques en el extremo superior de la capacidad.
Si la demanda eventualmente aumenta para cumplir el objetivo de 14 blobs o avanzar hacia el máximo de 21 blobs, las elevadas tasas de incumplimiento podrían traducirse en retrasos significativos en la finalidad o riesgo de reorganización. El informe enmarca esto como un límite de estabilidad: la red técnicamente puede procesar bloques de gran cantidad de blobs, pero hacerlo de manera consistente y confiable sigue siendo una cuestión abierta.
Economía de los blobs: por qué es importante el precio mínimo de reserva
Fusaka no sólo amplió la capacidad. También cambió el precio de los blobs a través de EIP-7918, que introduce un precio mínimo 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 se mantenía baja, la tarifa base de los blobs podía descender hasta desaparecer efectivamente como señal de precio. Los rollups de capa 2 pagan tarifas de blob para publicar sus datos de transacciones en Ethereum, y se supone que esas tarifas reflejan los costos computacionales y de red que imponen los blobs.
Cuando las tarifas caen a casi cero, el ciclo de retroalimentación económica se rompe y las acumulaciones consumen capacidad sin pagar en proporción. Esto da como resultado que la red pierda visibilidad respecto de la demanda real.
El precio mínimo de reserva de EIP-7918 vincula las tarifas de blob con los costos de ejecución, lo que garantiza que incluso cuando la demanda sea débil, el precio siga siendo una señal significativa.
Esto evita el problema del aprovechamiento gratuito, en el que los blobs baratos fomentan el uso despilfarrador y proporciona datos más claros para futuras decisiones sobre capacidad: si las tarifas de los blobs se mantienen elevadas a pesar del aumento de la capacidad, la demanda es genuina; si caen al suelo, existe espacio para la cabeza.
Los primeros datos del panel Dune de Hildobby, que rastrean los blobs de Ethereum, muestran que las tarifas de los blobs se han estabilizado después de Fusaka en lugar de continuar la espiral descendente observada en períodos anteriores.
El recuento 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 habitualmente contienen menos del objetivo de 14 bloques, y la distribución sigue estando muy sesgada hacia recuentos más bajos.
Lo que revelan los datos sobre la eficacia
Fusaka logró ampliar la capacidad técnica y demostrar que el mecanismo Blob Parameter Override funciona sin necesidad de polémicos bifurcaciones duras.
El precio mínimo de reserva parece estar funcionando según lo previsto, evitando que las tarifas blob pierdan su significado económico. Pero la utilización va por detrás de la capacidad, y la confiabilidad en los límites de la nueva capacidad muestra una degradación mensurable.
La curva de tasa de error sugiere que la infraestructura actual de Ethereum maneja cómodamente la línea de base anterior a Fusaka y los parámetros 10/15 de la primera anulación, pero comienza a superar los 16 blobs.
Esto crea un perfil de riesgo: si la actividad de la capa 2 aumenta y empuja los bloques hacia el máximo de 21 blobs regularmente, la red podría enfrentar tasas elevadas de fallas que comprometen la finalidad y la resistencia a la reorganización.
Los patrones de demanda ofrecen otra señal. La caída del uso medio de blobs después de la primera invalidación, a pesar del aumento de la capacidad, sugiere que los paquetes acumulativos de capa 2 actualmente no están limitados por la disponibilidad de blobs.
O sus volúmenes de transacciones no han crecido lo suficiente como para requerir más blobs por bloque, o están optimizando la compresión y el procesamiento por lotes para adaptarse a la capacidad existente en lugar de expandir el uso.
Blobscan, un explorador de blobs dedicado, muestra resúmenes individuales que publican recuentos de blobs relativamente consistentes a lo largo del tiempo en lugar de aumentar para explotar el nuevo margen de expansión.
La preocupación anterior a Fusaka era que la capacidad limitada de blobs obstaculizaría el escalamiento de la Capa 2 y mantendría elevadas las tarifas de acumulación a medida que las redes competían por la escasa disponibilidad de datos. Fusaka abordó la limitación de capacidad, pero el cuello de botella parece haber cambiado.
Los rollups no están llenando el espacio disponible, lo que significa que la demanda aún no ha llegado o que otros 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é viene después?
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 los blobs y al mismo tiempo mejoraría las propiedades de descentralización y seguridad.
Sin embargo, los resultados de Fusaka sugieren que la capacidad bruta no es la limitación vinculante en este momento.
La red tiene espacio para crecer hasta los parámetros 14/21 antes de necesitar otra expansión, y la curva de confiabilidad con un alto número de blobs indica que es posible que sea necesario actualizar la infraestructura antes de que la capacidad aumente nuevamente.
Los datos de tasa de fallos proporcionan una condición límite clara. Si Ethereum aumenta la capacidad mientras más de 16 bloques de blobs aún muestran tasas elevadas de fallas, se corre el riesgo de introducir inestabilidad sistémica que podría surgir durante períodos de alta demanda.
El camino más seguro es permitir que la utilización aumente hacia el objetivo actual, monitorear si las tasas de fallas mejoran a medida que los clientes optimizan para cargas de blobs más altas y ajustar los parámetros solo una vez que la red demuestre que puede manejar de manera confiable los casos extremos.
La efectividad de Fusaka depende de la métrica. Amplió la capacidad con éxito y estabilizó los precios de los blobs a través del piso de reservas. No impulsó aumentos inmediatos de utilización ni resolvió los desafíos de confiabilidad a la máxima capacidad.
La actualización creó margen para el crecimiento futuro, pero si ese crecimiento se materializa sigue siendo una pregunta abierta que los datos aún no han respondido.
