¿Qué pasó en Ethereum tras la llegada de Fusaka? 

Fusaka, la última actualización de Ethereum, está operativa en la red desde el 3 de diciembre. Con ella, este ecosistema recibió su segundo hard fork (bifurcación dura) del año, después de Pectra en mayo.  

Como lo reportó CriptoNoticias, la propuesta conocida como PeerDAS es la mejora más relevante de Fusaka y trajo a la red algo que el propio Vitalik Buterin esperaba desde 2015.  

PeerDAS introduce un sistema para verificar la disponibilidad de datos mediante muestreo entre nodos. En lugar de que cada nodo tenga que descargar todos los blobs completos (espacio donde almacenan información las redes de segunda capa), ahora solo solicita pequeñas muestras aleatorias a distintos pares.  

El gráfico a continuación, tomado horas después del lanzamiento de Fusaka, refleja a PeerDAS operando de la manera prevista: 

En la imagen, un nodo ubicado en Finlandia (“tysm”) solicita a la red algunas columnas de datos correspondientes a blobs utilizados por Base y Arbitrum.  

Ese nodo en particular no tiene almacenadas esas muestras, por lo que aparece el mensaje ‘MISSING’. Esto es normal en PeerDAS: los nodos ya no necesitan guardar todos los datos para verificar su disponibilidad. 

En lugar de eso, el nodo consulta a otros pares (en este caso, un nodo en Taiwán). Estos pares sí cuentan con esas columnas y las envían en menos de medio segundo.  

De esta forma, la red confirma que los datos asociados están disponibles, aun cuando no estén replicados íntegramente en cada nodo. 

Este comportamiento refleja exactamente el objetivo de PeerDAS en Ethereum: reducir la carga de almacenamiento individual y, al mismo tiempo, garantizar que la información siga accesible para quienes la necesiten. 

Redes de segunda capa de Ethereum publican más datos en forma de blobs 

El siguiente gráfico “Average Blob Count per Block” (promedio de blobs por bloque) muestra la evolución del número promedio de blobs por bloque. 

La línea negra asciende desde alrededor de “4” (eje izquierdo) hasta aproximarse al objetivo marcado en “6” blobs por bloque (línea celeste horizontal).  

Esto indica que, tras Fusaka, la red empezó a utilizar más espacio de blobs en los bloques, acercándose al objetivo definido para ese parámetro.  

En términos sencillos: las L2 empezaron a publicar más datos en forma de blobs, y PeerDAS comienza a ejercer su papel de comprobación sobre ese mayor tráfico. 

¿Por qué es útil para las L2? Porque al fragmentar y distribuir la carga entre muchos nodos, el sistema permite que las capas dos puedan publicar más datos sin depender de que cada nodo de Ethereum descargue y verifique todo por completo.  

Eso reduce costos operativos, mejora la velocidad con la que se procesan los lotes y habilita que las L2 sigan escalando sin imponer una carga creciente a la red base. 

En adición, lo que muestra ese gráfico es apenas el comienzo de una secuencia planificada de ampliaciones, por lo que este efecto se acrecentará en el futuro. 

A partir de la propuesta EIP-7892, que plantea una serie de actualizaciones graduales que ajustan exclusivamente el límite de los blobs, el 9 de diciembre se activará un fork que elevará el objetivo actual de blobs de 6 a 10, y el 7 de enero del año entrante otro fork lo llevará de 10 a 14. 

Tarifa de blobs: el pico y la corrección tras Fusaka

Horas antes de la llegada de Fusaka, la red registró un pico abrupto en los blobs fees las tarifas que pagan las L2 para publicar sus datos en Ethereum mediante los blobs. 

De acuerdo con el siguiente gráfico, esa tarifa llegó a unos 1.463 gwei (unidad mínima de ether que se usa para expresar tarifas en Ethereum), equivalentes a unos 0,0047 dólares actualmente: 

Hasta la integración de Fusaka, el piso de los blobs fees era prácticamente simbólico. El mínimo posible estaba fijado en 0,000000001 Gwei y permanecía clavado allí siempre que no hubiese congestión.  

Ese piso estático llevaba a que los L2 publicaran datos en Ethereum casi gratis el 99% del tiempo, incluso cuando su actividad generaba un costo real para la red. 

Con la activación de Fusaka y, en particular, EIP-7918, ese “suelo” tarifario de los blobs dejó de ser fijo y pasó a un sistema dinámico vinculado al costo real de operar en la L1.  

El piso de las comisiones de los blobs se situó en alrededor de un dieciseisavo (1/16) de la tarifa base de Ethereum, según el texto de la EIP-7918. 

Así se ve el suelo dinámico de los blobs fees tras Fusaka: 

Considerando niveles habituales de uso de Ethereum, el sistema establecido por EIP-7918 sitúa el mínimo de blobs fees en valores que suelen ubicarse entre 0,01 y 0,5 gwei (es decir, entre decenas y cientos de millones de veces por encima del antiguo mínimo de 1 wei). A diferencia del esquema previo, ya no puede descender hasta cero. 

Además, este nuevo piso tarifario tiene un efecto directo en la economía de Ethereum: al cobrar un mínimo realista por los blobs, la red deja de subsidiar su verificación y pasa a generar más ingresos por comisiones. 

Por otro lado, y para el usuario final, el impacto es casi imperceptible: las comisiones en las L2 siguen siendo muy bajas, porque estos costos se diluyen entre millones de transacciones. 

Límite de gas por bloque: más capacidad para datos 

A partir de EIP-7935, tras Fusaka, los clientes de Ethereum operan por defecto con un límite de gas por bloque de 60 millones. Eso implica un crecimiento del 100% desde los 30 millones que usaba la red a comienzos de 2025.  

El “límite de gas” define cuánto trabajo computacional o cuánto espacio de transacciones puede incluirse en un bloque. Al margen de Fusaka, el límite de gas es una medida que consensuan los validadores, pudiendo incrementarla o bajarla. 

Subirlo a 60 millones permite contener más transacciones por bloque, lo que facilita que la red soporte mayor carga sin congestión inmediata. 

Un software de consenso de Ethereum falló tras Fusaka 

Finalmente, horas después de que Fusaka entrara en funcionamiento, el cliente de consenso Prysm (uno de los programas que usan los nodos para coordinar la cadena) sufrió un fallo. El mismo dejó temporalmente fuera de juego a cerca del 23% de la red.  

Por lo que comunicaron desde Prysm, no hay indicios de que el fallo haya sido provocado por Fusaka. 

El equipo de Prysm identificó el problema y publicó una solución sencilla que cualquier operador podía aplicar en minutos añadiendo una línea de código a su nodo, sin necesidad de descargar una versión nueva.  

Gracias a eso, la red siguió funcionando sin mayores consecuencias.