¿Qué es Fusaka?
El 3 de diciembre de 2025, Ethereum activará la actualización Fusaka en la mainnet, su segundo hard fork importante del año después de Pectra en mayo.
Los rollups ahora gestionan la mayoría de las transacciones de Ethereum y los ingresos por comisiones; sin embargo, todavía están limitados por la cantidad de datos que pueden publicar de vuelta a la Capa 1 y por el costo que implica.
Fusaka está diseñada para aliviar esa presión. Su característica principal, PeerDAS (muestreo de disponibilidad de datos entre pares), permite a los validadores verificar los datos de los blobs de los rollups sin descargarlos todos, lo que reduce los requisitos de ancho de banda y almacenamiento, al tiempo que abre la puerta a un rendimiento de datos mucho mayor.
Al mismo tiempo, los forks de parámetros solo para blobs (BPO), los nuevos límites de gas y de tamaño de bloque, y los ajustes de caducidad del historial, preparan la cadena para aumentos repetidos de capacidad en lugar de dar saltos puntuales.
En este artículo, desglosaremos lo que Fusaka cambia, dónde se sitúa en la hoja de ruta de Surge, Verge y Purge, y lo que podría significar para los usuarios, los rollups y el ecosistema de Ethereum en general en los próximos años.
¿Sabías que? El nombre de Fusaka proviene de dos nombres de código internos de actualizaciones, Osaka (capa de ejecución) y Fulu (capa de consenso), fusionados en «Fusaka».
De The Merge a Fusaka: La hoja de ruta
Para ver dónde encaja Fusaka, es útil mirar en perspectiva.
-
The Merge (2022) cambió Ethereum de proof-of-work a proof-of-stake, reduciendo el consumo de energía en aproximadamente un 99,9 %.
-
Shapella (2023) habilitó los retiros de Ether (ETH) en staking, transformando un sistema de staking unidireccional en un sistema líquido y atrayendo a más validadores.
-
Dencun (marzo de 2024) introdujo la Propuesta de Mejora de Ethereum (EIP) 4844 «blobs«, un carril de datos temporal más económico para los rollups, también conocido como protodanksharding.
-
Pectra (mayo de 2025) añadió funciones de abstracción de cuentas EIP-7702 y renovó los parámetros de staking, como el límite de 2.048 ETH para validadores.
Esas actualizaciones se alinearon con la hoja de ruta abreviada de Vitalik Buterin: Merge, Surge, Verge, Purge y Splurge. Surge trata sobre escalar Ethereum a través de rollups y una mejor disponibilidad de datos, mientras que Verge y Purge se centran en clientes más ligeros y la poda del historial antiguo.
Fusaka es la primera actualización que impulsa todas esas palancas a la vez. Escala datos para los rollups como parte de Surge y se inclina hacia la caducidad del historial y la sincronización más ligera como parte de Verge y Purge. También establece un objetivo claro para un stack modular de Ethereum que aspira a más de 100.000 transacciones por segundo (TPS) si se suma el rendimiento de la Capa 2 sobre la liquidación de la Capa 1.
PeerDAS, blobs y bloques más grandes
El cambio de escalado central de Fusaka es EIP-7594, PeerDAS.
En lugar de que cada nodo completo descargue blobs enteros de datos de rollup, PeerDAS los divide en celdas más pequeñas y utiliza muestreo y codificación de borrado, de modo que los validadores solo obtengan fragmentos aleatorios. Si hay suficientes fragmentos disponibles, la red puede estar segura de la existencia de los datos completos.
Eso reduce el ancho de banda por nodo y el almacenamiento, y sienta las bases para un eventual aumento de 8x en la capacidad de blobs con el tiempo sin forzar a los stakers domésticos a usar hardware de centros de datos.
Para hacer ese crecimiento más flexible, EIP-7892 introduce los forks Blob Parameter Only (BPO), pequeños hard forks que cambian solo tres parámetros relacionados con los blobs: target, max y el factor de ajuste de la tarifa base.
Después de Fusaka, Ethereum puede aumentar la capacidad de los blobs en pasos más pequeños y frecuentes a medida que crece la demanda de la Capa 2, en lugar de esperar años para un fork «big bang«.
En cuanto a la ejecución, Fusaka actualiza el gas y el tamaño de los bloques:
-
El objetivo efectivo de gas por bloque se eleva de los 45 millones actuales hacia techos mucho más altos. EIP-7825 limita el gas que una sola transacción puede usar, y EIP-7934 añade un límite de tamaño de bloque de 10 MB de Recursive Length Prefix para reducir el riesgo de denegación de servicio.
-
EIP-7823 y EIP-7883 vuelven a fijar el precio y limitan la precompilación MODEXP para que una llamada criptográfica pesada no pueda paralizar un bloque entero.
En lenguaje más sencillo, Fusaka le da a Ethereum más espacio para los datos de los rollups y las transacciones complejas, al tiempo que añade salvaguardias para que los bloques sigan siendo verificables para los nodos regulares.
¿Sabías que? Los blobs son paquetes de datos temporales publicados por los rollups en Ethereum. Son más baratos que los call data y se podan automáticamente después de unos 18 días para que no saturen la cadena.
UX, seguridad y herramientas para desarrolladores
No todo en Fusaka se trata de capacidad bruta. Varias EIP se centran en la experiencia del usuario, la seguridad y la ergonomía del desarrollador.
EIP-7917 (búsqueda anticipada determinista del proponente) hace que el programa del proponente para la siguiente época sea totalmente determinista y accesible on-chain a través de la raíz del beacon. Esto es importante para los rollups basados y los esquemas de pre-confirmación que necesitan saber con antelación qué validador propondrá un bloque dado para ofrecer garantías de finalidad suave rápidas y creíbles.
En cuanto a la experiencia del usuario (UX), EIP-7951 añade una precompilación secp256r1, dando a Ethereum soporte nativo para las firmas P-256, la curva utilizada por Secure Enclave de Apple, Android Keystore, Fast Identity Online 2 (FIDO2) y las passkeys WebAuthn. Esto permite que las billeteras confíen en la biometría a nivel de dispositivo y las passkeys en lugar de las frases semilla, acercando la capa 1 a los flujos de inicio de sesión fintech convencionales.
Los desarrolladores obtienen EIP-7939, el opcode de conteo de ceros iniciales, que cuenta los ceros iniciales en una palabra de 256 bits. Esto hace que las matemáticas a nivel de bits, la aritmética de números enteros grandes y algunos circuitos de prueba de conocimiento cero sean más económicos y fáciles de implementar.
Finalmente, EIP-7642 extiende el trabajo de vencimiento del historial de Ethereum, permitiendo a los clientes eliminar más datos anteriores al Merge y más antiguos, al mismo tiempo que anuncian qué rangos atienden. Esto puede ahorrar cientos de gigabytes por nodo y puede acelerar significativamente la sincronización para los nuevos validadores.
Quién gana qué: L2s, validadores y titulares de ETH
Para los ecosistemas L2s, la historia es sencilla. Las bifurcaciones PeerDAS y BPO se combinan para hacer que los datos sean más baratos y abundantes.
Los analistas estiman que Fusaka más la primera bifurcación BPO podrían reducir las tarifas de datos L2 entre un 40 % y un 60 % con el tiempo, especialmente para casos de uso de alto rendimiento como DeFi, gaming y social. Los blobs más baratos significan más espacio para la experimentación y potencialmente una nueva ronda de competencia entre rollups en cuanto a precio y experiencia de usuario.
Para los operadores de nodos y validadores, Fusaka aligera algunas cargas y añade otras. El muestreo y el vencimiento del historial reducen la cantidad de datos que los nodos necesitan descargar y almacenar, facilitando mucho la sincronización de los nuevos nodos con el bloque más reciente.
Sin embargo, a medida que las bifurcaciones BPO aumentan el recuento de blobs, los validadores y proveedores de infraestructura bien equipados soportarán un mayor ancho de banda de carga, lo que podría empujar sutilmente a la red hacia operadores más grandes si las implementaciones de los clientes y la guía no son cuidadosas.
Las instituciones y los proveedores de staking tienden a enmarcar Fusaka como un facilitador estratégico más que como un aumento de velocidad puntual. Un rendimiento de datos más predecible, límites de gas y tamaño de bloque más seguros y una gestión del historial más limpia hacen que las operaciones de validación a gran escala sean más fáciles de planificar.
Para los titulares de ETH, el impacto es sencillo. La capa base de Ethereum se está ajustando como un motor de liquidación y datos de alta capacidad para las L2s, con tarifas mínimas y precios de blobs ajustados para que más actividad se liquide en Ethereum, lo que puede influir en los mercados de tarifas y las recompensas de los validadores según la demanda.
Sin embargo, hay concesiones. El protocolo se vuelve más complejo y un mayor enfoque en la monetización podría generar críticas si los usuarios cotidianos no perciben mejoras claras en el costo y la experiencia.
¿Sabías? Durante la llamada de coordinación final para Fusaka, el slot de activación se estableció en el slot 13.164.544, esperado alrededor de las 21:49 UTC del 3 de diciembre, para la mainnet.
Después de Fusaka: Glamsterdam y el camino hacia 100.000 TPS
La próxima actualización con nombre, Glamsterdam, se espera que llegue en 2026 y ya tiene dos puntos destacados: la separación de constructor y proponente consagrada (ePBS) y las listas de acceso a nivel de bloque (BALs).
-
ePBS tiene como objetivo fortalecer la cadena de suministro de valor máximo extraíble (MEV) al dividir la construcción y la propuesta de bloques a nivel de protocolo en lugar de depender únicamente de retransmisiones externas.
-
Las BALs apuntan a una ejecución más eficiente y un mejor manejo del acceso al estado, incluyendo futuros aumentos en la capacidad de los blobs.
Las bifurcaciones PeerDAS y BPO hacen avanzar The Surge. Las extensiones de vencimiento del historial y los ajustes peer-to-peer (P2P) llevan los temas de The Verge y The Purge. Las mejoras en la experiencia del usuario, como el «proposer lookahead» y el soporte P-256, hacen que las preconfirmaciones y las carteras con passkey sean realistas a escala.
Si Ethereum cumple con esta cadencia, Fusaka será recordada menos como un evento único y más como un punto de inflexión. Marca el momento en que la hoja de ruta se transformó en un programa de escalado coherente y consciente del valor. Su objetivo es soportar un stack modular de 100.000 TPS sin abandonar la descentralización que hizo valiosa la red en primer lugar.

