Conclusiones clave
Glamsterdam es la próxima gran actualización de Ethereum, ahora prevista para el cuarto trimestre de 2026 tras los retrasos respecto al objetivo original de junio de 2026. No se ha confirmado ninguna fecha para mainnet.
La actualización se centra en tres objetivos: procesamiento paralelo de transacciones, mayor capacidad de bloque y reajuste del gas para evitar el crecimiento excesivo de la base de datos.
Sus propuestas clave son EIP-7732 (separación consagrada entre proponente y constructor), EIP-7928 (listas de acceso a nivel de bloque) y EIP-8037 (reajuste del gas).
Glamsterdam se activó en la testnet Sepolia el 6 de octubre de 2026, en una activación ampliamente reportada como exitosa.
Introducción
Glamsterdam es una importante actualización de Ethereum que originalmente estaba prevista para junio de 2026 y posteriormente se trasladó al tercer trimestre de 2026. A octubre de 2026, se espera para el cuarto trimestre de 2026, aunque no se ha anunciado una fecha confirmada de activación en mainnet. La cronología revisada refleja la necesidad de pruebas adicionales y trabajo de interoperabilidad entre los clientes de consenso y ejecución.
Glamsterdam se basa en el progreso de la actualización Fusaka de diciembre de 2025, que introdujo PeerDAS para mejorar la disponibilidad de datos. Mientras Fusaka se centró en refinamientos fundamentales, Glamsterdam busca escalar la capa base de Ethereum reorganizando cómo la red crea y verifica los bloques.
¿Qué es la actualización Glamsterdam?
Glamsterdam es una actualización combinada de la capa de ejecución y la capa de consenso. El nombre sigue la convención de Ethereum de combinar un nombre de ciudad para la capa de ejecución (“Amsterdam”) con un nombre de estrella para la capa de consenso (“Gloas”), dando como resultado “Glamsterdam”.
La actualización se centra en tres objetivos principales. Primero, acelerar el procesamiento mediante paralelización, permitiendo que la red procese muchas transacciones simultáneamente en lugar de una por una.
Segundo, ampliar la capacidad separando las tareas de creación y verificación de bloques para dar a la red más tiempo para propagar mayores cantidades de datos.
Tercero, evitar el crecimiento excesivo de la base de datos ajustando las tarifas para reflejar el coste de hardware a largo plazo de almacenar nuevos datos, lo que desbloquea futuros aumentos del límite de gas.
En resumen, Glamsterdam introduce cambios estructurales para asegurar que la red pueda seguir rindiendo bien y de forma sostenible mientras aumenta su capacidad.
Propuestas clave en Glamsterdam
Los cambios de Glamsterdam se definen mediante Propuestas de Mejora de Ethereum (EIPs), el mismo proceso que Ethereum utiliza para otras actualizaciones del protocolo. A continuación se describen las tres propuestas principales.
EIP-7732: Separación consagrada entre proponente y constructor (ePBS)
Actualmente, la relación entre los proponentes de bloques y los constructores de bloques no forma parte del protocolo central de Ethereum. Depende de middleware de terceros de confianza conocidos como relays, especialmente MEV-Boost, dentro del diseño más amplio de Separación entre Proponente y Constructor (PBS).
Este arreglo fuera del protocolo crea un cuello de botella: los validadores deben apresurarse a transmitir y ejecutar transacciones en una estrecha ventana de 2 segundos, lo que limita la cantidad de datos que la red puede manejar por bloque.
EIP-7732 separa formalmente el papel del proponente (quien selecciona el bloque de consenso) del constructor (quien ensambla el payload de ejecución), consagrando este traspaso directamente en el protocolo. Esto elimina la necesidad de middleware de terceros e introduce pagos a constructores sin confianza integrados en el propio protocolo.
Para abordar el cuello de botella de 2 segundos, ePBS introduce un Comité de Puntualidad del Payload (PTC) y una lógica de doble plazo. Los validadores pueden atestiguar por separado el bloque de consenso y el payload de ejecución, ampliando la ventana de propagación de 2 segundos a aproximadamente 9 segundos. Este tiempo adicional permite a Ethereum procesar de forma segura bloques mucho más grandes sin poner en tensión la red.
ePBS también tiene implicaciones para los pools de staking, que necesitarán actualizaciones arquitectónicas para permitir un monitoreo sin confianza. Sin embargo, la experiencia general de staking podría mejorar gracias a un proceso refinado de selección de constructores.
EIP-7928: Listas de acceso a nivel de bloque (BALs)
Hoy en día, Ethereum procesa las transacciones de forma secuencial. La red no sabe qué datos accederá o modificará una transacción hasta que esta se ejecuta, por lo que los validadores deben procesarlas una por una para evitar conflictos. Esto crea una carretera de un solo carril donde el rendimiento está limitado por la velocidad de la ejecución serial.
Las listas de acceso a nivel de bloque (BALs) cambian esto proporcionando un mapa anticipado de todas las dependencias de las transacciones. La capa de ejecución almacena una lista de acceso completa del bloque que detalla cada cuenta que las transacciones tocarán, junto con los resultados finales de esos cambios. El encabezado del bloque contiene una huella compacta de esta lista.
Con este mapa en su lugar, los validadores pueden procesar transacciones sin conflictos en paralelo en lugar de secuencialmente. Los nodos también pueden sincronizarse más rápido leyendo los resultados finales sin volver a ejecutar cada transacción, una función llamada sincronización sin ejecución. Las BALs sientan las bases para un aumento significativo del rendimiento en la Capa 1.
EIP-8037: Reajuste del gas
Un límite de gas más alto solo ayuda si la red puede manejar el crecimiento resultante del estado sin degradar el rendimiento. EIP-8037 introduce una tarificación más inteligente para el almacenamiento de datos al aumentar el coste de las operaciones que crean estado. El objetivo es hacer que la expansión del estado sea más cara mientras se mantiene la computación relativamente más barata.
EIP-8037 se combina con una propuesta relacionada, EIP-8038, que actualiza los costos de las operaciones de acceso al estado. Juntas, buscan alinear los costos del gas más estrechamente con los recursos que realmente gastan los operadores de nodos.
Este ajuste de precios del gas está diseñado para funcionar junto con el objetivo de 200 millones de gas. Sin él, un límite de gas más alto podría provocar un crecimiento excesivo del estado que haría cada vez más costoso ejecutar un nodo. Al alinear los costos del gas con la carga real de hardware a largo plazo de almacenar nuevos datos, EIP-8037 garantiza que los aumentos de capacidad sigan siendo sostenibles.
El objetivo de límite de 200 millones de gas
La Fundación Ethereum ha descrito un límite de 200 millones de gas como un “objetivo creíble posterior a Glamsterdam” para la red. Esto supondría un aumento significativo respecto al límite de gas actual de aproximadamente 60 millones. Sin embargo, la Fundación lo ha presentado como un objetivo de capacidad y no como una configuración garantizada desde el primer día de la actualización.
Un límite de 200 millones de gas formó parte de la prueba de Sepolia que comenzó el 6 de octubre de 2026, lo que proporcionó a los desarrolladores datos tempranos sobre cómo se comporta la red a esa escala. No ha sido confirmado como una configuración de mainnet.
El límite de gas determina cuánta computación puede caber en un solo bloque. Aumentarlo significa que se pueden procesar más transacciones y operaciones de contratos inteligentes por bloque, pero también implica que los bloques se vuelvan más grandes y más intensivos en recursos para validarlos. La combinación de ePBS, BALs y reajuste del gas en Glamsterdam está diseñada para que este aumento sea seguro y sostenible.
Cronología y estado actual
Como se mencionó, el objetivo original de Glamsterdam era junio de 2026. Posteriormente, la actualización se trasladó al tercer trimestre de 2026, y ahora se espera para el cuarto trimestre de 2026. No se ha anunciado ninguna fecha confirmada de activación en mainnet.
Las pruebas han avanzado a través de varias etapas. Los devnets para la actualización se ejecutaron durante 2025 y 2026, con pruebas de interoperabilidad en eventos de desarrolladores, incluido uno en Svalbard, Noruega. La primera activación pública en testnet tuvo lugar en la testnet Sepolia el 6 de octubre de 2026, y fue ampliamente reportada como exitosa. Los desarrolladores publicaron una actualización de última hora para el cliente Prysm poco antes de la activación para mantener la prueba según lo previsto.
A continuación, se espera que las pruebas se trasladen a la testnet Hoodi antes de decidir una fecha de activación en mainnet. El principal riesgo para la cronología sigue siendo un nuevo retraso si las pruebas revelan problemas adicionales, especialmente en torno a la implementación de ePBS y la coherencia entre clientes.
¿Qué viene después de Glamsterdam?
La siguiente gran actualización después de Glamsterdam se llama Hegotá, prevista para el segundo trimestre de 2027. Su alcance programado se centra actualmente en dos funciones: FOCIL (EIP-7805), que refuerza las salvaguardas contra la censura de transacciones, y las transacciones en marco (EIP-8141).
EIP-8141, conocida como Frame Transactions, introduciría abstracción de cuentas nativa al hacer que la verificación de transacciones sea programable, permitiendo a los usuarios elegir esquemas de firma poscuánticos en lugar de quedar bloqueados en ECDSA. En agosto de 2026, los desarrolladores movieron EIP-8141 de Considered for Inclusion a Scheduled for Inclusion en Hegotá, aunque su especificación sigue siendo un borrador y los detalles aún pueden cambiar antes de su activación.
Las discusiones anteriores sobre la hoja de ruta vinculaban Hegotá con los Verkle Trees, pero el alcance programado actualmente se centra en FOCIL y las transacciones en marco. El trabajo sobre statelessness continúa bajo la hoja de ruta más amplia de lean Ethereum de Ethereum, en lugar de ser una función confirmada de Hegotá.
Más allá de Hegotá, la Fundación está impulsando Strawmap, su hoja de ruta a largo plazo resistente a la computación cuántica. Este trabajo incluye firmas basadas en hash (leanXMSS), un zkVM mínimo (leanVM) para comprimir firmas seguras frente a la cuántica, y pruebas de interoperabilidad semanales entre más de 10 equipos de clientes.
Preguntas frecuentes
¿Cuándo se activará la actualización Glamsterdam?
Se espera que Glamsterdam llegue en el cuarto trimestre de 2026, pero no se ha anunciado ninguna fecha confirmada de activación en mainnet. La actualización se activó en la testnet Sepolia el 6 de octubre de 2026, y se espera que las pruebas continúen en la testnet Hoodi antes de fijar una fecha para mainnet.
¿Qué es la separación entre proponente y constructor consagrada (ePBS)?
La ePBS (EIP-7732) traslada la relación entre los proponentes de bloques y los constructores de bloques al protocolo central de Ethereum, eliminando la necesidad de middleware de retransmisión de terceros como MEV-Boost.
Introduce un Comité de Puntualidad del Payload y una lógica de doble plazo que amplía la ventana de propagación del bloque de 2 segundos a aproximadamente 9 segundos, permitiendo que la red maneje bloques más grandes.
¿Qué son las listas de acceso a nivel de bloque (BALs)?
Las BALs (EIP-7928) proporcionan un mapa anticipado de todas las dependencias de las transacciones dentro de un bloque. Al indicar a los validadores qué cuentas tocará cada transacción antes de que comience la ejecución, las BALs permiten el procesamiento paralelo de transacciones no conflictivas y una sincronización más rápida de los nodos mediante la sincronización sin ejecución.
¿Glamsterdam reducirá las comisiones de gas?
El objetivo principal de Glamsterdam es aumentar la capacidad y el rendimiento de la red, no reducir directamente las comisiones de gas. Al elevar el objetivo del límite de gas y habilitar la ejecución paralela, cabrán más transacciones en cada bloque, lo que podría ayudar a reducir los picos de comisiones relacionados con la congestión.
Sin embargo, EIP-8037 también eleva los costos de las operaciones que crean estado para evitar el crecimiento excesivo de la base de datos, por lo que algunas operaciones pueden volverse más caras.
¿Cuál es la diferencia entre Glamsterdam y Fusaka?
Fusaka, activada en diciembre de 2025, introdujo PeerDAS para mejorar la disponibilidad de datos y aumentó los parámetros de blobs para los rollups de Capa 2. Glamsterdam se basa en esta fundación al centrarse en la escalabilidad de la Capa 1 mediante ePBS, listas de acceso a nivel de bloque y reajuste del gas. Mientras que Fusaka benefició principalmente a los rollups de Capa 2, Glamsterdam apunta directamente a la capa base.
¿Qué viene después de Glamsterdam?
Se espera que Hegotá le siga en el segundo trimestre de 2027, con FOCIL (EIP-7805) y las transacciones en marco (EIP-8141) como funciones programadas. A más largo plazo, la hoja de ruta Strawmap de la Fundación apunta hacia tecnología de firmas resistentes a la cuántica.
Reflexiones finales
Glamsterdam es un paso importante en la hoja de ruta de escalado de Ethereum. La actualización pretende preparar a Ethereum para un rendimiento sustancialmente mayor sin sacrificar la descentralización ni la accesibilidad de los nodos.
Los cambios clave incluyen consagrar la separación entre proponente y constructor, introducir el procesamiento paralelo de transacciones mediante listas de acceso a nivel de bloque y reajustar el gas para gestionar el crecimiento del estado.
Con la activación de la testnet Sepolia completada en octubre de 2026, Glamsterdam ha superado su primera prueba pública, y la ventana de activación en mainnet en el cuarto trimestre de 2026 es la expectativa actual. Como ocurre con cualquier actualización de red, el calendario y el alcance pueden cambiar, por lo que seguir los anuncios oficiales de Ethereum sigue siendo la mejor manera de mantenerse al día.
Lectura adicional
¿Qué es Ethereum y cómo funciona?
Actualización Fusaka de Ethereum: todo lo que necesitas saber
¿Cómo funcionan las comisiones de gas en Ethereum?
¿Qué es una propuesta de mejora de Ethereum (EIP)?
Blockchain Capa 1 vs. soluciones de escalado de Capa 2