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 "transmisión continuamente variable", lo que significa que la expansión de los Blobs ya no tendrá que estar atada a grandes actualizaciones de versión.
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.
Descargo de responsabilidad: El contenido de este artículo refleja únicamente la opinión del autor y no representa en modo alguno a la plataforma. Este artículo no se pretende servir de referencia para tomar decisiones de inversión.
También te puede gustar
El Departamento del Tesoro de EE.UU. amplió la recompra de bonos del Tesoro sin lograr el efecto esperado; el rendimiento de los bonos a 10 años subió al 4,95% y las tasas hipotecarias superaron el 7%.
El Departamento del Tesoro de EE.UU. realizó el jueves la primera recompra de bonos del Tesoro a largo plazo tras la ampliación anunciada por la secretaria Janet Yellen, pero el monto comprado fue menor al esperado por el mercado. Esto decepcionó a los inversores que esperaban que el Tesoro aumentara las recompras para aliviar la presión sobre las tasas de interés a largo plazo.
Los ingresos y beneficios de Adobe en el tercer trimestre superaron las expectativas, la IA impulsó los usuarios mensuales activos a más de mil millones, la guía para el cuarto trimestre no es "sorprendente"｜Informe de resultados
Los ingresos de Adobe en el tercer trimestre fiscal alcanzaron 6.76 mil millones de dólares, un aumento interanual del 13%, superando la expectativa promedio de los analistas de 6.7 mil millones de dólares. Las ganancias por acción ajustadas según el criterio no GAAP fueron de 6.13 dólares, por encima de la previsión del mercado de 6.08 dólares. La empresa elevó el rango de guía de EPS ajustado anual a entre 24.45 y 24.50 dólares y aumentó ligeramente el límite superior del objetivo de ingresos anual. Sin embargo, la guía de ingresos para el cuarto trimestre es ligeramente inferior a las expectativas de los analistas, lo que llevó a que el precio de las acciones cayera alrededor del 2% después del cierre del mercado.
Los hutíes toman control de un importante puerto en el Mar Rojo y el conflicto con Arabia Saudita se intensifica; Irán habría reanudado la producción de misiles balísticos y el petróleo sube más del 7% durante la sesión.
Un oficial del ejército gubernamental de Yemen afirmó que la ciudad portuaria estratégica de Al-Mokha en la provincia de Taiz, suroeste de Yemen, fue capturada por las fuerzas hutíes el jueves. Ese mismo día, los hutíes yemeníes declararon que Arabia Saudita realizó 64 ataques aéreos en varias regiones de Yemen en las últimas 24 horas; aseguraron que la navegación en el Mar Rojo "no está amenazada" y que sus acciones militares son defensivas. Expertos de la industria naviera señalaron que la toma de Al-Mokha permite a los hutíes avanzar aún más hacia el sur, “controlando casi por completo el estrecho de Bab el-Mandeb”, y que la pérdida de Al-Mokha “sin duda tendrá un impacto en la seguridad marítima de la región”.
SpaceX ajusta completamente el modelo de construcción de centros de datos de IA: expansión más lenta, mayor énfasis en la confiabilidad
Según informes de los medios, Elon Musk implementó una gran reestructuración en la gerencia de los centros de datos, poniendo a un veterano del área de cohetes al mando. El nuevo equipo directivo exige realizar pruebas más exhaustivas antes de poner en funcionamiento los centros de datos, añadiendo más sistemas de respaldo de energía y refrigeración, sacrificando la velocidad de construcción para lograr una mayor confiabilidad. El corte de energía ocurrido la semana pasada en el centro de datos de Memphis provocó la desconexión de algunos modelos Grok y generó un efecto en cadena que afectó a clientes de alquiler de computación como Anthropic y Google.
Precios de las criptos
Más
