El "cambio de marchas sin escalas" en la actualización Fusaka de Ethereum: establecer un mecanismo de respuesta rápida para la escalabilidad de L2

El futuro de Ethereum será como tener una "caja de cambios de transmisión continua", donde la expansión de Blob ya no estará atada a grandes actualizaciones de versión.

Autor: Zhixiong Pan

Contexto: La actualización del Gas Limit no requiere hard fork

Antes de la actualización Fusaka, la gran mayoría de los parámetros centrales en la capa de protocolo de Ethereum (como la recompensa de bloque, el algoritmo de ajuste de dificultad, etc.) estaban "codificados" en el software del cliente. Esto significaba que, incluso para modificar un solo valor, era necesario pasar por una larga propuesta EIP, pruebas en testnet y coordinar todos los nodos de la red para realizar un hard fork a gran escala, lo cual normalmente requería medio año o incluso más tiempo.

Antes de esto, la única excepción en el protocolo de Ethereum era el Block Gas Limit (límite de gas por bloque). El Gas Limit no se decide mediante hard fork, sino que permite a los validadores hacer pequeños ajustes algorítmicos al empaquetar bloques (por ejemplo, este año de 30M a 60M). Este mecanismo le da cierta flexibilidad a la red.

La aparición de EIP-7892, BPO (Blob Parameter Only), es precisamente para extender esta flexibilidad al ámbito de los datos. Convierte los parámetros clave de Blob en configuraciones y los activa mediante BPO, un "hard fork ligero que solo cambia parámetros y no código". Desde la perspectiva del desarrollo del cliente, es casi como una actualización en caliente de parámetros.

Esto permite que Ethereum, en términos de escalabilidad, se libere del ritmo de "tener que esperar al próximo gran hard fork cada vez que se quiera ajustar el número de Blobs", pudiendo ajustar los parámetros con mayor frecuencia a través de pequeños forks BPO.

¿Por qué es importante la cantidad de Blobs?

El objeto central de este ajuste es el Blob. Desde la actualización Cancun (Dencun), la mayoría de los Rollups ya no escriben la mayor parte de los datos de transacciones en el costoso calldata, sino que migraron a Blob, una "zona de montaje de datos temporales" especializada.

La lógica económica de Blob es muy simple: Blob es un recurso escaso, y la cantidad de Blobs que se pueden montar en cada bloque es limitada. Su precio proviene de la relación entre oferta y demanda; cuando la demanda de Layer 2 supera la oferta, el precio unitario de Blob aumenta, lo que encarece las comisiones de L2.

Por lo tanto, siempre que se garantice la seguridad, aumentar el límite superior de la cantidad de Blobs es la forma más directa de reducir los costos para los usuarios de L2.

Parámetros clave: el mecanismo de Target y Max

En el plan de ajuste de BPO, se pueden ver dos números que aparecen en pares (por ejemplo, 10/15). Estos son dos umbrales clave establecidos según el mecanismo de EIP-4844:

Target (valor objetivo): el "regulador" de las tarifas 

Este es el nivel de carga ideal establecido por Ethereum. El sistema ajusta dinámicamente la tarifa base (Base Fee) de Blob según este valor. Si el uso real > Target, la tarifa sube para frenar la demanda; si el uso real < Target, la tarifa baja.

Determina la capacidad de procesamiento y la tarifa base de la red en condiciones normales.

Max (valor máximo): el "fusible" de seguridad 

Este es el límite físico máximo establecido para evitar la caída de la red. Sin importar cuánta demanda haya, el protocolo estipula que la cantidad de Blobs en un solo bloque no puede superar este valor, para evitar que los nodos se caigan o desconecten por procesar demasiados datos.

Es el techo máximo de la capacidad de la red.

Además, desde Pectra, los parámetros de blob en mainnet básicamente siguen el patrón "Max = 1.5 × Target": 6/9, 10/15, 14/21, todos con esta proporción.

Hoja de ruta de la actualización: ¿Por qué Fusaka eligió un "enfoque por etapas"? 

Esta expansión no se realizó de una sola vez el 3 de diciembre (UTC+8), sino que adoptó una estrategia rigurosa de tres etapas: "primero desplegar la tecnología, luego liberar la capacidad".

Primera etapa: Lanzamiento de la actualización Fusaka (3 de diciembre (UTC+8))

Estado de los parámetros: Target: 6 / Max: 9 (igual que la versión anterior de Pectra, sin cambios).

La actualización Fusaka activó PeerDAS (muestreo de disponibilidad de datos), una tecnología central. Aunque técnicamente ya se puede manejar más datos, por seguridad, los desarrolladores decidieron no aumentar la carga de la red el primer día de la actualización. Es un "período de observación de seguridad" para verificar la estabilidad del mecanismo PeerDAS bajo el tráfico actual.

Segunda etapa: BPO 1 (previsto para el 9 de diciembre (UTC+8))

Ajuste de parámetros: Target: 10 / Max: 15

Después de que PeerDAS funcione de manera estable durante aproximadamente una semana, se realiza la primera actualización en caliente mediante el mecanismo BPO. El valor objetivo pasa de 6 a 10. Esta es la primera expansión sustancial durante el ciclo de Fusaka.

Tercera etapa: BPO 2 (previsto para el 7 de enero de 2026 (UTC+8))

Ajuste de parámetros: Target: 14 / Max: 21

Después de un mes de pruebas de estrés exhaustivas, se realiza la segunda actualización en caliente. En comparación con el lanzamiento de Fusaka, la capacidad se multiplica por 2,3 (6 → 14). Esto marca la implementación completa del plan de expansión.

Resumen

La introducción de BPO es un hito. Rompe con el antiguo paradigma de "cada expansión de Blob requiere esperar un gran hard fork funcional", dividiendo la expansión en una serie de mini hard forks que solo cambian parámetros.

Esto significa que el futuro de Ethereum será como tener una "caja de cambios de transmisión continua", donde la expansión de Blob ya no estará atada a grandes actualizaciones de versión. Se podrán planificar BPO3, BPO4 y más, según la demanda de L2 y el rendimiento del cliente, ajustando el rendimiento con pequeños hard forks frecuentes en lugar de esperar años para cada cambio.