¿Por qué Glamsterdam podría ser una de las actualizaciones más importantes de Ethereum después de la fusión?
Escrito por: KarenZ, Foresight News
La actualización Glamsterdam de Ethereum puede ser fácilmente malinterpretada como una simple iteración técnica para aumentar el rendimiento. Más precisamente, está reestructurando el proceso de creación de bloques, el proceso de verificación y la forma de fijar precios de recursos, preparando el terreno para un límite de Gas más alto, mayor capacidad de blobs y ejecución paralela en el futuro.
Hasta el 23 de junio de 2026, ethereum.org ha marcado Glamsterdam como una actualización planificada para la segunda mitad de 2026. El nombre Glamsterdam proviene de la combinación de la actualización de la capa de ejecución Amsterdam y la actualización de la capa de consenso Gloas. La hoja de ruta oficial la sitúa después de Fusaka en diciembre de 2025 y antes de Hegotá, y enumera claramente dos funciones principales: separación de proponentes y constructores dentro del protocolo, es decir, ePBS, y listas de acceso a nivel de bloque, es decir, BAL.
Quien propone, quien construye: ePBS escribe el trabajo de proposición de bloques en el protocolo
Hoy, producir un bloque en Ethereum es como un relevo con poco tiempo: alguien se encarga de proponer el bloque y alguien de construir el contenido de las transacciones; además, depende de infraestructura fuera del protocolo como MEV-Boost y relés de terceros.
Este sistema lleva funcionando muchos años. Sin embargo, también pone parte de las relaciones de confianza fuera del protocolo, y hace que los validadores tengan que manejar a la vez tareas como consenso, ejecución y disponibilidad de datos dentro de una ventana de tiempo muy corta.
Uno de los cambios principales de Glamsterdam es el número 1: EIP-7732, es decir ePBS (Enshrined Proposer-Builder Separation), que escribe la separación entre proponentes y constructores dentro del protocolo.
En pocas palabras, el proponente se encarga de elegir el bloque de consenso, y el constructor se encarga de preparar el contenido de las transacciones dentro de ese bloque. El constructor no puede prometerlo solo de palabra: primero debe «entregar una garantía» dentro del protocolo, dejando claro qué bloque de ejecución entregará y cuánto pagará al proponente; después, el Payload Timeliness Committee (PTC, Comité de Oportunidad del Payload) verifica si lo entrega a tiempo.
El punto clave de este cambio no es solo reducir la dependencia de relés de terceros: también se trata de conseguir tiempo para la propagación y la verificación del bloque.
Hoy, los validadores necesitan procesar consenso y ejecución en una ventana clave muy corta. ePBS separa estas dos tareas, haciendo que la carga de ejecución se revele y verifique más tarde. Según el diseño de EIP-7732, la ventana de propagación de la carga de ejecución —el tiempo disponible para que los datos se propaguen en la red y los nodos los reciban— puede ampliarse de aproximadamente 2 segundos a aproximadamente 9 segundos. Al hacer la ventana más larga, Ethereum, al aumentar la capacidad de bloque, tiene menos riesgo de perder votos o de sufrir reorgs porque los nodos no alcancen a descargar, verificar y emitir votos a tiempo.
Esto quizá no se perciba directamente por el usuario común, pero es clave para el escalado de Ethereum. Una ventana de propagación y verificación más larga significa que la red puede manejar cargas mayores de manera más segura. En un reporte del 16 de junio de 2026, CoinDesk citó a Parithosh Jayanthi, ingeniero DevOps de la Fundación Ethereum: Glamsterdam podría ser una de las mayores bifurcaciones desde Merge, cambiará muchas suposiciones sobre Ethereum y preparará el terreno para una escalada aún de mayor escala en el futuro.
BAL y la recalibración de precios: escalar no solo es pisar el acelerador; también hay que controlar la base de datos
Otro cambio central de Glamsterdam es EIP-7928, Block-Level Access Lists, listas de acceso a nivel de bloque.
Se puede entender como «un registro de accesos» para cada bloque: cuando ese bloque se ejecuta, qué cuentas y qué posiciones de almacenamiento toca; y después de ejecutar, en qué estados relevantes se convierte. Todo eso debe registrarse. Así, cuando los nodos procesan bloques, ya no es tan parecido a sacar la caja a ciegas: pueden saber antes qué datos necesitan leerse y qué cálculos se pueden avanzar en paralelo.
El EIP-2930 anterior ya introdujo listas de acceso a nivel de transacción, pero eran opcionales y su uso real fue limitado. El cambio de EIP-7928 es que eleva las listas de acceso al nivel de bloque: dentro del encabezado del bloque queda un «huella» (registro hash) de esta lista y, para la carga de ejecución, se almacena el listado completo. Cuando el nodo ejecuta el bloque, comprueba si los registros de acceso escritos en la lista realmente coinciden con el proceso de ejecución del bloque; si no coincide, el bloque es inválido.
¿Por qué es importante esto? Hoy, cuando Ethereum ejecuta transacciones, muchas operaciones de acceso a datos solo se saben de verdad cuando se llega a ese punto. Los nodos no saben si un conjunto de transacciones leerá y escribirá al mismo tiempo la misma cuenta o el mismo slot de almacenamiento, así que es difícil tener confianza para paralelizar. BAL equivale a escribir explícitamente las trazas de acceso durante la ejecución del bloque, permitiendo que los clientes hagan lecturas paralelas del disco, verificación paralela de transacciones y cálculo paralelo de raíces de estado; e incluso en algunos casos, pueden reejecutar parcialmente sin tener que reproducir todo para actualizar el estado. No es un botón que reduce directamente las comisiones para el usuario, sino espacio de ingeniería para que los clientes se paralelicen.
Pero la lógica de escalado de Glamsterdam no se limita a «ensanchar el camino». También busca controlar la expansión a largo plazo de la base de datos de Ethereum. EIP-8037 aumenta el costo de crear estado e introduce el costo por byte por estado (CPSB). El estado puede entenderse como el contenido de la base de datos que Ethereum debe guardar a largo plazo, por ejemplo, nuevas cuentas, nuevos contratos y nuevos slots de almacenamiento. La ejecución de una transacción termina, pero el estado se queda en el libro que todos los nodos deben mantener; si el estado crece demasiado rápido, ejecutar nodos será cada vez más caro y la descentralización se verá presionada poco a poco.
Los números de contexto que aporta EIP-8037 son muy intuitivos: al 1 de enero de 2026, una base de datos de un nodo Geth dedicada solo al estado pesa aproximadamente 390 GiB; después de que el límite de gas de la red principal subiera de 30 millones a 60 millones, el estado agregado diariamente pasó de aproximadamente 105 MiB a 326 MiB, lo que equivale a un crecimiento anual de unos 116 GiB. Si se extrapola proporcionalmente bajo un límite de 200 millones de Gas, el crecimiento anual del estado podría llegar a unos 387 GiB y superar el umbral de degradación del rendimiento de 650 GiB en menos de un año.
Por eso, lo que quiere hacer EIP-8037 es separar el precio de «cálculo temporal» del de «ocupar una base de datos de forma permanente». Crear nuevo estado será más caro, porque lo que se le impone a la red no es solo un costo de computación puntual, sino una carga de almacenamiento a largo plazo.
Vitalik Buterin también mencionó, al explicar la hoja de ruta de ampliación hacia Glamsterdam, que Glamsterdam separará el costo de creación de estado de los costos de ejecución y de calldata: la meta es poder ampliar más la capacidad de ejecución, sin que el tamaño del estado crezca a la misma velocidad.
Mirándolo en conjunto, BAL hace que a los nodos les resulte más fácil procesar bloques en paralelo, resolviendo el problema de «ir más rápido»; la nueva tarificación del estado creado hace que las operaciones que ocupan bases de datos durante mucho tiempo cuesten más, resolviendo el problema de «no dejar que el libro de contabilidad se infle». La ampliación de Glamsterdam no es solo subir el límite de Gas, sino plantear una pregunta más real: ¿puede Ethereum albergar más transacciones y, al mismo tiempo, evitar que se descontrole la presión en la propagación de bloques, la verificación de transacciones y el almacenamiento de estado?
Lista EIP de Glamsterdam ya tomando forma: ¿qué está confirmado y qué aún espera?
Al 23 de junio de 2026, según el seguimiento en Forkcast sobre las actualizaciones de Ethereum, los desarrolladores actuales están probando la actualización de Glamsterdam en entornos devnet. El 3 de agosto se desplegará en Sepolia y el 16 de septiembre en la red principal (las fechas exactas pueden variar).
En el plan de inclusión para la lista de Glamsterdam hay 10 EIP:
EIP-7708 (transferencias de ETH también disparan registros, facilitando el indexado y el seguimiento de las transferencias nativas de ETH)
EIP-7732 (ePBS: incorpora en el protocolo la separación entre proponentes y constructores, reduciendo la dependencia de relés fuera del protocolo)
EIP-7778 (elimina el registro de gas relacionado con el refund de Gas, haciendo más simple el cálculo del gas del bloque)
EIP-7843 (añade el opcode SLOTNUM para que los contratos puedan leer el número de slot actual)
EIP-7928 (listas de acceso a nivel de bloque, BAL: registra las cuentas y posiciones de almacenamiento que el bloque ejecutó, allanando el camino para la verificación en paralelo)
EIP-7954 (aumenta el límite máximo del tamaño de los contratos, permitiendo bytecode de contrato más grande)
EIP-7976 (aumenta el costo mínimo de calldata; ajusta el costo mínimo de calldata)
EIP-7981 (aumenta el costo de las listas de acceso; recalibra la fijación de precios del Gas para access lists)
EIP-8024 (opcodes SWAPN, DUPN y EXCHANGE con compatibilidad hacia atrás; mejora la capacidad de manipulación de la pila del EVM)
EIP-8037 (aumenta el costo de crear estado; frena el crecimiento demasiado rápido de las bases de datos de estado)
Estos EIP pueden agruparse, a grandes rasgos, en tres categorías: la primera es la reestructuración del proceso de producción y verificación de bloques, con EIP-7732 y EIP-7928 como núcleo; la segunda es el ajuste de precios de recursos, incluyendo EIP-7778, EIP-7976, EIP-7981 y EIP-8037; la tercera son cambios en el EVM y la experiencia de desarrollo, incluyendo EIP-7708, EIP-7843, EIP-7954 y EIP-8024.
Dicho de otro modo, Glamsterdam no solo cambia un punto de funcionalidad: actualiza a la vez la división de trabajo al proponer bloques, la verificación en paralelo, el pricing de Gas y la disponibilidad del EVM.
Hay otra tanda de EIP que siguen en la lista de «se está considerando incluir»:
EIP-2780 (Gas intrínseco de transacciones dividido según recursos)
EIP-7610 (revertir al crear un contrato con cuentas de almacenamiento no vacío)
EIP-7688 (estructuras de datos de la capa de consenso compatibles con el futuro)
EIP-7904 (análisis del costo de Gas; podría eliminarse de Glamsterdam)
EIP-7975 (eth/70, listas parciales de recibos de bloques)
EIP-7997 (fábrica de contratos determinista)
EIP-8038 (actualización de los costos de Gas para accesos al estado)
EIP-8045 (excluye a validadores que ya han sido castigados por seguir proponiendo bloques)
EIP-8061 (aumenta el churn al salir y al fusionar)
EIP-8070 (eth/72, Sparse Blobpool)
EIP-8080 (hacer que las salidas usen consolidation queue)
EIP-8136 (deltas a nivel de celda para difusión de datos)
EIP-8159 (eth/71, intercambio de listas de acceso)
EIP-8246 (elimina SELFDESTRUCT burn)
EIP-8282 (Builder Execution Requests: proporciona a los constructores de ePBS solicitudes específicas de registro y salida)
Además, Forkcast también lista EIP-8254 (limitar el número de deposit requests dentro de cada bloque de la capa de ejecución a 8192) como una lista de «se recomienda incluir».
Desde la perspectiva de los stakers, conviene prestar especial atención a EIP-8061 y EIP-8080, incluidos en la lista. Para los stakers, esto implica que la liquidez de salida podría mejorar. En un artículo del 5 de mayo de 2026, Figment señaló que los stakers institucionales necesitan centrarse principalmente en ePBS, EIP-8061 y EIP-8080, y estimó que, con un volumen de staking de alrededor de 38,9 millones de ETH al 4 de abril de 2026, EIP-8061 podría aumentar el límite de churn de salidas de 256 ETH/epoch a aproximadamente 1187 ETH/epoch, mientras que EIP-8080 permitiría que las salidas ordinarias aprovechen la capacidad sobrante de la cola de consolidación. Figment también recordó que todas las cifras antes del despliegue en la red principal deben considerarse especulativas.
Fuente: Figment
El protocolo está evolucionando y también cambian los miembros de la Fundación
La preparación técnica para Glamsterdam y los ajustes de personal en el clúster de protocolos (Protocol cluster) de la Fundación Ethereum ocurrieron casi al mismo tiempo. En un post de blog del 11 de mayo de 2026, la Fundación Ethereum afirmó que Glamsterdam ya alcanzó varios hitos: el establecimiento de un floor de 200 millones de Gas como objetivo confiable post-Glamsterdam, la ejecución estable de ePBS en el devnet de Glamsterdam con múltiples clientes y la finalización de EIP-8037.
El mismo artículo anunció la transición de liderazgo del Protocol cluster: Will Corcoran, Kev Wedderburn y Fredrik serán los nuevos coordinadores del clúster de protocolos. El coordinador anterior Barnabé Monnot y Tim Beiko se marchan de la Fundación Ethereum; Alex Stokes se toma unas vacaciones.
La descripción del reparto de funciones para tres nuevos coordinadores es: Will Corcoran tiene experiencia en coordinación entre equipos; Kev Wedderburn lidera el equipo de zkEVM; Fredrik lidera los proyectos Protocol Security y Trillion Dollar Security.
Estos cambios no se limitaron al equipo de protocolo. El 18 de junio de 2026, Hsiao-Wei Wang publicó un texto en el que afirmaba que, tras volver de vacaciones, decidió renunciar a sus cargos como director ejecutivo adjunto de la Fundación Ethereum y como miembro de la junta directiva
El ex investigador de la Fundación Ethereum, Dankrad Feist, declaró el 19 de junio de 2026 que quienes se van de la EF son creyentes de CROPS (anti-censura y anti-captura, open source, privacidad y seguridad). Dijo que el problema no es la estrategia, sino la gestión, y calificó esa salida de talento como una noticia más bien negativa para Ethereum. En cambio, el cofundador de Miden, Azeem, lo interpretó desde la dirección opuesta: considera que a la EF le cuesta cambiarse a sí misma; tras la salida de talento, podrían surgir nuevas organizaciones capaces de ejecutar el roadmap de Ethereum, lo cual a largo plazo sería un beneficio neto para el ecosistema.
El discurso de los insiders de la Fundación Ethereum se parece más a un ejercicio de poner límites. Bastian Aue (Aerugo), director ejecutivo interino en funciones de la Fundación Ethereum, respondió que las razones por las que miembros de la Fundación dejan sus cargos incluyen discrepancias estratégicas, adecuación a su puesto, cambios institucionales normales o decisiones personales. La EF no discutirá en redes sociales asuntos personales de personal, pero señaló que quienes se marchen deberían hacerlo de manera digna.
La Fundación Ethereum, después, aportó una narrativa organizativa más clara mediante un thread oficial en Twitter: para realizar el potencial de Ethereum se necesita una alianza de múltiples organizaciones; durante el último año ya varias organizaciones han colaborado para fortalecer la resiliencia y las capacidades del ecosistema. Los ejemplos que dio la EF incluyen: ethlabs (un laboratorio de investigación sin fines de lucro centrado en la siguiente etapa de adopción de Ethereum y ETH), anunciado el 23 de junio; Eth Apps Guild (dirigido a adopción real de aplicaciones nativas de Ethereum, con especial atención a mercados emergentes), lanzado en abril de 2026; Ethereum Economic Zone (objetivo de reducir la fragmentación del ecosistema mediante componibilidad sincronizada y pruebas de conocimiento cero en tiempo real); y Argot (un colectivo autónomo de ingenieros e investigadores que mantiene herramientas de compilación Solidity y open source), establecido en 2025.
Este thread oficial hace más fácil entender los cambios recientes de la Fundación Ethereum: la Fundación no solo está empujando a personas y proyectos hacia afuera, ni abandonando la coordinación central. Más bien, podría estar descomponiendo la hoja de ruta de Ethereum para que más organizaciones la asuman conjuntamente.
Resumen
Así que Glamsterdam no debería verse solo como un conjunto de EIP. Es un reordenamiento de ingeniería de Ethereum antes de alcanzar mayor rendimiento: quién construye bloques, quién propone, quién verifica, qué datos deben guardarse a largo plazo y qué recursos deberían costar más, todo se ha vuelto a poner sobre la mesa.
Las palabras clave de la ruta técnica son ePBS, BAL y el comienzo de un Gas multidimensional; y las palabras clave de la ruta organizativa son más realistas: si la Fundación Ethereum puede mantener su capacidad de coordinación, y si nuevas organizaciones fuera de la Fundación pueden convertir esa capacidad de coordinación en entregas continuas.
Referencia:
https://forkcast.org/upgrade/glamsterdam/
https://ethereum.org/roadmap/glamsterdam/
https://blog.ethereum.org/2026/05/11/protocol-update-may-26
https://x.com/VitalikButerin/status/2027403360484430122