Autor|jk
La próxima actualización Glamsterdam de Ethereum es, en opinión de los desarrolladores principales, la reestructuración de protocolo más extensa desde The Merge. Este nombre combina dos partes: la parte de actualización de la capa de ejecución mantiene "Amsterdam", tomada de la ciudad donde se celebraron anteriores ediciones de Devconnect; la parte de actualización de la capa de consenso se denomina "Gloas", nombre de una estrella. Siguiendo a la actualización Fusaka anterior, Glamsterdam avanza en la escalabilidad de L1 reorganizando la forma en que la red procesa transacciones y gestiona su creciente base de datos, actualizando fundamentalmente la forma en que Ethereum crea y valida bloques.
Esta actualización gira en torno a tres objetivos principales:
- Aceleración del procesamiento (paralelización): Reorganizar cómo la red registra las dependencias de datos para poder procesar de forma segura un gran volumen de transacciones simultáneamente, en lugar de hacerlo secuencial y lentamente.
- Escalabilidad: Dividir el trabajo pesado de creación y validación de bloques, dando a la red más tiempo para propagar volúmenes mayores de datos sin ralentizarse.
- Sostenibilidad: Ajustar las tarifas de la red para reflejar con precisión los costos a largo plazo del hardware para almacenar nuevos datos, allanando el camino para futuros aumentos del límite de Gas, evitando al mismo tiempo la degradación del rendimiento del hardware.
Las dos principales propuestas de la actualización se sitúan en la capa de consenso y en la capa de ejecución:

Hay dos propuestas principales (Headliner). Fuente: Ethereum
Propuesta principal 1: ePBS, convertir los "intermediarios externos" en "reglas integradas"
Primero, la propuesta principal de la capa de consenso: Separación del Proponente y el Constructor dentro del protocolo, abreviado en inglés como ePBS (EIP-7732).
Cada vez que Ethereum produce un bloque, en realidad hay dos pasos: una persona es responsable de "seleccionar qué bloque" (el Proponente), y otra persona es responsable de "ensamblar realmente las transacciones dentro del bloque" (el Constructor). Actualmente, esta división del trabajo no está regulada por el propio protocolo de Ethereum, sino que se realiza mediante un conjunto de "empresas intermediarias" (en jerga, relés) fuera de la cadena. Esta relación extra-cadena también crea una ruta durante la validación del bloque, obligando a los validadores a completar apresuradamente la difusión y ejecución de transacciones en una ventana ajustada de 2 segundos, lo que limita la cantidad de datos que la red puede manejar. Poniendo un símil, es como si en un restaurante los pasos de tomar pedidos y cocinar dependieran de un coordinador externo independiente para transmitir los platos; si ese coordinador falla, la cocina y la sala pueden perder la coordinación.
Lo que hace ePBS es integrar estas reglas de división del trabajo "pedido-preparación" directamente en el manual de operaciones interno del restaurante, dejando de depender de un coordinador externo. De esta manera, un mecanismo confiable de entrega y pago de bloques en cadena se construye directamente en el propio protocolo, eliminando así la necesidad de depender de intermediarios de terceros, aunque si ambas partes desean utilizar funciones complejas aún no reguladas en el protocolo, pueden optar por seguir utilizando intermediarios externos. Al mismo tiempo, para evitar el caos en la "transmisión de platos", ePBS establece específicamente un "grupo de verificación" que verifica por separado "quién hizo el pedido" y "si el plato se preparó y sirvió a tiempo", ampliando la ventana de tiempo de transmisión original de 2 segundos a aproximadamente 9 segundos, permitiendo al restaurante manejar más pedidos de una vez, es decir, permitiendo que Ethereum soporte más datos destinados a las Layer2.
Propuesta principal 2: BALs, hacer la "lista de la compra" antes de salir
Ahora, la propuesta principal de la capa de ejecución: Listas de Acceso a Nivel de Bloque, abreviado en inglés como BALs (EIP-7928).
La forma actual en que Ethereum procesa las transacciones es similar a una persona que va al supermercado con los ojos vendados: primero tiene que tocar un producto, confirmar qué es, y luego decidir cómo proceder, por lo que solo puede procesar uno por uno en fila. Debido a que no se sabe de antemano qué datos utilizará una transacción, como qué cuentas involucrará, el sistema debe procesar las transacciones estrictamente de forma secuencial y una por una. De lo contrario, dos transacciones podrían intentar modificar accidentalmente los mismos datos (como el saldo de la misma dirección) al mismo tiempo, causando conflictos y errores.
BALs equivalen a darle a esta persona, antes de salir, una "lista de la compra" que especifique claramente "a qué pasillos ir y qué artículos tomar". Con esta lista, el sistema puede ver de antemano qué transacciones no se "pelearán" entre sí en absoluto, y por lo tanto puede agrupar las transacciones no relacionadas en varios conjuntos y procesarlas en paralelo, en lugar de hacerlo una por una en fila. Esta lista tiene un beneficio adicional: cuando un nuevo nodo se une a la red, puede copiar directamente el resultado final registrado en esta lista, sin tener que recalcular todas las complejas transacciones históricas, lo que acelerará mucho la sincronización del nuevo nodo. Para que esta lista realmente circule en la red, Glamsterdam también incluye una actualización del protocolo de transmisión para permitir que los nodos compartan estas listas de acceso. Este protocolo de transmisión ahora es un requisito obligatorio para todos los clientes de la capa de ejecución.
Propuestas complementarias: Recalcular los costos de las operaciones que "ocupan espacio"
Además de estas dos propuestas principales, Glamsterdam incluye dos propuestas complementarias de re-precio, que pueden entenderse como ajustes en la "tarifa de almacenamiento" y la "tarifa de consulta" de la red.
- La primera es para operaciones que "ocupan espacio permanentemente" en la red, como la creación de nuevas cuentas o la implementación de contratos. Anteriormente, la tarifa no era proporcional al espacio real que ocupan. Ahora se cobrará según el principio de "pagar por el espacio que se ocupa", con el objetivo de controlar la tasa de crecimiento de datos de toda la red en un nivel seguro y predecible de unos 120 GiB anuales, asegurando que el hardware común pueda seguir ejecutando esta red. Además, esta tarifa de almacenamiento se contabilizará en una cuenta separada, sin mezclarse con los costos de computación del procesamiento de transacciones en sí. Siempre que los desarrolladores estén dispuestos a pagar un poco más por el almacenamiento, aún podrán implementar aplicaciones más grandes y complejas, sin verse limitados de golpe por el límite total de Gas.
- La segunda es para operaciones como consultar o leer datos existentes en la red, cuyo precio anterior era demasiado bajo y no se mantenía al día con los costos reales de consulta tras el aumento del volumen de datos. Esta vez se aumentará la tarifa de estos opcodes, acercando el precio a la carga real del hardware moderno, al mismo tiempo que se evita que alguien aproveche el bajo costo para bloquear la red intencionalmente con un gran volumen de solicitudes de consulta.
Tiempo de implementación en la red principal: Aún no se ha fijado
En cuanto al calendario, Glamsterdam se encuentra actualmente en una fase bastante delicada. A nivel oficial, la última reunión verificable de todos los desarrolladores principales de la capa de ejecución (ACDE) fue la número 241, el 16 de julio, con una agenda que incluía la presentación del último progreso en la fase Devnet de Glamsterdam y la votación para seleccionar las propuestas principales para la siguiente actualización, Hegota. Una programación ampliamente citada en la industria mostraba que la fase Devnet tuvo ocho iteraciones de la 0 a la 7, con un período comprendido entre el 28 de marzo y el 8 de julio de 2026, seguido de un hard fork planificado en la testnet Sepolia para el 3 de agosto de 2026, un hard fork en la testnet Hoodi para el 17 de agosto de 2026, y una fecha objetivo de activación en la red principal para el 16 de septiembre de 2026.

La programación original era para la primera mitad de 2026, Fuente: Ethereum
Sin embargo, según los últimos movimientos, es muy probable que esta programación se haya retrasado. El equipo de EthPandaOps lanzó recientemente una nueva testnet llamada Plataberget, la primera testnet pública de corta duración diseñada específicamente para Glamsterdam. Se espera que los despliegues formales en Sepolia y Hoodi se retrasen hasta septiembre, y el objetivo de implementación en la red principal se pospone correspondientemente al cuarto trimestre de 2026. Este es el segundo deslizamiento de fecha de Glamsterdam, después de su retraso previo desde la primera mitad de 2026. Los desarrolladores principales han enfatizado en múltiples ocasiones que la corrección de la actualización tiene prioridad sobre cumplir cualquier fecha específica. Por lo tanto, hasta que una reunión oficial de ACD fije una altura de bloque específica, es posible que tengamos que esperar hasta el cuarto trimestre o incluso finales de año para ver esta actualización.







