Fusaka ya está en funcionamiento y el debate ha pasado de lo que haría a lo bien que se ha comportado. Activada siete meses después de Pectra, fue la segunda hard fork de Ethereum en 2025 y el intervalo más corto entre actualizaciones importantes desde que la red pasó a la prueba de participación.

La versión confirmó un cambio de ritmo. Los desarrolladores principales sustituyeron la antigua cadencia anual por bifurcaciones más ajustadas y frecuentes, y Fusaka fue la prueba de concepto. Esto es lo que se lanzó realmente, cómo respondió la red y qué implica para ETH de cara a 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 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», antigua ciudad anfitriona de Devcon, uniendo las capas de consenso y ejecución en una sola versión.

Fusaka se centró en la escalabilidad más que en funciones visibles para el usuario, a diferencia de la actualización Pectra que la precedió. Su cambio principal, PeerDAS (EIP-7594), reformuló la forma en que los nodos confirman que existen los datos de blobs de la capa 2, permitiéndoles muestrear fragmentos en lugar de almacenar cada byte. Esto sentó las bases del Danksharding completo.

La bifurcación agrupó unas doce propuestas de mejora de Ethereum, la mayoría heredadas de rondas de definición anteriores, con el foco en reforzar la Ethereum Virtual Machine y la capa de datos. En conjunto, situaron a Ethereum para dar servicio a rollups más rápidos y a aplicaciones con uso intensivo de datos sin llevar los requisitos de los nodos más allá del hardware de consumo.

Principales ventajas que aportó Fusaka

Fusaka dio prioridad a la salud de la red y a un escalado predecible frente a las funciones destacadas, reflejo de la cautela que marcó su alcance final. Los cambios transformaron la forma en que Ethereum gestiona cargas de datos más pesadas y cómo los validadores coordinan la producción de bloques en la red.

Entre las principales ventajas que introdujo Fusaka se incluyen las siguientes:

• Muestreo de blobs (PeerDAS): Reduce la presión sobre el ancho de banda y el almacenamiento de los nodos de consenso en aproximadamente un 85 %, y permite que los validadores verifiquen la disponibilidad de los 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 hacia 21 mediante forks escalonados, lo que amplía notablemente la capacidad de Layer 2 y reduce con el tiempo los costes de publicación de los rollups.
• Mayor límite de gas en L1: se elevó el límite de gas por bloque predeterminado a 60 millones mediante la EIP-7935, lo que da 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): se añadieron los forks Blob Parameter Only, actualizaciones ligeras que ajustan la configuración de los blobs sin necesidad de un hard fork completo cada vez que los desarrolladores quieren más capacidad.
• Proponentes predecibles (EIP-7917): habilitó una anticipación determinista del proponente, de modo que los validadores saben antes quién propondrá los próximos bloques, lo que ayuda a las preconfirmaciones y a la estabilidad del consenso.
• Firma nativa con passkeys (EIP-7951): añadió un precompilado secp256r1 que habilita firmas nativas del dispositivo mediante WebAuthn, FIDO2 y módulos de seguridad de hardware para un acceso más fluido a la wallet.

Fusaka, PeerDAS y la decisión sobre EOF, explicados

Dos componentes definieron el alcance de Fusaka: PeerDAS, que entró en la versión como función principal, y EOF, que los desarrolladores acabaron descartando. Entender ambos explica por qué la actualización final resultó más ajustada de lo que sugerían las primeras hojas de ruta.

¿Qué es PeerDAS en Fusaka?

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

Este diseño rompió el vínculo entre el rendimiento de los blobs y el coste del hardware del validador, lo que permitió a Ethereum escalar la capacidad de datos sin exigir máquinas de nivel empresarial. Los desarrolladores dieron menor prioridad a cualquier función que pudiera retrasar PeerDAS, ya que era el requisito previo para atender la demanda futura de rollup y de disponibilidad de datos, como explicamos en nuestra guía sobre EIP-4844.

Por qué se descartó EOF de Fusaka

EVM Object Format (EOF) pretendía reestructurar los contratos inteligentes trazando límites claros entre código, datos y metadatos, en sustitución del actual bytecode sin estructura. El plan agrupaba una docena aproximada de EIP coordinadas en la primera revisión profunda de la EVM desde su origen.

Los desarrolladores principales retiraron EOF de Fusaka tras una llamada de All Core Developers de abril de 2025, alegando complejidad sin resolver, riesgo de calendario y falta de consenso general. El responsable del protocolo, Tim Beiko, presentó el recorte como una forma de proteger PeerDAS, y dejó que los defensores de EOF defiendan su propuesta para una bifurcación posterior en lugar de forzarla.

Calendario de lanzamiento de Ethereum Fusaka

Fusaka llegó a mainnet según lo previsto tras superar tres testnets públicas durante octubre de 2025. Después, el despliegue continuó con dos forks que solo modificaban parámetros y que ampliaron la capacidad de blobs en pasos medidos en lugar de hacerlo de golpe, un enfoque deliberadamente cauto dada la novedad de la técnica de muestreo.

El despliegue de Fusaka se desarrolló a lo largo de estos hitos clave:

• testnet Holesky: Activada el 1 de octubre de 2025, para probar cambios de base, entre ellos el aumento del límite de gas y el rendimiento de los validadores con las nuevas reglas.
• testnet Sepolia: activada el 14 de octubre de 2025, centrada en el comportamiento de PeerDAS y en límites de gas más altos simulados en las distintas implementaciones de clientes.
• Testnet Hoodi: activada el 28 de octubre de 2025, fue el último ensayo de validadores sin permisos antes de que los desarrolladores confirmaran que la mainnet estaba lista.
• Activación en mainnet: Entró en funcionamiento el 3 de diciembre de 2025 en la época 411392 y se finalizó sin incidencias en unos quince minutos en todos los clientes principales.
• Fork BPO1: activado el 9 de diciembre de 2025, elevó el objetivo de blobs a 10 y el máximo a 15 por bloque.
• Fork BPO2: activado el 7 de enero de 2026, elevó 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 la capa 2, mejorar la eficiencia de ejecución de la capa 1 y perfeccionar la experiencia de desarrolladores y validadores. Según el anuncio de mainnet de la Ethereum Foundation y el seguimiento de Forkcast, estas fueron las propuestas que dieron forma a la versión.

Los EIP de Fusaka más relevantes por función son los siguientes:

• EIP-7594: Introdujo PeerDAS, el protocolo de muestreo que permite a los nodos de consenso verificar la disponibilidad de los blobs sin descargas completas, el eje de toda la actualización.
• EIP-7892: Habilitó los forks Blob Parameter Only, que permiten ajustes ligeros de los objetivos y máximos de blobs sin un hard fork coordinado completo.
• EIP-7935: fija el límite de gas por bloque predeterminado en 60 millones, estandarizando entre los clientes un valor 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 refuerzo contra ataques DoS que además sienta las bases para la ejecución en paralelo.
• EIP-7918: limitó la comisión base de los blobs según el coste de ejecución, evitando que los precios de los blobs se desplomen hasta 1 wei y conservando una señal de comisión significativa.
• EIP-7951: añadió un precompilado secp256r1 que permite verificar a bajo coste, on-chain, firmas de tipo passkey y respaldadas por hardware.
• EIP-7917: introdujo un lookahead determinista de proponentes, que permite a los rollups y a las aplicaciones anticipar los próximos proponentes de bloques para lograr una mejor secuenciación.
• EIP-7939: añadió el opcode CLZ (count leading zeros), que ofrece a los desarrolladores una instrucción nativa económica para cálculos a nivel de bits y utilidades criptográficas.

Varias propuestas más pequeñas completaron el paquete, entre ellas el par de reajustes de precios de ModExp (EIP-7823 y EIP-7883), el límite de tamaño de bloque RLP (EIP-7934) y mejoras del protocolo de red (EIP-7642). En su mayoría afinaron la economía del gas y la eficiencia de propagación a medida que crecía la capacidad de los bloques.

Cómo respondió la red tras el lanzamiento

La verdadera prueba de Fusaka llegó tras la activación, cuando los datos reales de uso de blobs y de comisiones sustituyeron a las proyecciones. Las primeras señales coincidieron en general con lo que esperaban los desarrolladores, aunque algunos resultados sorprendieron a los observadores que siguieron el precio del gas de Ethereum y los mercados de blobs en las semanas posteriores.

Las dos bifurcaciones BPO triplicaron la capacidad máxima de blobs en aproximadamente un mes, lo que da a los rollups bastante más margen para publicar lotes. Las comisiones de capa 2 en las redes principales se mantuvieron muy por debajo de un céntimo en las transacciones habituales, y los analistas señalaron nuevas reducciones a medida que la capacidad seguía escalando hacia el objetivo a largo plazo de 128 blobs.

Un resultado contraintuitivo destacó. El suelo de comisión de blobs del EIP-7918 hizo que las comisiones base de los blobs se dispararan desde sus niveles previos, cercanos a cero, ya que publicar datos dejó de ser prácticamente gratuito. Los costes de L2 se mantuvieron bajos de todos modos, porque el suelo de comisión restableció sobre todo una señal de precio útil, en lugar de encarecer de verdad el blobspace para los rollups.

Fusaka y ETH: rendimiento del precio desde el lanzamiento

Fusaka se activó con una breve subida, con ETH cerca de 3.200 $ el día del lanzamiento, con un avance aproximado del 4 %, mientras el fork se finalizaba en un contexto de optimismo por los recortes de tipos de la Fed y mínimos de varios años en las reservas de los exchanges. Esa fortaleza solo se mantuvo hasta principios de enero, cuando ETH aún rondaba por encima de 3.000 $ antes de que las condiciones generales tomaran el control.

Después la caída se profundizó. ETH cayó por debajo de 1.800 $ en febrero de 2026 al coincidir los temores de recesión, la venta de ETH por parte del cofundador Vitalik Buterin y las salidas persistentes de los ETF spot. Los repuntes primaverales hacia 2.350 $ en marzo y 2.100 $ en abril se encontraron con ventas, y un movimiento de aversión al riesgo en junio llevó el precio cerca de 1.570 $.

El panorama acumulado es desalentador. ETH cotiza en torno a 1.774 $ a principios de julio, aproximadamente 45 % por debajo de su nivel desde el lanzamiento, y ha registrado sus tres primeras velas trimestrales rojas consecutivas de la historia. Fusaka superó las principales objeciones técnicas, pero el precio se movió en sentido contrario durante los siete meses siguientes.

Esa desconexión resume la cuestión de la captura de valor que pesa sobre ETH. Un espacio en bloques más barato y abundante no aumenta automáticamente la quema de comisiones de la capa base ni el rendimiento del staking cuando la demanda sigue débil, así que Fusaka mejoró más la calidad de la red que su precio. Nada de esto es asesoramiento financiero, así que investiga por tu cuenta antes de invertir.

Qué preparó Fusaka para después

Fusaka nunca fue un punto final. Al implantar PeerDAS y el mecanismo BPO, dio a los desarrolladores principales una forma repetible de escalar la capacidad de datos y una base para el trabajo, más ambicioso, en la capa de ejecución que viene después. La hoja de ruta posterior a Fusaka ya va tomando forma.

El sucesor inmediato es Glamsterdam, previsto para la segunda mitad de 2026, que se orienta a escalar la propia capa 1 mediante la separación integrada entre proponente y constructor y la ejecución en paralelo. Más allá del calendario de forks, Vitalik Buterin publicó una hoja de ruta de «Lean Ethereum» que abarca seguridad cuántica, privacidad y escalabilidad a largo plazo hasta 2029.

Otros forks BPO buscan elevar el número de blobs hasta 48 por bloque a mediados de 2026, continuando el escalado gradual que habilitó Fusaka. Cada paso se suma al anterior y acerca de forma constante a Ethereum al rendimiento que su hoja de ruta centrada en rollup promete desde hace tiempo.

Conclusiones

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 desplegó sin problemas, la capacidad de blobs se triplicó en pocas semanas y la red absorbió los cambios con una interrupción mínima.

La cuestión más difícil es qué resultará de ello. Fusaka dio a Ethereum la infraestructura para incorporar a la próxima oleada de usuarios, pero la infraestructura por sí sola no garantiza que le sigan la actividad, las comisiones o el precio. A medida que avanzan Glamsterdam y la hoja de ruta más amplia de 2026, la capacidad de la red para convertir la capacidad técnica en valor duradero sigue siendo la historia que merece la pena vigilar.