Fusaka ya está activo, y el debate ha pasado de lo que haría a lo bien que ha funcionado. Activado siete meses después de Pectra, marcó la segunda bifurcación dura de Ethereum de 2025 y su tiempo de respuesta más rápido entre actualizaciones importantes desde que la red pasó a prueba de participación.

El lanzamiento confirmó un cambio de ritmo. Los desarrolladores CORE reemplazaron la antigua cadencia anual por bifurcaciones más ajustadas y frecuentes, y Fusaka fue la prueba de concepto. Esto es lo que realmente se implementó, cómo respondió la red y lo que esto significa para ETH a medida que avanzamos en 2026. 👇

¿Qué fue la actualización Fusaka de Ethereum?

La actualización Fusaka de Ethereum fue una bifurcación dura coordinada que se activó en la mainnet el 3 de diciembre de 2025. Siguiendo la tradición, el nombre combina "Fulu", una estrella de la constelación de Casiopea, con "Osaka", una antigua ciudad anfitriona de Devcon, uniendo las capas de consenso y ejecución en un único lanzamiento.

Fusaka se centró en la escalabilidad en lugar de en características orientadas al usuario, a diferencia de la actualización Pectra que la precedió. Su cambio principal, PeerDAS (EIP-7594), reestructuró la forma en que los nodos confirman la existencia de datos de blobs de Layer 2, permitiéndoles muestrear fragmentos en lugar de almacenar cada byte. Esto sentó las bases para el Danksharding completo.

La bifurcación incluyó alrededor de doce Propuestas de Mejora de Ethereum, la mayoría heredadas de rondas de alcance anteriores, con un enfoque en fortalecer la Ethereum Virtual Machine y la capa de datos. Juntas, posicionaron a Ethereum para soportar rollups más rápidos y aplicaciones con gran cantidad de datos sin llevar los requisitos de los nodos más allá del hardware de consumo.

Beneficios clave que Fusaka aportó

Fusaka priorizó la salud de la red y la escalabilidad predecible sobre las características destacadas, reflejando la cautela que dio forma a su alcance final. Los cambios redefinieron cómo Ethereum maneja cargas de datos más pesadas y cómo los validadores coordinan la producción de bloques en toda la red.

Los beneficios CORE que introdujo Fusaka incluyen los siguientes:

• Muestreo de blobs (PeerDAS): Reduce la presión de ancho de banda y almacenamiento en los nodos de consenso en aproximadamente un 85%, permitiendo a los validadores verificar la disponibilidad de blobs a partir de muestras parciales en lugar de descargas completas.
• Mayor rendimiento de blobs: Elevó el máximo de blobs por bloque de 9 a 21 mediante bifurcaciones escalonadas, expandiendo drásticamente la capacidad de Layer 2 y reduciendo los costos de publicación de rollups con el tiempo.
• Mayor límite de gas de L1: Elevó el límite de gas de bloque predeterminado a 60 millones a través de EIP-7935, dando a la capa base aproximadamente un 20-30% más de espacio para transacciones y ejecución de contratos inteligentes complejos.
• Escalado flexible de blobs (EIP-7892): Añadió bifurcaciones de solo parámetros de Blob, actualizaciones ligeras que ajustan la configuración de blobs sin una bifurcación dura completa cada vez que los desarrolladores desean más capacidad.
• Proponentes predecibles (EIP-7917): Permitió la anticipación determinista de proponentes, para que los validadores sepan quién propone los próximos bloques con antelación, lo que ayuda a las preconfirmaciones y a la estabilidad del consenso.
• Firma nativa con passkey (EIP-7951): Se añadió una precompilación secp256r1, desbloqueando firmas nativas del dispositivo a través de WebAuthn, FIDO2 y módulos de seguridad de hardware para una incorporación más fluida a la wallet.

Fusaka PeerDAS y la decisión sobre EOF explicadas

Dos componentes definieron el alcance de Fusaka: PeerDAS, que se incluyó en el lanzamiento como característica principal, y EOF, que los desarrolladores finalmente eliminaron. Comprender ambos explica por qué la actualización final resultó más austera de lo que sugerían las primeras hojas de ruta.

¿Qué es PeerDAS en Fusaka?

PeerDAS (Peer Data Availability Sampling) permite a los nodos de la capa de consenso confirmar grandes transacciones de blobs verificando pequeñas porciones aleatorias en lugar de descargar cada blob completo. Los datos se dividen en 128 columnas distribuidas por la red, de modo que cada nodo almacena solo una fracción mientras garantiza colectivamente la disponibilidad.

Este diseño rompió el vínculo entre el rendimiento de los blobs y el costo del hardware del validador, permitiendo a Ethereum escalar la capacidad de datos sin exigir máquinas de nivel empresarial. Los desarrolladores despriorizaron todas las características que corrían el riesgo de retrasar PeerDAS, ya que era el requisito previo para satisfacer la futura demanda de rollup y data availability, como se explica en nuestro explicador de EIP-4844.

Por qué se eliminó EOF de Fusaka

EVM Object Format (EOF) tenía como objetivo reestructurar los contratos inteligentes estableciendo límites claros entre el código, los datos y los metadatos, reemplazando el bytecode no estructurado actual. El plan agrupó aproximadamente una docena de EIP coordinados en la primera revisión profunda de la EVM desde su creación.

Los desarrolladores CORE eliminaron EOF de Fusaka después de una llamada de todos los desarrolladores CORE en abril de 2025, citando complejidad no resuelta, riesgo en el cronograma y falta de consenso general. El líder del protocolo, Tim Beiko, enmarcó el recorte como una protección para PeerDAS, dejando a los defensores de EOF la tarea de presentar su caso para una bifurcación posterior en lugar de forzar su implementación.

Cronograma de lanzamiento de Ethereum Fusaka

Fusaka llegó a la mainnet según lo programado después de superar tres testnets públicas durante octubre de 2025. El despliegue continuó a través de dos bifurcaciones solo de parámetros que escalaron la capacidad de blobs en pasos medidos en lugar de todo a la vez, un enfoque deliberadamente cauteloso dada la novedad de la técnica de muestreo.

El despliegue de Fusaka se desarrolló a través de estos hitos clave:

• testnet Holesky: Activada el 1 de octubre de 2025, probando cambios de base, incluido el aumento del límite de gas y el rendimiento del validador bajo las nuevas reglas.
• testnet Sepolia: Activada el 14 de octubre de 2025, centrada en el comportamiento de PeerDAS y simuló límites de gas más altos en las implementaciones de clientes.
• testnet Hoodi: Activada el 28 de octubre de 2025, el ensayo final de validador sin permisos antes de que los desarrolladores confirmaran la preparación de la mainnet.
• Activación de la mainnet: Se activó el 3 de diciembre de 2025 en la época 411392, finalizando limpiamente en aproximadamente quince minutos en todos los clientes principales.
• Bifurcación BPO1: Activada el 9 de diciembre de 2025, elevando el objetivo de blobs a 10 y el máximo a 15 por bloque.
• Bifurcación BPO2: Activada el 7 de enero de 2026, elevando el objetivo a 14 y el máximo a 21, completando el ajuste de parámetros de Fusaka.

Lista de EIP de Ethereum Fusaka

El conjunto final de EIP de Fusaka se centró en tres objetivos: escalar la capacidad de datos de Layer 2, mejorar la eficiencia de ejecución de Layer 1 y refinar la experiencia de desarrolladores y validadores. Según el anuncio de la mainnet de la Ethereum Foundation y el seguimiento de Forkcast, estas fueron las propuestas que dieron forma al lanzamiento.

Los EIP de Fusaka más importantes por su función incluyen los siguientes:

• EIP-7594: Introdujo PeerDAS, el protocolo de muestreo que permite a los nodos de consenso verificar la disponibilidad de blobs sin descargas completas, siendo el pilar de toda la actualización.
• EIP-7892: Habilitó los forks de solo parámetros de blob, permitiendo ajustes ligeros a los objetivos y máximos de blobs sin un hard fork coordinado completo.
• EIP-7935: Estableció el límite de gas por bloque predeterminado en 60 millones, estandarizando un valor entre clientes que los validadores ya habían empezado a adoptar incluso antes de la activación.
• EIP-7825: Limitó el gas por transacción a aproximadamente 16.7 millones (2²⁴), una medida de endurecimiento contra ataques DoS que también sienta las bases para la parallel execution.
• EIP-7918: Limitó la tarifa base de los blobs por el costo de ejecución, evitando que los precios de los blobs colapsaran a 1 wei y preservando una señal de tarifa significativa.
• EIP-7951: Añadió una precompilación secp256r1, permitiendo que las firmas tipo passkey y respaldadas por hardware se verifiquen de forma económica on-chain.
• EIP-7917: Proporcionó una anticipación determinista del proponente, permitiendo que los rollups y las aplicaciones anticipen a los próximos proponentes de bloques para una mejor secuenciación.
• EIP-7939: Añadió el opcode CLZ (count leading zeros), ofreciendo a los desarrolladores una instrucción nativa económica para matemáticas a nivel de bit y asistentes criptográficos.

Varias propuestas más pequeñas completaron el paquete, incluyendo el par de repricing ModExp (EIP-7823 y EIP-7883), el límite de tamaño de bloque RLP (EIP-7934) y mejoras en el protocolo de red (EIP-7642). Estas principalmente ajustaron la economía del gas y la eficiencia de propagación a medida que crecía la capacidad del bloque.

Cómo respondió la red después del lanzamiento

La verdadera prueba de Fusaka llegó después de la activación, cuando los datos de uso de blobs en vivo y tarifas reemplazaron las proyecciones. Las primeras señales coincidieron en gran medida con las expectativas de los desarrolladores, aunque algunos resultados sorprendieron a los observadores que seguían el precio del gas de Ethereum y los mercados de blobs en las semanas siguientes.

Los dos forks BPO triplicaron la capacidad máxima de blobs en aproximadamente un mes, dando a los rollups mucho más espacio para publicar lotes. Las tarifas de Layer 2 en las principales redes se mantuvieron muy por debajo de un centavo para las transacciones típicas, y los analistas señalaron reducciones adicionales a medida que la capacidad continuaba escalando hacia el objetivo a largo plazo de 128 blobs.

Un resultado contraintuitivo destacó. El suelo de tarifas de blobs de EIP-7918 hizo que las tarifas base de los blobs aumentaran drásticamente desde sus niveles anteriores cercanos a cero, ya que la publicación de datos ya no era efectivamente gratuita. Los costos de L2 se mantuvieron bajos de todos modos, porque el suelo de tarifas principalmente restauró una señal de precio funcional en lugar de hacer que el blobspace fuera realmente caro para los rollups.

Fusaka y ETH: Rendimiento del precio desde el lanzamiento

Fusaka se activó con una breve oferta, con ETH cerca de los $3,200 el día del lanzamiento, un aumento de aproximadamente el 4% mientras el fork se finalizaba en medio del optimismo por los recortes de tasas de la Fed y mínimos de varios años en las reservas de intercambio. Esa fortaleza se mantuvo solo hasta principios de enero, cuando ETH aún rondaba los $3,000 antes de que las condiciones generales tomaran el control.

La caída se profundizó entonces. ETH cayó por debajo de los $1,800 para febrero de 2026 a medida que convergieron los temores de recesión, la venta de ETH por parte del cofundador Vitalik Buterin y las persistentes salidas de ETF spot. Los repuntes de primavera hacia los $2,350 en marzo y los $2,100 en abril fueron cada uno objeto de venta, y un movimiento de aversión al riesgo en junio empujó el precio cerca de los $1,570.

El panorama acumulado es aleccionador. ETH cotiza alrededor de $1,774 a principios de julio, una caída de aproximadamente el 45% desde el lanzamiento, y ha registrado sus primeras tres velas trimestrales rojas consecutivas en la historia. Fusaka superó importantes objeciones técnicas, sin embargo, el precio se movió en la dirección opuesta durante los siete meses siguientes.

Esa desconexión capta la cuestión de la acumulación de valor que pesa sobre ETH. Un blockspace más barato y abundante no eleva automáticamente la quema de tarifas de la capa base o el yield del staking cuando la demanda se mantiene débil, por lo tanto, Fusaka mejoró la calidad de la red más que su precio. Nada de esto es asesoramiento financiero, así que investigue por su cuenta antes de asignar.

Lo que Fusaka preparó a continuación

Fusaka nunca fue un punto final. Al implementar PeerDAS y el mecanismo BPO, proporcionó a los desarrolladores CORE una forma repetible de escalar la capacidad de datos y una base para el trabajo más ambicioso de la capa de ejecución que le sigue. La hoja de ruta después de Fusaka ya está tomando forma.

El sucesor inmediato es Glamsterdam, previsto para la segunda mitad de 2026, que se orienta hacia la escalabilidad de la propia Layer 1 a través de la separación consagrada de proponente-constructor y la parallel execution. Más allá del calendario de forks, Vitalik Buterin publicó una hoja de ruta de "Lean Ethereum" que cubre la seguridad cuántica, la privacidad y la escalabilidad a largo plazo hasta 2029.

Futuros forks BPO tienen como objetivo aumentar el número de blobs a 48 por bloque para mediados de 2026, continuando la escalabilidad incremental que Fusaka desbloqueó. Cada paso se suma al anterior, moviendo Ethereum constantemente hacia el rendimiento que su hoja de ruta centrada en rollups ha prometido durante mucho tiempo.

Consideraciones finales

Fusaka cumplió su promesa central: escaló la capa de datos de Ethereum sin comprometer la descentralización de la que dependen los operadores de nodos. PeerDAS se implementó sin problemas, la capacidad de blobs se triplicó en semanas, y la red absorbió los cambios con una interrupción mínima.

La pregunta más difícil es qué resultará de ello. Fusaka proporcionó a Ethereum la infraestructura para incorporar a la próxima ola de usuarios, pero la infraestructura por sí sola no garantiza que la actividad, las tarifas o el precio sigan. A medida que Glamsterdam y la hoja de ruta más amplia de 2026 se desarrollan, la capacidad de la red para convertir la capacidad técnica en valor duradero sigue siendo la historia que vale la pena observar.