Autor: KarenZ, Foresight News
La actualización Glamsterdam de Ethereum es más fácilmente malinterpretada como otra iteración técnica destinada únicamente a aumentar el rendimiento. Una definición más precisa sería: está reorganizando el proceso de creación de bloques, la validación y la forma de fijar precios a los recursos en Ethereum, sentando las bases para un límite de Gas más alto, una mayor capacidad de blob y una ejecución paralela futura.
Hasta el 23 de junio de 2026, ethereum.org ha etiquetado Glamsterdam como una actualización planeada para la segunda mitad de 2026. El nombre Glamsterdam es una combinación de la actualización de la capa de ejecución Amsterdam y la actualización de la capa de consenso Gloas. El roadmap oficial la sitúa después de Fusaka (diciembre de 2025) y antes de Hegotá, e incluye explícitamente dos funciones principales: la Separación Proponente-Constructor integrada en el protocolo (ePBS) y las Listas de Acceso a Nivel de Bloque (BAL).
Quién propone, quién construye: ePBS integra la división del trabajo en el protocolo
Hoy, la creación de bloques en Ethereum se parece a un relevo con mucho estrés: alguien se encarga de proponer el bloque, otro de construir el contenido de las transacciones, y el proceso depende además de infraestructuras externas al protocolo como MEV-Boost y relés (relays) de terceros.
Este sistema ha funcionado durante años, pero deja parte de las relaciones de confianza fuera del protocolo y obliga a los validadores a manejar simultáneamente tareas de consenso, ejecución y disponibilidad de datos en una ventana de tiempo muy corta.
Uno de los cambios principales de Glamsterdam, la EIP-7732, o ePBS (Enshrined Proposer-Builder Separation), consiste precisamente en integrar esta división del trabajo entre proponente y constructor en el protocolo.
En pocas palabras, el proponente es responsable de elegir el bloque de consenso, y el constructor de preparar el contenido de las transacciones dentro de él. El constructor no puede limitarse a prometer; primero debe "presentar una garantía" en el protocolo: especificar claramente qué bloque de ejecución entregará y cuánto pagará al proponente. Posteriormente, el Payload Timeliness Committee (PTC) verificará si cumple con la entrega a tiempo.
El objetivo clave de este cambio no es solo reducir la dependencia de relés de terceros, sino también ganar tiempo para la propagación y verificación de bloques.
Hoy, los validadores necesitan manejar simultáneamente consenso y ejecución en una ventana crítica muy breve; ePBS separa estas dos tareas, permitiendo que la carga de ejecución se revele y verifique más tarde. Según el diseño de la EIP-7732, la ventana de propagación de la carga de ejecución, es decir, el tiempo disponible para que los datos se propaguen por la red y sean recibidos por los nodos, puede ampliarse de unos 2 segundos a unos 9 segundos. Con una ventana más larga, al aumentar la capacidad de los bloques, Ethereum corre menos riesgo de incrementar los votos perdidos o la reordenación de bloques debido a que los nodos no tengan tiempo de descargar, verificar y votar.
Este cambio puede no ser directamente perceptible para el usuario común, pero es crucial para la escalabilidad de Ethereum. Ventanas de propagación y verificación más largas significan que la red puede procesar cargas mayores de forma más segura. En un reporte del 16 de junio de 2026, CoinDesk citó al ingeniero de DevOps de la Fundación Ethereum, Parithosh Jayanthi, diciendo que Glamsterdam podría ser uno de los forks más grandes desde The Merge, cambiando muchas suposiciones sobre Ethereum y preparando el terreno para una escalabilidad a mayor escala en el futuro.
BAL y reajuste de precios: Escalar no es solo acelerar, también gestionar la base de datos
Otro cambio central en Glamsterdam es la EIP-7928, Block-Level Access Lists, Listas de Acceso a Nivel de Bloque.
Puede entenderse como dotar a cada bloque de un "registro de acceso": qué cuentas y posiciones de almacenamiento fueron tocadas durante su ejecución, y en qué estado quedaron los datos relacionados después de la ejecución, todo debe registrarse. De esta manera, al procesar un bloque, los nodos ya no actúan completamente a ciegas; pueden saber de antemano qué datos necesitan leer y qué cálculos pueden avanzar en paralelo.
La EIP-2930 introdujo previamente listas de acceso a nivel de transacción, pero eran opcionales y su uso real fue limitado. El cambio con la EIP-7928 es que eleva la lista de acceso al nivel del bloque: el encabezado del bloque deja la "huella" (hash) de esta lista, y la carga de ejecución almacena la lista completa. Los nodos verifican al ejecutar el bloque si los registros de acceso escritos en la lista coinciden realmente con el proceso de ejecución del bloque; si no coinciden, el bloque es inválido.
¿Por qué es importante esto? Hoy, cuando Ethereum ejecuta transacciones, muchos accesos a datos solo se conocen al llegar a ese paso. Los nodos no saben si un grupo de transacciones leerá o escribirá simultáneamente en la misma cuenta o ranura de almacenamiento, por lo que les cuesta procesarlas en paralelo con confianza. BAL equivale a hacer explícita la traza de acceso durante la ejecución del bloque, permitiendo a los clientes realizar lecturas paralelas de disco, verificación paralela de transacciones, cálculo paralelo de raíces de estado, y actualizar el estado en algunos escenarios sin reproducir completamente las transacciones. No es un botón que reduzca directamente las tarifas para los usuarios, sino que abre espacio a la ingeniería de clientes para la paralelización.
Pero la lógica de escalabilidad de Glamsterdam no se limita a "ensanchar la carretera". También debe controlar la expansión a largo plazo de la base de datos de Ethereum. La EIP-8037 aumenta el costo de creación de estado e introduce un costo por byte de estado (CPSB). El estado puede entenderse como el contenido de la base de datos que Ethereum debe conservar a largo plazo, como nuevas cuentas, nuevos contratos, nuevas ranuras de almacenamiento. Las transacciones terminan al ejecutarse, pero el estado permanece en el libro mayor que todos los nodos deben mantener; si el estado crece demasiado rápido, ejecutar un nodo será cada vez más costoso y la descentralización se verá erosionada gradualmente.
La EIP-8037 presenta cifras de contexto muy claras: hasta enero de 2026, la base de datos de un nodo Geth dedicado al estado era de aproximadamente 390 GiB; después de que el límite de Gas de la red principal aumentara de 30 millones a 60 millones, el estado nuevo diario pasó de unos 105 MiB a unos 326 MiB, lo que equivale a un crecimiento anual de unos 116 GiB. Extrapolando proporcionalmente bajo un límite de Gas de 200 millones, el crecimiento anual del estado podría alcanzar unos 387 GiB, superando en menos de un año el umbral de degradación del rendimiento de 650 GiB.
Por lo tanto, lo que busca la EIP-8037 es separar la fijación de precios entre el "cálculo temporal" y la "ocupación permanente de la base de datos". Crear nuevo estado será más caro, porque impone a la red no un costo de cálculo único, sino una carga de almacenamiento a largo plazo.
Vitalik Buterin también mencionó, al explicar la ruta de escalabilidad de Glamsterdam, que Glamsterdam separará el costo de creación de estado del costo de ejecución y calldata: el objetivo es permitir que la capacidad de ejecución se amplíe mucho más, mientras el tamaño del estado no se expanda a la misma velocidad.
Vistos en conjunto, BAL facilita que los nodos procesen bloques en paralelo, resolviendo el problema de "ejecutar más rápido"; el reajuste de precios de creación de estado hace que las operaciones que ocupan permanentemente la base de datos paguen un costo mayor, resolviendo el problema de "no hinchar cada vez más el libro mayor". La escalabilidad de Glamsterdam no es simplemente aumentar el límite de Gas, sino plantear una pregunta más realista: ¿puede Ethereum albergar más transacciones y al mismo tiempo evitar que las presiones en la propagación de bloques, la verificación de transacciones y el almacenamiento del estado se descontrolen?
La lista de EIPs de Glamsterdam toma forma: ¿Cuáles están fijadas y cuáles aún están en espera?
Hasta el 23 de junio de 2026, según el contenido de seguimiento sobre actualizaciones de Ethereum en Forkcast, los desarrolladores de Ethereum están realizando pruebas en entornos devnets para la actualización Glamsterdam, con lanzamiento previsto en Sepolia el 3 de agosto y en la red principal el 16 de septiembre (las fechas específicas de lanzamiento pueden cambiar).
Actualmente hay 10 EIPs planeadas para incluir en la lista de Glamsterdam:
- EIP-7708 (Las transferencias de ETH también activarán logs, facilitando la indexación y el rastreo de transferencias nativas de ETH)
- EIP-7732 (ePBS, integra la división del trabajo entre proponente y constructor en el protocolo, reduciendo la dependencia de relays externos al protocolo)
- EIP-7778 (Elimina la contabilidad de Gas relacionada con reembolsos de Gas, simplificando el cálculo del Gas del bloque)
- EIP-7843 (Agrega el opcode SLOTNUM, permitiendo a los contratos leer el número del slot actual)
- EIP-7928 (Listas de acceso a nivel de bloque BAL, registra las cuentas y posiciones de almacenamiento accedidas durante la ejecución del bloque, allanando el camino para la verificación paralela)
- EIP-7954 (Aumenta el límite máximo de tamaño de contrato, permitiendo bytecodes de contrato más grandes)
- EIP-7976 (Aumenta el costo mínimo (floor cost) de calldata, ajustando el costo mínimo del calldata)
- EIP-7981 (Aumenta el costo de las listas de acceso, recalibrando la fijación de precios de Gas de las access lists)
- EIP-8024 (Opcodes SWAPN, DUPN, EXCHANGE compatibles con versiones anteriores, mejorando la capacidad de manipulación de la pila de la EVM)
- EIP-8037 (Aumenta el costo de Gas de creación de estado, inhibiendo la expansión demasiado rápida de la base de datos de estado)
Estas EIPs pueden clasificarse aproximadamente en varias categorías: la primera es la reestructuración del proceso de creación de bloques y verificación, centrada en EIP-7732 y EIP-7928; la segunda son ajustes en la fijación de precios de recursos, incluyendo EIP-7778, EIP-7976, EIP-7981 y EIP-8037; la tercera son cambios en la EVM y la experiencia del desarrollador, incluyendo EIP-7708, EIP-7843, EIP-7954, EIP-8024.
En otras palabras, Glamsterdam no modifica solo un punto funcional, sino que actualiza simultáneamente la división del trabajo en la creación de bloques, la verificación paralela, la fijación de precios de Gas y la usabilidad de la EVM.
Hay otro grupo de EIPs que aún se encuentran en la lista de "consideración para inclusión":
- EIP-2780 (Divide el Gas intrínseco de la transacción por recurso)
- EIP-7610 (Revierte la creación de contratos en cuentas de almacenamiento no vacías)
- EIP-7688 (Estructuras de datos de la capa de consenso compatibles con el futuro)
- EIP-7904 (Análisis de costo de Gas de cálculo, posiblemente eliminada de Glamsterdam)
- EIP-7975 (eth/70, lista parcial de recibos de bloque)
- EIP-7997 (Contrato fábrica determinista)
- EIP-8038 (Actualización del costo de Gas de acceso al estado)
- EIP-8045 (Excluye a los validadores sancionados de seguir proponiendo bloques)
- EIP-8061 (Aumenta el límite de salida y fusión (churn))
- EIP-8070 (eth/72, Sparse Blobpool)
- EIP-8080 (Permite que las salidas utilicen la cola de consolidación)
- EIP-8136 (Deltas a nivel de celda para la difusión de columnas de datos)
- EIP-8159 (eth/71, intercambio de listas de acceso a bloques)
- EIP-8246 (Elimina la quema (burn) de SELFDESTRUCT)
- EIP-8282 (Builder Execution Requests, proporciona solicitudes de registro y salida específicas para los constructores de ePBS)
Además, Forkcast actualmente también lista la EIP-8254 (limita el número de deposit requests por bloque de la capa de ejecución a 8192) como "sugerida para inclusión".
Desde la perspectiva de los stakers, las EIPs EIP-8061 y EIP-8080 en la lista de consideración merecen especial atención. Para los stakers, esto podría significar una mejora en la liquidez de salida. Figment, en un artículo del 5 de mayo de 2026, afirmó que los stakers institucionales deben prestar más atención a ePBS, EIP-8061 y EIP-8080, y estimó que, con un tamaño de stake de aproximadamente 38.9 millones de ETH hasta abril de 2026, la EIP-8061 podría aumentar el límite de salida (churn limit) de 256 ETH/epoch a aproximadamente 1187 ETH/epoch, mientras que la EIP-8080 permitiría que las salidas ordinarias aprovechen la capacidad sobrante de la cola de consolidación. Figment también advierte que todas las cifras antes del lanzamiento en la red principal deben considerarse especulativas.
Fuente: Figment
El protocolo se actualiza, y también cambian los miembros de la Fundación
La preparación técnica de Glamsterdam ha coincidido casi en el tiempo con ajustes de personal en el clúster de protocolo (Protocol cluster) de la Fundación Ethereum. En un blog del 11 de mayo de 2026, la Fundación Ethereum afirmó que Glamsterdam había alcanzado varios hitos: se estableció un límite de Gas de 200 millones como objetivo post-Glamsterdam creíble, ePBS funciona de manera estable en el devnet multinavegador de Glamsterdam, y la EIP-8037 se finalizó.
El mismo artículo anunciaba el relevo en el liderazgo del Protocol cluster: Will Corcoran, Kev Wedderburn y Fredrik se convertirían en los nuevos coordinadores del clúster de protocolo. Los coordinadores originales Barnabé Monnot y Tim Beiko abandonan la Fundación Ethereum, y Alex Stokes se toma una licencia.
La descripción de la Fundación sobre la división del trabajo de los tres nuevos coordinadores es: Will Corcoran tiene experiencia en coordinación entre equipos; Kev Wedderburn lidera el equipo zkEVM; Fredrik lidera el proyecto Protocol Security y Trillion Dollar Security.
Estos cambios no se han limitado al equipo de protocolo. El 18 de junio de 2026, Hsiao-Wei Wang publicó que, después de un permiso, había decidido renunciar a su cargo como Directora Ejecutiva Conjunta y miembro de la Junta Directiva de la Fundación Ethereum.
El ex investigador de la Fundación Ethereum Dankrad Feist declaró el 19 de junio de 2026 que las personas que abandonan la EF son creyentes en CROPS (Censorship Resistance & Capture Resistance, Open Source, Privacy, Security), que el problema no está en la estrategia, sino en la gestión, y calificó esta fuga de talento como algo ligeramente negativo para Ethereum. Por otro lado, Azeem, cofundador de Miden, interpretó en sentido contrario, argumentando que la EF tiene dificultades para cambiarse a sí misma, y que después de que el talento se vaya, podrían surgir nuevas organizaciones más capaces de ejecutar el roadmap de Ethereum, lo que a largo plazo sería netamente positivo para el ecosistema.
La narrativa interna en la Fundación Ethereum parece más bien de establecer límites. El Director Ejecutivo Conjunto interino de la Fundación Ethereum, Bastian Aue (Aerugo), respondió que las razones de la salida de los miembros de la EF incluyen diferencias estratégicas, adaptación al puesto, cambios institucionales normativos o elecciones personales, que la EF no discutiría asuntos de personal individual en redes sociales, pero que quienes se van deberían tener una salida digna.
Posteriormente, la Fundación Ethereum utilizó un hilo oficial en Twitter para dar una narrativa organizativa más clara: lograr el potencial de Ethereum requiere una coalición de múltiples organizaciones, y en el último año varias organizaciones ya han trabajado conjuntamente para mejorar la resiliencia y capacidad del ecosistema. La EF enumeró ejemplos como: ethlabs (anunciado el 23 de junio, un laboratorio de I+D sin fines de lucro centrado en la siguiente fase de adopción de Ethereum y ETH), Eth Apps Guild (iniciado en abril de 2026, centrado en la adopción real de aplicaciones nativas de Ethereum, especialmente en mercados emergentes), Ethereum Economic Zone (iniciada en 2026, con el objetivo de reducir la fragmentación del ecosistema mediante composabilidad sincronizada y pruebas de conocimiento cero en tiempo real), y Argot (formado en 2025, un colectivo autónomo de ingenieros e investigadores que mantienen Solidity y herramientas de compilador de código abierto).
Este hilo oficial hace que los cambios recientes en la Fundación Ethereum sean más fáciles de entender: la Fundación no está simplemente empujando a personas y proyectos hacia afuera, ni abandonando la coordinación central, sino que probablemente esté distribuyendo el roadmap de Ethereum entre más organizaciones para compartir la responsabilidad.
Conclusión
Por lo tanto, Glamsterdam no debería verse solo como un conjunto de EIPs. Es una reorganización de ingeniería que Ethereum lleva a cabo antes de alcanzar un mayor rendimiento: quién construye el bloque, quién lo propone, quién lo valida, qué datos deben almacenarse a largo plazo y qué recursos deberían ser más caros, todo se vuelve a poner sobre la mesa.
Las palabras clave de la ruta técnica son ePBS, BAL y el inicio del Gas multidimensional; las palabras clave de la ruta organizativa son más realistas: si la Fundación Ethereum podrá mantener su capacidad de coordinación, y si las nuevas organizaciones fuera de la Fundación podrán convertir esa capacidad de coordinación en una entrega continua.
Referencias:
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
