Ethereum activó la actualización Fusaka el 3/12/2025, ampliando significativamente la capacidad de disponibilidad de datos de la red mediante el mecanismo Blob Parameter Overrides. Este mecanismo permite ajustar progresivamente el objetivo y el límite máximo de blobs — paquetes de datos de transacción comprimidos que los layer-2 rollups suben a Ethereum para garantizar seguridad y completitud.
Las dos siguientes modificaciones elevaron el objetivo de blobs por bloque de 6 a 10, y luego a 14, mientras que el límite máximo se incrementó a 21. El objetivo principal de Fusaka es reducir los costos para los rollups aumentando el rendimiento de datos de los blobs.
Sin embargo, tras tres meses de recopilación de datos, los resultados muestran una brecha clara entre la capacidad técnica y el uso real. El análisis de MigaLabs sobre más de 750.000 slots desde la activación de Fusaka indica que la red aún no alcanza el objetivo de 14 blobs por bloque.
Es notable que la utilización mediana de blobs incluso disminuyó tras la primera modificación de parámetros. Los bloques con 16 blobs o más tienen una tasa de fallos significativamente mayor, lo que indica que la fiabilidad de la red disminuye al acercarse a los nuevos límites de capacidad.
La conclusión del informe es bastante franca: no se debe seguir aumentando el parámetro de blobs hasta que la tasa de fallos en bloques con muchos blobs vuelva a niveles normales y exista una demanda real que llene la capacidad creada.
¿Qué cambió con Fusaka y cuándo ocurrió?
Antes de Fusaka, según EIP-7691, Ethereum apuntaba a 6 blobs por bloque con un límite máximo de 9. La actualización Fusaka introdujo dos ajustes consecutivos en el Blob Parameter Override.
El primero se activó el 9/12/2025, elevando el objetivo a 10 y el límite máximo a 15. El segundo ocurrió el 7/1/2026, aumentando el objetivo a 14 y el límite a 21.
*La hoja de ruta de Fusaka de Ethereum muestra que los parámetros de blobs aumentaron desde 6/9 hasta 12/15 y luego 14/21 en el período de diciembre de 2025 a enero de 2026.*Estos cambios no requieren un hard fork, permitiendo a Ethereum ajustar la capacidad mediante coordinación entre clientes en lugar de una actualización a nivel de protocolo.
El análisis de MigaLabs, con código fuente y métodos reproducibles, monitorea el uso de blobs y el rendimiento de la red durante esta transición. Los resultados muestran que la mediana de blobs por bloque bajó de 6 a 4 tras el primer override, aunque la capacidad total se amplió. Los bloques con 16 blobs o más son extremadamente raros, apareciendo entre 165 y 259 veces en todo el período de observación.
En otras palabras, la red tiene margen, pero aún no lo ha explotado.
El informe también señala una inconsistencia: la descripción en la línea de tiempo indica que el primer override elevó el objetivo de 6 a 12, mientras que los anuncios en mainnet y la documentación de Ethereum Foundation confirman que el aumento fue de 6 a 10. En este análisis, se utilizan los parámetros oficiales de Ethereum Foundation, mientras que los datos empíricos de uso y tasa de fallos de MigaLabs se consideran la base del análisis.
La tasa de fallos aumenta notablemente en bloques con muchos blobs
La fiabilidad de la red se mide mediante los slots fallidos — bloques que no se transmiten o verifican correctamente — mostrando una tendencia muy clara.
En niveles bajos de blobs, la tasa de fallos básica ronda el 0,5%. Cuando un bloque contiene 16 blobs o más, esta tasa aumenta a entre 0,77% y 1,79%. En el límite máximo de 21 blobs, tras el segundo override, la tasa de fallos alcanza 1,79%, más de tres veces la base.
El análisis por niveles de blobs de 10 a 21 muestra una curva de disminución de fiabilidad que se vuelve más evidente al superar el objetivo de 14 blobs.
Esto es especialmente importante porque indica que la infraestructura actual de Ethereum — hardware de validadores, ancho de banda y tiempo de attestación — tiene dificultades para procesar bloques en los límites superiores de capacidad.
Si en el futuro la demanda crece rápidamente y empuja los bloques cerca del límite de 21 blobs con frecuencia, la alta tasa de fallos podría causar retrasos en la finalización o aumentar el riesgo de reorganizaciones (reorg). El informe considera esto como un umbral estable: la red puede manejar técnicamente bloques con muchos blobs, pero mantener esa capacidad de forma estable y confiable aún no está garantizado.
La tasa de errores se mantiene por debajo del 0,75% en bloques con menos de 16 blobs, pero supera el 1% en niveles mayores, alcanzando 1,79% en bloques con 21 blobs.## Economía de los blobs y el papel del precio mínimo de reserva
Fusaka no solo amplía la capacidad, sino que también cambia el mecanismo de fijación de precios de los blobs mediante EIP-7918, que introduce un precio mínimo de reserva para evitar que las subastas de blobs caigan por debajo de 1 wei.
Antes, cuando la demanda de blobs era baja y los costos de ejecución dominaban, la tarifa base (base fee) de los blobs podía reducirse a casi cero, haciendo que la señal de precio perdiera sentido. Mientras tanto, los rollups layer-2 deben pagar tarifas de blobs para subir datos de transacción a Ethereum, y se espera que estas tarifas reflejen los costos computacionales y la carga en la red que generan los blobs.
Cuando las tarifas se acercan a cero, se rompe el ciclo económico, incentivando el consumo de capacidad sin pagar un costo proporcional, lo que impide que la red observe la demanda real.
El precio mínimo de reserva de EIP-7918 vincula la tarifa de blobs a los costos de ejecución, asegurando que incluso en condiciones de baja demanda, el precio sirva como una señal económica significativa. Esto ayuda a evitar el problema del “free-rider” y proporciona datos más claros para decisiones futuras de expansión de capacidad.
Los datos iniciales del dashboard de Dune de Hildobby muestran que las tarifas de blobs se estabilizaron tras Fusaka, en lugar de seguir una tendencia descendente marcada en fases anteriores. La media de blobs por bloque también confirma que la utilización aún no llena la nueva capacidad, apoyando la conclusión de MigaLabs.
Las tarifas de transacción de “blob” alcanzaron picos superiores a 2 millones de dólares a principios y finales de 2024, y disminuyeron durante 2025, manteniéndose en niveles bajos en 2026.## ¿Qué tan efectivo ha sido Fusaka?
Desde un punto de vista técnico, Fusaka ha logrado ampliar la capacidad y demostrar que el mecanismo Blob Parameter Override puede funcionar sin un hard fork controvertido. La tarifa mínima de reserva también está funcionando, evitando que las tarifas de blobs se vuelvan económicamente insignificantes.
Sin embargo, el uso sigue siendo menor que la capacidad, y la fiabilidad disminuye claramente en los límites superiores. La curva de tasa de fallos indica que la infraestructura actual maneja bien los niveles previos a Fusaka y los parámetros 10/15 tras el primer override, pero empieza a sufrir presión al superar los 16 blobs.
Esto crea un perfil de riesgo claro: si los layer-2 aumentan su actividad de forma repentina y empujan los bloques cerca del límite de 21 blobs con frecuencia, la red podría enfrentarse a tasas de fallos elevadas, afectando la finalización y la resistencia a reorganizaciones.
Por otro lado, la reducción de la mediana de blobs tras el primer override, pese a la ampliación de capacidad, indica que los rollups aún no están limitados por la disponibilidad de blobs. Puede ser que su volumen de transacciones no sea lo suficientemente grande, o que estén optimizando compresión y batching para ajustarse a la capacidad actual en lugar de expandir su uso.
Los datos de Blobscan también muestran que los rollups individuales mantienen un número relativamente estable de blobs a lo largo del tiempo, en lugar de aprovechar rápidamente la capacidad sobrante.
Próximos pasos de Ethereum
El plan de Ethereum sigue incluyendo PeerDAS, un rediseño más profundo del muestreo de disponibilidad de datos para ampliar la capacidad de blobs y mejorar la descentralización y seguridad.
No obstante, los resultados de Fusaka indican que la capacidad bruta actual no es el principal cuello de botella. La red aún tiene margen para “crecer” dentro del rango de 14/21 antes de necesitar más expansión, mientras que los datos sobre tasas de fallos en blobs altos muestran que la infraestructura debe actualizarse en paralelo.
Una estrategia más segura es dejar que el uso aumente progresivamente hacia el objetivo actual, monitoreando si la tasa de fallos mejora cuando los clientes y validadores optimizan para cargas altas de blobs, y solo ajustar los parámetros cuando la red demuestre capacidad para manejar casos límite de forma estable.
Fusaka ha creado espacio para el crecimiento futuro y estabilizado la economía de los blobs, pero aún no ha provocado un aumento explosivo en el uso ni resuelto completamente los desafíos de fiabilidad en la capacidad máxima. La cuestión de si esa capacidad será completamente utilizada sigue abierta, y los datos actuales no ofrecen una respuesta definitiva.
