Ethereum realiza la actualización "Fusaka", continúa con la "escalabilidad y mejora de eficiencia", y refuerza la capacidad de liquidación en cadena.

Ethereum ha activado la actualización clave "Fusaka", que aumenta la capacidad de datos de Layer-2 en 8 veces mediante la tecnología PeerDAS, y combina el mecanismo de bifurcación BPO y el mecanismo de precio base de Blob, lo que promete reducir significativamente los costes operativos de Layer-2 y garantizar la sostenibilidad económica a largo plazo de la red.

Redactado por: Ye Huiwen

Fuente: Wallstreetcn

Ethereum está llevando a cabo hoy una actualización de red clave llamada "Fusaka", que representa otro hito importante en su hoja de ruta de expansión continua. Esta actualización tiene como objetivo aumentar significativamente la capacidad de datos y optimizar la eficiencia del protocolo, reduciendo aún más los costes de transacción en las redes Layer-2 y consolidando la posición central de Ethereum como capa de liquidación global eficiente.

Según lo previsto, la actualización Fusaka se activará el 3 de diciembre de 2025 en la altura de bloque 13,164,544. Esto marca un nuevo paso en el camino de expansión de Ethereum tras las actualizaciones Dencun y Pectra. Kenny Lee, jefe de criptoactivos de Goldman Sachs, señaló que Fusaka representa la siguiente etapa en la hoja de ruta de escalabilidad de Ethereum, cuyo objetivo es impulsar la evolución de la red hacia una capa de liquidación global con impacto y eficiencia de costes.

El cambio más importante de esta actualización es la introducción de la tecnología "PeerDAS" (Peer Data Availability Sampling, muestreo de disponibilidad de datos entre pares). Esta función pretende aumentar teóricamente en 8 veces la capacidad de datos de las redes Layer-2, permitiendo así un mayor rendimiento de transacciones y reduciendo significativamente las comisiones para los usuarios de Layer-2.

Además, la actualización Fusaka incluye la introducción del mecanismo de bifurcación "Blob Parameter Only" (BPO), que permite una mayor flexibilidad para futuras ampliaciones de capacidad de la red; al mismo tiempo, optimiza el rendimiento de la mainnet Layer-1 mediante funciones como la expiración del almacenamiento y el control de bloques, y mejora las funciones de las wallets y la experiencia del usuario. Estos cambios constituyen un salto estructural en la escalabilidad, sostenibilidad y operatividad de Ethereum.

De Dencun a Fusaka: centrados en la expansión y la optimización de la infraestructura

La actualización Fusaka es en realidad la activación simultánea de la actualización "Fulu" en la capa de consenso y la actualización "Osaka" en la capa de ejecución. Según el plan final confirmado por la Ethereum Foundation, las propuestas de mejora de Ethereum (EIPs) incluidas en la actualización se centran principalmente en tres áreas:

• Mejorar la eficiencia de Layer-1: Incluye la expiración del almacenamiento (EIP-7642) y el límite de gas de transacción (EIP-7825), con el objetivo de mantener la eficiencia de los nodos a medida que crece el uso de la red.
• Expandir la capacidad de datos de Layer-2: El núcleo es PeerDAS (EIP-7594), complementado por la actualización de parámetros de Blob (EIP-7892) y la optimización de tarifas de Blob (EIP-7918).
• Mejorar la experiencia del usuario y las herramientas para desarrolladores: Incluye la previsión determinista de proponentes (EIP-7917) y la precompilación para el soporte de la curva secp256r1 (EIP-7951), para mejorar las funciones de las wallets y el desarrollo de aplicaciones.

Estas tres direcciones coinciden plenamente con las prioridades estratégicas establecidas por la Ethereum Foundation en abril de 2025 (expandir la mainnet de Ethereum, expandir los Blobs, mejorar la experiencia del usuario). Este artículo se centrará en el aumento de la capacidad de datos de Layer-2 y la optimización del mecanismo de tarifas.

Misión central: el camino de la expansión centrada en L2

Para entender por qué Ethereum se centra en la expansión a través de Layer-2, es necesario revisar su filosofía de diseño.

En el "trilema de la blockchain" (es decir, la imposibilidad de lograr simultáneamente descentralización, seguridad y escalabilidad), Ethereum priorizó en sus inicios la descentralización y seguridad de su capa base (Layer-1). Esto llevó a que, con el aumento de la demanda de aplicaciones descentralizadas, Layer-1 experimentara cuellos de botella en forma de altas comisiones de transacción y tiempos de confirmación lentos.

Para resolver este problema, Ethereum adoptó una hoja de ruta "centrada en los Rollups". Esta estrategia transfiere la mayor parte del procesamiento de transacciones a las redes Layer-2, donde las transacciones se ejecutan off-chain y los datos comprimidos se publican de nuevo en Ethereum Layer-1 para la liquidación final y la garantía de seguridad.

Este enfoque modular permite a Ethereum lograr escalabilidad sin sacrificar sus principios fundamentales de descentralización. Sin embargo, esto también plantea un nuevo problema de "disponibilidad de datos": cómo demostrar a toda la red que los datos comprimidos publicados son válidos, sin que cada nodo tenga que descargar todos los datos.

PeerDAS: la clave para multiplicar por 8 la capacidad de datos

La función más influyente de la actualización Fusaka, PeerDAS, nace precisamente para resolver el problema de disponibilidad de datos mencionado anteriormente.

Antes de Fusaka, aunque la actualización Dencun introdujo los "Blobs" como una forma eficiente de almacenamiento de datos para Layer-2, cada nodo completo de Ethereum aún tenía que descargar todos los datos de Blob, lo que limitaba el ancho de banda y el rendimiento máximo de la red.

PeerDAS cambia fundamentalmente este modelo. Tras la actualización, la red divide los datos de Blob en fragmentos pequeños y los distribuye entre diferentes nodos. Cada nodo solo necesita descargar y verificar una pequeña parte del total de datos (alrededor de 1/8), y mediante métodos criptográficos puede garantizar la disponibilidad e integridad de todo el conjunto de datos. Este mecanismo reduce drásticamente los requisitos de recursos de cada nodo, lo que permite un aumento teórico de aproximadamente 8 veces en la capacidad de datos de la red. PeerDAS sienta las bases para futuras ampliaciones de Blob y es el motor clave para reducir los costes de transacción en Layer-2.

Bifurcación BPO: aumentar el límite de Blob de forma más flexible

Con el crecimiento continuo de la actividad de transacciones en Layer-2 (ver imagen dos), la demanda de espacio de Blob también está aumentando.

Según datos de Coinmetrics, el número diario de Blobs muestra una tendencia al alza. Sin embargo, bajo el mecanismo actual, aumentar el número de Blobs por bloque requiere una compleja "hard fork", una actualización importante que es difícil de coordinar y poco frecuente.

Para resolver este cuello de botella, Fusaka introduce el mecanismo de bifurcación "Blob Parameter Only" (BPO). Se trata de una bifurcación ligera y especializada, utilizada únicamente para actualizar parámetros relacionados con los Blobs (como el número máximo de Blobs por bloque). Debido a su alcance limitado y su impacto controlado, los equipos de desarrollo pueden implementar este tipo de actualizaciones con mayor frecuencia y seguridad, permitiendo a la red aumentar progresivamente su capacidad de datos sin tener que esperar a grandes actualizaciones con otras funciones. Según la Ethereum Foundation, las bifurcaciones BPO estarán programadas de antemano para duplicar el número de Blobs en fases durante varias semanas, hasta alcanzar el máximo.

Mercado de tarifas estable: introducción del mecanismo de precio base de Blob

Tras la actualización Dencun, las Layer-2 que publican datos en Ethereum se enfrentan a dos tipos de tarifas independientes: ejecución de Gas y Blob Gas. Cuando la demanda de Blobs es baja, su tarifa puede acercarse a cero, pero Layer-2 aún debe pagar una tarifa de ejecución de Gas que puede ser considerable. Esta "señal de precios defectuosa" conduce a una baja eficiencia en la fijación de precios y a la inestabilidad del mercado.

Para resolver este problema, Fusaka introduce mediante la EIP-7918 un mecanismo de "precio base" para los Blobs. Este precio base no es un valor fijo, sino que está vinculado dinámicamente a la tarifa de ejecución de Gas.

Cuando la tarifa de Blob impulsada por el mercado cae por debajo de este precio base, el algoritmo de ajuste de tarifas impide que siga bajando. El objetivo es garantizar que la tarifa de Blob siempre refleje su valor económico, que el mercado de tarifas siga siendo sensible a la congestión de la red y que Layer-2 disponga de un entorno de precios más estable y predecible.

Impacto en el mercado y riesgos potenciales

Se espera que la actualización Fusaka tenga un profundo impacto en el mercado. El aumento de la capacidad de datos gracias a PeerDAS y la bifurcación BPO promete reducir aún más los costes operativos de Layer-2. Al mismo tiempo, el mecanismo de precio base de la EIP-7918 garantiza que el espacio de Blob no se utilice de forma irrazonablemente barata, manteniendo la sostenibilidad económica de la red. Esto podría intensificar la competencia entre las redes Layer-2, desplazando el foco de la competencia de los costes de transacción hacia la experiencia del usuario, la colaboración en el ecosistema y la profundidad de la liquidez.

Sin embargo, esta actualización también conlleva algunos riesgos y consideraciones:

• Riesgo de ejecución: cualquier hard fork importante conlleva el riesgo de fallos de coordinación entre clientes o aparición de vulnerabilidades, lo que podría causar inestabilidad temporal en la red.
• Impacto limitado en las tarifas de la mainnet: los beneficios directos de la actualización se concentran principalmente en Layer-2, por lo que las tarifas de Gas de la mainnet de Ethereum pueden no bajar inmediatamente a corto plazo.
• Requisitos de hardware: aunque PeerDAS optimiza la eficiencia, un objetivo de Blob más alto podría aumentar con el tiempo la demanda de ancho de banda para los validadores.
• Retraso en la adaptación del ecosistema: las Layer-2 y los desarrolladores de dApps necesitarán tiempo para aprovechar plenamente las ventajas de la nueva arquitectura.