Ethereum Fork: Fusaka - Qué esperar de este fork?
El último fork de Ethereum programado para el 3 de Diciembre del 2025
Antes de hablar de Fusaka necesitamos ponernos en contexto con otro gran upgrade/fork después de The Merge que ocurrió hace algún tiempo, me refiero a Dencun. Y por qué es importante? , pues ya lo verás.
Dencun
El nombre viene de la combinación de Deneb (capa de consenso) y Cancún (capa de ejecución). Este fue uno de los más grandes upgrades, ya que ayudó mucho a escalar las soluciones de capa 2 (L2), ayudando a:
Reducir los costos de rollups L2.
Introdujo un nuevo tipo de datos: blobs.
Abrió al camino hacia Danksharding, el futuro escalamiento masivo de Ethereum.
¿Qué es Proto-Danksharding (EIP-4844)?
Es el primer paso hacia al Danksharding completo y su objetivo principal es hacer mas barato y eficiente el data availability que utilizan las L2 (Optimistic y ZK Rollups).
Antes de que el upgrade ocurriera, los rollups publicaban sus datos en calldata y esto lo hacia muy caro, ya que competían por el espacio dentro de un bloque normal. Y esto provocaba unos fees mas altos en L2s. Bueno tampoco tan altos, en general son mas baratas, pero esto hace mayor referencia al proceso de reflejar ese batch de transacciones desde la L2 en la L1.
Si revisamos el roadmap de Ethereum aparece el Danksharding y en este upgrade se introdujo el Proto-Danksharding para encaminarnos hasta esa configuración final. Esto introdujo un nuevo tipo de objeto en el bloque, los blobs. Estos están hechos específicamente para datos de rollups y son mucho más baratos ya que no compiten por el calldata.
¿Qué son los blobs?
Piensa en un blog como:
Un paquete temporal de datos (hasta ~128 KB) que la L2 publica dentro del bloque, pero que los nodos no almacenan para siempre
Literalmente son eso, datos almacenados temporalmente, hasta 18 dias aproximadamente, lo que es suficiente para validadores de rollups en caso de alguna disputa. Al no quedar como calldata se reducen los costos.
Qué cambió técnicamente con Dencun / EIP-4844
Aquí vamos un poquito más técnicos, pero tampoco tanto, si quieres te la saltas esta parte.
Como dijimos anteriormente, en este upgrade se presenta una nueva arquitectura de datos: blobs.
Los blobs son un chunk de datos binarios grandes, como dijimos, aprox 128 KiB cada uno.
Estos blobs permiten que los rollups publiquen datos masivamente sin usar el mecanismo tradicional que ocupaba calldata -el cual es permanente- en la L1.
Los blobs se almacenan temporalmente en los nodos de consenso (beacon node), no permanentemente como calldata. Luego de un periodo fijo (~18-20 días), pueden ser podados para no incrementar el tamaño de la blockchain permanentemente.
Separación entre capa de ejecución (EVM) y capa de data (Consenso / DA)
Con esta arquitectura, la data availability (DA) o data de disponibilidad,
que horrible la traducción, pasa a manejarse por la capa de consenso (beacon / blobs), no por la capa de ejecución.Esto significa que el código del smart contract / EVM ya no tiene que almacenar todo el historial de datos que publica un rollup, solo necesita referencias (algo como un compromiso criptográgico) si se requieren.
Nuevo mercado de tarifas (“fee market") dual: gas + blob-fees
Antes de Dencun, todas las transacciones, incluyendo las publicadas por los rollups, pagaban una sola tarifa: el gas tradicional de la EVM.
Este gas cubría dos cosas al mismo tiempo:
Computación (ejecutar código en la EVM)
Datos publicados (como el calldata, que es permanente en la L1)
¿El problema?
Los rollups no necesitan computación en la L1: solo necesitan publicar datos para que todos puedan verificarlos. Pero aun así tenían que pagar gas caro por esos datos, porque competían con las transacciones normales dentro del bloque.
Dencun separó estas dos cosas, y ahora tenemos dos mercados de fees independientes:
Gas fee (el de siempre)
Paga por computación y ejecución EVM.
Afecta las txs normales.
Queda igual, aquí nada cambia
Blob-fee (nuevo)
Es solo para los blobs (datos grandes de rollups)
Tiene su propio market, separado del gas.
Su precio depende únicamente de la demanda de publicación de datos, no del uso de la EVM.
Habiendo dicho esto, lo importante es que ahora
Las L2s no compiten con las transacciones normales dentro del bloque.
Escribí todo lo anterior solo para resumirlo en lo anterior, en fin, la hipotenusa. Ahora si vamos con Fusaka. Me da pena que no le hayan puesto Fukuoka para haber citado a Juan Luis Guerra, pero se me viene la canción a la cabeza inevitablemente.
Fusaka Upgrade: El próximo gran salto de Ethereum
Ahora si que si, Ethereum vuelve a actualizarse. Después de Dencun, ahora viene Fusaka, el siguiente paso en la escalabilidad modular dentro del roadmap de Ethereum.
Fusaka se activa el 3 de Diciembre del 2025 y trae cambios profundos que mejoran cómo Ethereum maneja datos, cómo escalan las L2, y cómo funciona la propia red a nivel de nodos y validación.
¿Qué es el Fusaka Upgrade?
Es un hard fork que introduce 12 EIPs enfocados en escalabilidad, eficiencia y estabilidad del sistema.
Miren no les voy a dar la lata con los 12 EIPs, ni tampoco nos vamos a poner tan técnicos. Vamos allá.
PeerDAS (EIP-7594)
Con Dencun ya sabemos que los rollups empezaron a publicar sus datos en blobs. Estos blobs son paquetes grandes que se deben distribuir a los nodos para garantizar data availability.
Pero había un límite: cada nodo tenía que descargar cada blob completo para verificar que los datos estaban realmente disponible.
Esto funciona cuando hay pocos blobs, pero no cuando quieres escalar a miles de rollups a millones de transacciones provenientes de las L2 por segundo en el futuro -si realmente queremos escalar.
PeerDAS cambia todo
PeerDAS (Peer Data availability Sampling) introduce una idea poderosa:
Los nodos ya no necesitan descargar el blob completo. Solo descargan pequeñas muestras aleatorias del blob.
¿Y esto es seguro?
Si, Ethereum usa técnicas de codificación tipo erasure coding. Esto en español es:
Los blobs se dividen en muchas piezas.
Cada nodo recibe
almacenasolo algunas piezas.Si suficientes nodos pueden reconstruir el blob desde sus piezas, se garantiza que el blob completo está disponible.
Ya aun más simple
En vez de que un nodo cargue todo el peso, ahora todos colaboran: cada uno guarda un pedacito. Juntos verifican que los datos existen sin que nadie que bajarlo todo.
BPO Forks (EIP-7892): Ajustes dinámicos sin hard-fork
Con Dencun, ethereum fijó ciertos parámetros de blobs: tamaño, cantidad por bloque, etc. El problema es que esos parámetros no pueden quedarse fijos cuando las L2 sigan creciendo.
Fusaka introduce los Blob-Parameter-Only Forks (BPO)
¿Y eso que rayos significa?
Ethereum podrá ajustar ciertos parámetros de los blobs SIN necesidades de un hard-fork completo
Esto incluye cosas como:
cuántos blobs por bloque se pueden incluir
cuánto pesan estos blobs
cómo se distribuyen
cómo se validan los blobs
Esto es importante porque la cantidad de blobs irá creciendo, y Ethereum debe aumentar esa capacidad de manejar mayor cantidad de transacciones provenientes de las L2s sin necesidades de entrar en un upgrade gigante cada poco tiempo.
BPO le da flexibilidad a Ethereum para seguir escalando de forma continua.
EIP-7918: El “blob reserve fee” — tarifas más estables
Después de Dencun, el precio de los blobs se volvió muy barato, tanto que a veces casi llegaba a cero cuando bajaba la actividad.
Esto tiene un problema:
Si la tarifa baja demasiado, la red podría llenarse de blobs de baja calidad.
Para estabilizar esto, Fusaka introduce un precio mínimo para los blobs: el blob reserve fee.
En castellano ahora
Los blobs ahora tienen un piso mínimo de precio. Nunca podrán ser completamente gratuitos
¿Qué se logra con esto?
Estabilidad en los costos de publicar datos L2
Prevención de spam y blobs "basura"
Un mercado de tarifa más predecible
Mejor flujo económico para los validadores y para ETH como activo
Es una mejora económica clave dentro del ecosistema modular.
Algunos otros cambios importantes
Pueden revisarlos todos aquí, pero algunos otros cambios son:
Límites aumentados de gas por bloque, que permite más throughput -
la cantidad de TPS- sin saturar la red.Límite de gas por transacción, para evitar que una sola transacción gigante consuma todo el bloque, esta va de la mano con el update anterior.
Nuevos opcodes y mejoras en la EVM. Optimización de operaciones criptográgicas y bitwise, muy útiles para ZK-rollups y verificación eficiente.
Mejoras en nodos y sincronización. Gracias a PeerDAS, corre un nodo será menos costoso, especialmente en regiones con internet limitado.
Conclusión
Fusaka no es solo otro upgrade; es un paso gigantesco para hacer Ethereum más eficiente, más escalable y más accesible para todos.
Si Dencun abrió la puerta a un ecosistema modular basado en rollups, Fusaka amplifica esa capacidad y la hace realmente usable a gran escala.
Los próximos años seguirán empujando esta dirección: más blobs, más rollups, más throughput y un Ethereum que funciona como la base económica segura para miles de cadenas en paralelo.
El 3 de diciembre de 2025 marca otro hito importante en ese camino. Vamos que vamos!