Actualización de Glamsterdam, la solución de escalado L1 de Ethereum.

Original | Odaily Planet Daily jk

La próxima actualización Glamsterdam para Ethereum es considerada por los desarrolladores principales como la mayor reestructuración a nivel de protocolo desde The Merge. El nombre proviene de la combinación de dos partes: la actualización de la capa de ejecución conserva "Amsterdam", en referencia a la ubicación de eventos anteriores de Devconnect; la actualización de la capa de consenso se llama "Gloas", en honor a una estrella. Tras la actualización Fusaka, Glamsterdam mejora la escalabilidad de la capa 1 al reorganizar la forma en que la red procesa las transacciones y gestiona su creciente base de datos, actualizando fundamentalmente la manera en que Ethereum crea y verifica bloques.

Esta actualización gira en torno a tres objetivos principales:

• Procesamiento acelerado (paralelización): Consiste en reorganizar la forma en que la red registra las dependencias de los datos, lo que le permite procesar de forma segura un gran número de transacciones simultáneamente, en lugar de procesarlas lentamente una por una.
• Escalabilidad: Al dividir la pesada carga de trabajo de creación y verificación de bloques, se le da a la red más tiempo para propagar mayores cantidades de datos sin ralentizarse.
• Sostenibilidad: Ajustar las tarifas de red para que reflejen con precisión los costes de hardware a largo plazo para el almacenamiento de nuevos datos, eliminando los obstáculos para futuros aumentos en los límites de gas y evitando al mismo tiempo la degradación del rendimiento del hardware.

Las dos propuestas principales de la actualización se centran en la capa de consenso y la capa de ejecución:

Existen dos propuestas principales para Headliner. Fuente: Ethereum

Propuesta principal número uno: ePBS, transformando a los "intermediarios subcontratados" en "reglas integradas".

En primer lugar, analicemos la propuesta principal para la capa de consenso, que separa a los proponentes y a los constructores dentro del protocolo, abreviada en inglés como ePBS (EIP-7732).

Cada vez que Ethereum genera un bloque, el proceso consta de dos pasos: una persona se encarga de seleccionar el bloque (el proponente) y otra de ensamblar las transacciones (el constructor). Actualmente, esta división del trabajo no está especificada en el protocolo Ethereum, sino que depende de un grupo de empresas intermediarias externas (conocidas como relés) para facilitar el proceso. Esta relación externa también crea una ruta durante la verificación del bloque, lo que obliga a los validadores a completar rápidamente la transmisión y ejecución de transacciones en un ajustado lapso de 2 segundos, limitando la cantidad de datos que la red puede procesar. Por ejemplo, esto es similar a un restaurante donde los procesos de pedido y preparación dependen de un intermediario externo para coordinar la entrega de los platos; si este intermediario falla, la cocina y la recepción podrían no estar coordinadas.

ePBS integra esta división del trabajo de "pedido y preparación" en el manual operativo del restaurante, eliminando la necesidad de intermediarios externos. Como resultado, el protocolo incorpora directamente un mecanismo de pago y entrega en cadena de bloques de confianza, eliminando la necesidad de middleware de terceros. Sin embargo, si ambas partes desean utilizar funciones complejas aún no especificadas en el protocolo, pueden optar por recurrir a intermediarios externos. Además, para evitar problemas durante la fase de "entrega", ePBS ha establecido un "equipo de verificación de platos" para comprobar "quién realizó el pedido" y "si el plato se preparó a tiempo", ampliando así el tiempo de entrega original de 2 segundos a unos 9 segundos. Esto permite al restaurante gestionar más pedidos simultáneamente, lo que significa que Ethereum puede albergar más datos destinados a la Capa 2.

Segunda propuesta destacada: Los asistentes de vuelo preparan una "lista de compras" antes de partir.

A continuación, vamos a analizar la propuesta principal para la capa de ejecución, que es una lista de acceso a nivel de bloque, abreviada como BAL (EIP-7928).

Actualmente, el procesamiento de transacciones en Ethereum es similar al de una persona que compra en un supermercado a ciegas: primero debe tantear el producto, confirmar qué es y luego decidir cómo proceder, lo que la obliga a procesar los artículos uno por uno. Dado que el sistema desconoce de antemano qué datos utilizará una transacción, como las cuentas involucradas, debe procesarlas estrictamente en orden; de lo contrario, dos transacciones podrían intentar modificar inadvertidamente los mismos datos (como el saldo de una misma dirección), lo que provocaría conflictos.

Las listas de acceso a la compra (BAL) permiten a esta persona obtener una lista que indica claramente "a qué estantes dirigirse y qué artículos recoger" antes de salir. Con esta lista, el sistema puede prever qué transacciones no se superpondrán, lo que permite agrupar y procesar en paralelo las transacciones no relacionadas en lugar de ponerlas en cola una por una. Esta lista también ofrece una ventaja adicional: cuando nuevos nodos se unen a la red, pueden copiar directamente los resultados finales registrados en ella sin tener que recalcular todas las complejas transacciones históricas, lo que acelera significativamente el proceso de sincronización para los nuevos nodos. Para facilitar la circulación de esta lista dentro de la red, Glamsterdam también ha incluido una actualización del protocolo de transmisión que permite a los nodos compartir estas listas de acceso, lo que ahora es un requisito obligatorio para todos los clientes de la capa de ejecución.

Propuestas de apoyo: Reevaluación de las operaciones que ocupan espacio.

Además de estas dos propuestas principales, Glamsterdam también ha presentado dos propuestas complementarias para la revisión de precios, que pueden entenderse como un ajuste de la lista de precios de las "tarifas de almacenamiento" y las "tarifas de consulta" de la red.

• La primera propuesta aborda operaciones como la creación de nuevas cuentas y la implementación de contratos que ocuparán espacio de forma permanente en la red. Anteriormente, las tarifas cobradas no eran proporcionales al espacio ocupado; ahora se recalcularán en función del cobro por unidad de espacio, con el objetivo de controlar el crecimiento general de datos de la red a un nivel seguro y predecible de 120 GiB al año, garantizando así su funcionamiento con hardware convencional. Además, esta tarifa de almacenamiento se contabilizará por separado, sin mezclarse con las tarifas de procesamiento de transacciones. Si los desarrolladores están dispuestos a pagar un poco más en concepto de tarifas de almacenamiento, podrán seguir implementando aplicaciones más grandes y complejas sin verse limitados de inmediato por el límite general de Gas.
• La segunda propuesta aborda operaciones como la consulta y la lectura de datos existentes en la red, que anteriormente tenían precios demasiado bajos y no se ajustaban al aumento real del volumen de datos. En esta ocasión, se elevarán los precios de estos códigos de operación para reflejar mejor las condiciones de carga reales del hardware moderno, evitando además que algunos usuarios se aprovechen de las bajas tarifas para saturar la red con un número excesivo de consultas.

Fecha de lanzamiento de la red principal: Aún no determinada

En cuanto al cronograma, Glamsterdam se encuentra actualmente en una fase bastante delicada. Oficialmente, la reunión más reciente verificable de todos los desarrolladores principales de la capa de ejecución (ACDE) fue la número 241, celebrada el 16 de julio, cuyo orden del día principal incluyó actualizaciones sobre la fase de Glamsterdam Devnet y la selección de las propuestas principales para la próxima actualización, Hegota. Un cronograma ampliamente citado en la industria indicó que la fase de Devnet pasó por ocho iteraciones, de la 0 a la 7, desde el 28 de marzo de 2026 hasta el 8 de julio, seguida de la bifurcación de la red de prueba Sepolia, originalmente programada para el 3 de agosto de 2026, y la bifurcación de la red de prueba Hoodi, originalmente programada para el 17 de agosto de 2026, con la fecha objetivo para la activación de la red principal fijada para el 16 de septiembre de 2026.

El calendario original estaba previsto para la primera mitad de 2026. Fuente: Ethereum

Sin embargo, según los últimos acontecimientos, es probable que este calendario se haya pospuesto. El equipo de EthPandaOps lanzó recientemente una nueva red de prueba llamada Plataberget, la primera red de prueba pública a corto plazo diseñada específicamente para Glamsterdam. Se espera que los despliegues oficiales de Sepolia y Hoodi se retrasen hasta septiembre, y el lanzamiento de la red principal se ha pospuesto al cuarto trimestre de 2026. Esta es la segunda vez que se retrasa el calendario de Glamsterdam, tras el aplazamiento anterior desde la primera mitad de 2026, prevista inicialmente. Los desarrolladores principales han insistido repetidamente en que la correcta actualización tiene prioridad sobre el cumplimiento de cualquier fecha específica, por lo que, hasta que se defina la altura del bloque durante la reunión formal de la ACD, es posible que no veamos esta actualización hasta el cuarto trimestre o incluso a finales de año.