En Resumen

  • Ethereum se prepara para Fusaka, actualización Q4 2025 que ampliará capacidad de blobs, reforzará seguridad ante ataques y añadirá herramientas para desarrolladores y usuarios.
  • PeerDAS permitirá a nodos almacenar solo una fracción de los blobs, aumentando hasta ocho veces el rendimiento de datos sin exigir más hardware ni ancho de banda.
  • Fusaka incluye ajustes en precios de blobs, límites de gas y bloques, soporte de preconfirmación y verificación nativa de firmas P-256, mejorando escalabilidad y usabilidad de la red.

La próxima actualización importante para la red de Ethereum está en el horizonte. Llamada Fusaka—abreviatura de "Fulu-Osaka"—el lanzamiento está programado para el cuarto trimestre de 2025 y combinará cambios significativos tanto en las capas de ejecución como de consenso de Ethereum.

Fusaka sigue varios hitos para la red de Ethereum después de La Fusión o The Merge en 2022. Shanghai/Shapella en 2023 introdujo retiros de ETH en staking, Dencun en 2024 añadió proto-danksharding y blobs, y Pectra en 2025 trajo flexibilidad para validadores e interoperabilidad con Capa 2.

Según la hoja de ruta del proyecto, Fusaka está diseñada para expandir la capacidad de datos, reforzar las defensas contra ataques de denegación de servicio e introducir nuevas herramientas para desarrolladores y usuarios.

Los cambios son amplios. Fusaka no es un parche menor sino un rediseño de cómo Ethereum gestiona la disponibilidad de datos, el precio de los blobs y las salvaguardas de transacciones. Su éxito se medirá por si la red puede escalar para satisfacer la creciente demanda de Capa 2 sin fragmentarse o sobrecargar a los operadores de nodos.

PeerDAS: Muestreo en lugar de almacenar todo

La característica central de Fusaka es PeerDAS, abreviatura de "muestreo de disponibilidad de datos", una nueva forma de manejar los datos de blobs.

En Ethereum, un blob es un paquete de datos temporal introducido con proto-danksharding como parte de la actualización Dencun. Los blobs permiten a los rollups de Capa 2 publicar grandes cantidades de datos de transacciones en la red principal de manera económica, mejorando la escalabilidad sin inflar permanentemente el estado de la blockchain.

Esto asegura redundancia, pero crea un cuello de botella a medida que crece la demanda. En el modelo actual, cada nodo completo en Ethereum debe almacenar cada "blob" de datos de Capa 2 publicado en la cadena.

PeerDAS cambia la ecuación. Cada nodo almacenará solo una fracción de los datos de blobs—aproximadamente un octavo—y dependerá de la reconstrucción criptográfica para completar las piezas faltantes. El diseño se basa en muestreo aleatorio para verificar la disponibilidad de datos con probabilidades de error extremadamente bajas, del orden de una en 10²⁰ a 10²⁴.

Al distribuir el almacenamiento de esta manera, Ethereum puede, en teoría, soportar hasta ocho veces más rendimiento de blobs sin exigir mayor hardware o ancho de banda a los operadores de nodos. Los rollups, que dependen de los blobs para publicar datos de transacciones comprimidos, se espera que se beneficien más directamente.

Economía y flexibilidad de los blobs

Fusaka también remodela cómo se fijan los precios y se gestionan los datos de blobs.

Un cambio clave, EIP-7918, introduce una tarifa de reserva para los blobs. Bajo las reglas actuales, los precios de los blobs pueden caer cerca de cero cuando las tarifas de gas de ejecución dominan. Esto crea incentivos para un uso ineficiente. La tarifa de reserva asegura que el uso de blobs siempre conlleve un costo base, haciendo que las redes de Capa 2 paguen por el almacenamiento y ancho de banda que consumen.

Otro mecanismo, EIP-7892, introduce bifurcaciones de solo parámetros de blobs. Estos permiten a los clientes de Ethereum ajustar el rendimiento de blobs fuera de las bifurcaciones duras completas. El objetivo es dar a los desarrolladores la agilidad para responder a la demanda impredecible de Capa 2 sin esperar a la próxima actualización programada.

Protección contra ataques

Escalar también significa aumentar la superficie de ataque de Ethereum. Fusaka incluye una serie de cambios para limitar los escenarios en el peor de los casos y proteger la red de ataques de denegación de servicio:

  • EIP-7823: limita el tamaño de entrada para la operación MODEXP a 8.192 bits.
  • EIP-7825: establece un límite de gas por transacción de 2²⁴ unidades.
  • EIP-7883: aumenta los costos de gas para exponentes grandes en MODEXP para ajustarse mejor al esfuerzo computacional.
  • EIP-7934: limita el tamaño del bloque de ejecución a 10 MB.

En conjunto, estos cambios reducen el riesgo de que transacciones extremas o bloques de gran tamaño puedan sobrecargar a los clientes, detener la propagación o crear inestabilidad.

Nuevas herramientas para usuarios y desarrolladores

Fusaka también busca mejorar la usabilidad.

Para los usuarios, EIP-7917 introduce soporte de preconfirmación. Esto permite a las billeteras y aplicaciones anticipar el cronograma de proponentes, permitiendo a los usuarios asegurar que su transacción aparecerá en un próximo bloque. El resultado es menor latencia y menos incertidumbre sobre la inclusión.

Para los desarrolladores, Fusaka añade dos características notables:

  • Un opcode CLZ (contar ceros iniciales), útil para rutinas criptográficas y eficiencia de contratos.
  • EIP-7951, que proporciona verificación nativa de firma secp256r1 (P-256). Esta es una curva elíptica común utilizada en dispositivos de hardware y sistemas móviles, y su adición mejora la compatibilidad y la abstracción de cuentas.

Estos cambios están destinados a reducir la fricción para los desarrolladores de aplicaciones y allanar el camino para nuevos diseños de billeteras y modelos de seguridad.

Lo que los holders de ETH deben saber

Para los usuarios cotidianos de Ethereum, Fusaka no requiere ninguna acción. Los saldos de cuentas, tokens y aplicaciones continuarán funcionando como antes. Ethereum.org enfatiza que los usuarios deben ignorar estafas que les pidan "actualizar" ETH o transferir fondos—no existe tal requisito.

La responsabilidad recae en los validadores y operadores de nodos, quienes deben actualizar sus clientes de ejecución y consenso coordinadamente. La coordinación sigue siendo un proceso delicado: si los validadores se dessincronizan, la red corre el riesgo de tiempo de inactividad o divisiones temporales de la cadena.

Fusaka se activará en la testnet Holesky de Ethereum el 1 de octubre, seguida de Sepolia el 14 de octubre, Hoodi el 28 de octubre y el lanzamiento en la red principal el 3 de diciembre.

El futuro de Ethereum después de Fusaka

Fusaka representa uno de los pasos más audaces en la hoja de ruta de Ethereum desde La Fusión. Es un intento de ofrecer más capacidad de blobs, defensas más estrictas y nuevas herramientas para desarrolladores en un solo lanzamiento coordinado.

Las pruebas y ensayos en devnet están en marcha, con equipos de clientes enfocándose en el rendimiento de PeerDAS, modelos de precios de blobs y compatibilidad entre el software de ejecución y consenso. Si tiene éxito, Fusaka podría marcar un punto de inflexión en la capacidad de Ethereum para escalar ante la próxima ola de adopción de Capa 2.

Daily Debrief Newsletter

Start every day with the top news stories right now, plus original features, a podcast, videos and more.