La próxima gran actualización de Ethereum ya está en la fase final.
Según la hoja de ruta oficial actual de Ethereum, la actualización Glamsterdam está programada para lanzarse en la red principal en la segunda mitad de 2026. A finales de junio, también entró en la fase final de pruebas en la red de desarrolladores. Actualmente se están probando continuamente funciones centrales como PBS integrado, listas de acceso a nivel de bloque y repreciación del Gas en redes de desarrollo multicliente, aunque el momento exacto de activación aún no se ha determinado finalmente.
Mientras tanto, en las principales redes sociales, la narrativa más comentada es, sin duda, la de "la red principal alcanzando 10000 TPS" tras la actualización. Pero más allá de esto, esta actualización reestructura profundamente la cadena de producción de bloques y el motor de ejecución de Ethereum. Los cambios son tan profundos y de tan amplio alcance que la comunidad de desarrolladores la ha calificado como "la actualización más grande desde The Merge (la Fusión de Ethereum)".
Entonces, ¿qué cambia exactamente esta actualización llamada "Glamsterdam" (combinación de la actualización de la capa de consenso "Gloas" y la actualización de la capa de ejecución "Amsterdam"), que suena bastante impresionante? ¿Cómo se despedirá de los problemas del pasado y qué cambios revolucionarios traerá a nuestra experiencia diaria en cadena?
1. ¿Por qué es "la mayor actualización desde The Merge"?
Si las actualizaciones anteriores Dencun y Fusaka prepararon principalmente el terreno para la disponibilidad de datos (Blob) de L2, entonces Glamsterdam vuelve a centrarse en L1, iniciando una gran reforma del rendimiento y la arquitectura de L1.
Esta es también la expresión subyacente más genuina del actual deseo de Ethereum de "hacer que L1 vuelva a ser grande": cómo hacer que L1 admita más transacciones, sin que aumenten simultáneamente el costo de ejecutar nodos y el riesgo de centralización de la red.
Sin embargo, para el usuario común, las actualizaciones de Ethereum suelen simplificarse a una pregunta muy directa: ¿el Gas será más barato? ¿El rendimiento será mayor? Pero, sinceramente, la próxima actualización Glamsterdam es difícil de resumir simplemente como "reducción de tarifas" o "escalado".
En general, esta actualización afecta múltiples aspectos clave de la capa base de Ethereum, incluyendo quién construye los bloques, cómo se ejecutan las transacciones, cómo los nodos leen y sincronizan el estado, y cuánto Gas deberían pagar las diferentes operaciones en cadena. Es equivalente a rediseñar el paradigma fundamental de cómo Ethereum produce y procesa bloques. Según los detalles técnicos divulgados hasta ahora, los cambios centrales más destacados se centran principalmente en tres aspectos:
- PBS integrado (ePBS): Reestructura la relación de juego entre proponentes y constructores de bloques, eliminando la dependencia de relés externos.
- Listas de acceso a nivel de bloque (BALs): Proporciona un mapa previo para la ejecución de transacciones, allanando el camino para el procesamiento en paralelo y una sincronización más rápida de nodos.
- Repreciación del Gas: Introduce un modelo de facturación de recursos más preciso para controlar la expansión del estado en entornos de alto rendimiento.
En primer lugar, para entender el PBS integrado, hay que saber que los bloques en Ethereum actualmente no son necesariamente enviados personalmente por el Proponente. Especialmente en la arquitectura actual de MEV-Boost, la mayoría de los Proponentes externalizan el trabajo de recopilar transacciones, ordenarlas y buscar ganancias de MEV a Constructores de Bloques profesionales, mientras que el Proponente se encarga principalmente de elegir, entre varios bloques candidatos, el que ofrezca el precio más alto para enviarlo a la red.
Esta división del trabajo, donde el "Constructor se encarga de ensamblar y el Proponente de enviar", es el PBS (Separación Proponente-Constructor).
El problema es que este mecanismo actual no está completamente codificado en el protocolo subyacente de Ethereum: el Proponente y el Constructor deben utilizar software de terceros fuera del protocolo y servicios de Relé MEV-Boost para completar la cotización del bloque, la entrega del contenido y el pago.
Esto significa que el Relé debe garantizar que el Constructor finalmente revele el bloque completo, y al mismo tiempo evitar que el Proponente, tras espiar previamente el contenido del bloque, se niegue a pagar ("robo"), asumiendo así el frágil y centralizado papel de "intermediario de confianza".
El ePBS (PBS Incorporado) propuesto por EIP-7732 pretende precisamente resolver este punto débil. Planea incorporar esta relación de juego directamente en el protocolo de consenso de Ethereum, eliminando directamente a los intermediarios de terceros, haciendo que el Constructor sea un participante reconocido de forma nativa por el protocolo. Primero envía un compromiso de bloque y una cotización, el protocolo bloquea automáticamente el pago correspondiente, y luego un "Comité de Oportunidad de la Carga Útil" juzga si el Constructor ha revelado la carga útil de ejecución a tiempo.
Esto permite separar parcialmente el proceso de manejo del bloque de consenso y la carga útil de ejecución, extendiendo la ventana de propagación y procesamiento de la carga útil de ejecución de aproximadamente 2 segundos a unos 9 segundos. Estos pocos segundos pueden parecer pocos, pero son clave para la escalabilidad de Ethereum: significa que los nodos dispondrán de más tiempo para recibir y procesar bloques más grandes y más datos Blob, creando así espacio para aumentar aún más el Límite de Gas.
En segundo lugar, otro avance central de Glamsterdam en la capa de ejecución son las Listas de Acceso a Nivel de Bloque (BALs, Block-Level Access Lists) propuestas por EIP-7928.
Como es sabido, actualmente los nodos de Ethereum, antes de recibir un bloque, no pueden saber directamente del bloque qué cuentas leerá cada transacción, qué almacenamiento de contratos accederá o qué estados modificará. Normalmente descubren estas dependencias de datos durante la ejecución de la transacción.
Es como entrar en un gran almacén para recoger mercancías sin una lista completa de ubicaciones. Los trabajadores deben buscar y procesar al mismo tiempo, por lo que, para evitar que dos personas modifiquen el mismo inventario simultáneamente, gran parte del trabajo debe completarse en un orden estrictamente fijo (un solo hilo en serie).
Las Listas de Acceso a Nivel de Bloque (BALs) equivalen a adjuntar un "mapa completo de acceso al estado" a cada bloque. En la cabecera del bloque, declara por adelantado qué direcciones y Slots de Almacenamiento alcanzará el conjunto de transacciones dentro de ese bloque, así como el resultado del estado después de la ejecución de las transacciones. Con este mapa, los nodos pueden determinar de un vistazo, antes de la ejecución, qué transacciones accederán a los mismos datos y cuáles no entrarán en conflicto:
Para las partes que no entren en conflicto, los nodos pueden leer previamente el estado relevante desde el disco y procesar en paralelo la verificación parcial de transacciones y el cálculo de la raíz del estado, sin tener que meter todo el trabajo en una única cola estrictamente serial. Además, dado que las BALs también registran los cambios de estado después de completar las transacciones, algunos nodos pueden utilizar estos resultados para reconstruir el estado durante la sincronización y puesta al día de la red, sin tener que ejecutar desde cero cada transacción del bloque en todos los escenarios (en mi opinión personal, tiene un sabor similar al concepto de fragmentación), haciendo que Ethereum se convierta en una blockchain de ejecución completamente paralela.
Por lo tanto, a largo plazo, esta es también la clave subyacente para que la red principal de Ethereum rompa su techo de rendimiento.
Finalmente, está la repreciación del Gas, que principalmente recalibra drásticamente la fijación del precio del Gas para múltiples operaciones en cadena mediante palancas económicas.
La razón es que el costo actual del Gas en Ethereum no se corresponde completamente con el consumo real de recursos que asumen los nodos. Por ejemplo, un cálculo complejo puro, una vez finalizada su ejecución, generalmente no deja una carga permanente significativa a los nodos. Pero crear una nueva cuenta, desplegar un contrato inteligente o escribir en una nueva ranura de almacenamiento genera datos que todos los nodos completos del mundo deben guardar permanentemente.
En el pasado, las tarifas de estos comportamientos de creación de estado no reflejaban completamente el costo de almacenamiento permanente que conllevan (explosión del estado). Si Ethereum mantuviera la fijación de precios original después de aumentar el Límite de Gas, más espacio de bloque podría convertirse rápidamente en datos de estado incontrolables, lo que finalmente sobrecargaría por completo el hardware de los nodos.
El EIP-8037, que ya se ha confirmado que formará parte de Glamsterdam, pretende reestructurar completamente estas reglas. Esto incluye la separación y contabilidad del cálculo y el estado, recalculando los costos según el volumen de nuevos datos de estado añadidos, separando el Gas de cálculo ordinario del Gas de estado; y también controlar la explosión del estado, haciendo que el costo de las operaciones para aplicaciones que crean muchas cuentas nuevas, despliegan contratos redundantes grandes o escriben frecuentemente en nuevo estado pueda aumentar, mientras que la estructura de tarifas será más atractiva para aplicaciones que consumen principalmente recursos de cálculo inmediatos y no aumentan continuamente el estado.
En esencia, la reforma del Gas de Glamsterdam no debe entenderse de manera simple y burda como una "reducción general de tarifas", sino como una aclaración de cuántos recursos de cálculo inmediato consume realmente una transacción y cuánta carga de almacenamiento a largo plazo deja en la red, y luego hacer que diferentes operaciones paguen de una manera más cercana al costo físico real.
En general, estas tres partes, aunque parecen independientes, apuntan en conjunto al mismo objetivo final: transformar por adelantado la infraestructura central subyacente para permitir que la red principal de Ethereum aumente aún más significativamente el Límite de Gas y la capacidad de procesamiento.
2. ¿Por qué no simplemente agrandar los bloques?
Muchos pueden preguntarse: si se quejan de que es lento y caro, ¿por qué no simplemente aumentar el Límite de Gas y duplicar directamente la capacidad del bloque?
Esta es una pregunta muy repetida. Teóricamente, la forma más directa de aumentar la capacidad de la red principal es, efectivamente, aumentar el límite máximo de Gas permitido por bloque, ya que un Límite de Gas más alto permite que un bloque contenga más transacciones y cálculos.
Pero el Límite de Gas no es un número que se pueda aumentar infinitamente. Si los bloques se agrandan ciegamente, se desencadena un efecto dominó: los nodos necesitan recibir más datos, ejecutar más transacciones y calcular nuevo estado en el mismo tiempo. Si la velocidad de procesamiento no sigue el ritmo, los nodos con configuraciones más débiles tendrán más dificultades para mantenerse al día, la propagación y verificación de bloques también pueden sufrir retrasos, aumentando finalmente el riesgo de bifurcaciones de red y centralización.
Al mismo tiempo, más transacciones significan más cuentas, contratos y datos de almacenamiento escritos permanentemente en la base de datos de Ethereum. Estos datos no desaparecen automáticamente al finalizar la transacción, sino que se acumulan continuamente en la base de datos de estado de Ethereum, causando una expansión más rápida del estado.
Por lo tanto, la escalabilidad de Ethereum no enfrenta un simple problema matemático, sino que necesita resolver simultáneamente tres problemas:
- Primero, cómo dejar a los nodos más tiempo para propagar y procesar bloques grandes.
- Segundo, cómo reducir los cuellos de botella de rendimiento causados por la ejecución secuencial de transacciones.
- Finalmente, cómo evitar que más espacio de bloque se convierta rápidamente en una expansión incontrolable del estado.
Esta es la lógica central de Glamsterdam: no es expandir ciegamente primero y luego dejar que los nodos lo aguanten, sino primero reestructurar la forma de producir bloques, ejecutar transacciones y fijar precios a los recursos, desatascar las tuberías desde la base, y luego abrir naturalmente la puerta para aumentar la capacidad de la red principal.
Entre ellas, ePBS, al reorganizar el proceso de manejo de bloques dentro de un Slot, deja a los nodos más tiempo para propagar y verificar bloques grandes; BALs, al proporcionar explícitamente las relaciones de acceso al estado, mejora la eficiencia de lectura, ejecución y sincronización del cliente; y la repreciación del Gas se encarga de limitar el crecimiento insostenible del estado.
En las pruebas de colaboración de Glamsterdam de abril de 2026, los desarrolladores centrales realizaron pruebas de estrés centradas en implementaciones multicliente y propusieron claramente un objetivo técnico de 200 millones de Gas como límite inferior de capacidad creíble después de la actualización. Detrás de este objetivo está precisamente el soporte subyacente conjunto proporcionado por ePBS, BALs y la repreciación del Gas de estado.
Por supuesto, 200 millones de Gas se acerca más a la capacidad de carga que el sistema tendrá después de la actualización y a la dirección en la que puede evolucionar en el futuro, y no significa que la red principal, el día de la activación de Glamsterdam, aumente inmediatamente el Límite de Gas a este nivel.
Lo verdaderamente importante es que Ethereum está pasando de una "expansión cautelosa y tentativa" del pasado a "prepararse por adelantado para una expansión más significativa de la red principal mediante la reestructuración de la base".
3. ¿Qué impacto tendrá en los usuarios comunes y el ecosistema de Ethereum?
Desde la perspectiva del usuario común, la pregunta que más interesa sobre la actualización Glamsterdam sigue siendo si las tarifas de transacción bajarán.
En general, la respuesta se acerca más a "es probable que bajen y se vuelvan más estables", en lugar de que todas las transacciones se abaraten inmediatamente.
Dado que ePBS y las listas de acceso a nivel de bloque crean las condiciones para un Límite de Gas más alto, es previsible que la cantidad de transacciones que cada bloque pueda contener aumentará definitivamente. Por lo tanto, si la demanda en cadena no cambia, un aumento en la oferta de espacio de bloque naturalmente ayudará a aliviar la congestión y reducirá la probabilidad de que la Tarifa Base aumente repentinamente.
Pero para transacciones individuales, los cambios en diferentes operaciones pueden no ser uniformes. Por ejemplo, las transferencias simples de ETH podrían beneficiarse de la optimización del Gas base; y dado que las BALs informan por adelantado de las rutas de estado, la precisión de las carteras al estimar las tarifas de Gas mejorará enormemente. La mala experiencia pasada de transacciones fallidas debido a estimaciones de Gas inexactas por fluctuaciones del mercado, que aún así cobraban comisiones, pasará a la historia.
Sin embargo, las operaciones de despliegue de contratos, creación masiva de cuentas o escritura de grandes cantidades de nuevo estado podrían aumentar de costo debido a la repreciación del estado. Por lo tanto, el resultado más probable de Glamsterdam es una disminución en el costo de transacciones simples, tarifas más estables en períodos de congestión, y al mismo tiempo que las aplicaciones intensivas en estado comiencen a pagar un precio más preciso por los recursos de red que ocupan a largo plazo.
Para los usuarios que utilizan principalmente L2, esta actualización tampoco es irrelevante. ePBS extiende la ventana de propagación de datos de la carga útil de ejecución de unos 2 segundos a unos 9 segundos, lo que no solo puede soportar bloques de red principal más grandes, sino que también deja espacio para que Ethereum procese más datos Blob. Después de expandir aún más la capacidad Blob, los Rollups dispondrán de más espacio para enviar datos de transacciones, lo que a largo plazo ayudará a estabilizar los costos de datos de L2.
Además, para carteras, exchanges y puentes cruzados (cross-chain bridges), un cambio que los usuarios podrían percibir más fácilmente podría provenir del EIP-7708. Actualmente, las transferencias de tokens ERC-20 suelen generar registros (logs) estandarizados de Transfer, pero algunas transferencias nativas de ETH entre contratos inteligentes no dejan registros de eventos igualmente claros. Las carteras y plataformas de trading a menudo necesitan depender de herramientas de rastreo de transacciones internas adicionales para identificar estos movimientos de ETH.
El EIP-7708 requiere que las transferencias de ETH distintas de cero y las operaciones de destrucción de ETH generen registros estándar, permitiendo que carteras, exchanges y puentes identifiquen de manera más confiable los depósitos, retiros y movimientos internos de ETH dentro de los contratos. En el futuro, los registros de activos ETH que vean los usuarios podrían ser más completos, y algunas transferencias internas que antes requerían un rastreo complejo de transacciones para mostrarse también serán más fáciles de identificar directamente por las carteras.
Para operadores de nodos y usuarios que realizan staking, el impacto es más directo. Glamsterdam cambia simultáneamente la forma en que se manejan los bloques en la capa de ejecución y de consenso, por lo que los nodos y validadores necesitan actualizar a versiones de cliente compatibles con Glamsterdam antes de la activación en la red principal. Los usuarios comunes que poseen monedas no necesitan migrar ETH ni realizar ningún tipo de "actualización de activos" o "canje de tokens".
A más largo plazo, lo que Glamsterdam realmente afecta es cómo Ethereum vuelve a encontrar un equilibrio entre escalabilidad y descentralización. Después de todo, una vez aumentada la capacidad de los bloques, si el costo de hardware necesario para ejecutar un nodo también aumenta significativamente, aunque el rendimiento de la red principal sea mayor, la red podría depender cada vez más de grandes instituciones.
La combinación de ePBS, listas de acceso a nivel de bloque y repreciación del Gas de estado intenta formar otra ruta de escalabilidad: no es simplemente exigir a los nodos que procesen más trabajo en el mismo tiempo, sino reorganizar el flujo de producción de bloques, proporcionar información de dependencia de transacciones por adelantado, y hacer que diferentes recursos paguen según la carga real que asumen.
Esta es también la diferencia más fundamental entre Glamsterdam y un simple aumento del Límite de Gas: no intenta resolver todos los problemas de Ethereum con un solo EIP, sino que transforma simultáneamente tres conjuntos de mecanismos interrelacionados: producción de bloques, ejecución de transacciones y crecimiento del estado.
Al final
A largo plazo, lo que Glamsterdam afectará realmente de manera profunda es la dirección narrativa de cómo Ethereum vuelve a encontrar un equilibrio entre la "escalabilidad de alto rendimiento" y la "descentralización absoluta".
Esta es también la creciente familiaridad con el espíritu inicial o la inercia de Ethereum: frente a la presión constante de blockchains monolíticas de alto rendimiento, no opta por el camino simple y brusco de aumentar los requisitos de hardware, sino que elige un camino que intenta mantener el carácter descentralizado y la resiliencia subyacente. Al igual que esta vez, mediante la combinación de reescribir la cadena de producción de bloques (ePBS), proporcionar explícitamente por adelantado las dependencias de las transacciones (BALs) y hacer que diferentes recursos paguen con precisión según la carga física (repreciación del Gas), todo sigue siendo para, bajo la premisa de garantizar que las personas comunes puedan ejecutar nodos y participar en la validación, extraer a toda costa una capacidad de red principal más enorme.
Desde este punto de vista, cada tarifa de Gas económica que paguemos en el futuro, cada factura interna de ETH más precisa y clara en nuestra cartera, y cada espacio más amplio para la reducción de tarifas en L2, quizás se beneficiarán profundamente de estos cimientos que Glamsterdam volverá a colocar para Ethereum en la segunda mitad de 2026.
