Cronología de Ethereum Glamsterdam: el objetivo de H1 2026 se traslada a Q4
La actualización Ethereum Glamsterdam estaba prevista para H1 2026. En agosto de 2026 sigue en devnet-8, y su activación ahora está prevista para Q4 2026. Esto es lo que cambió.

Kai Nakamoto
Analista de tecnología emergente

La actualización Ethereum Glamsterdam se planificó originalmente para la primera mitad de 2026. En agosto de 2026, sigue ejecutándose en devnet-8 y la hoja de ruta oficial ahora indica Q4 2026. Las cifras de recotización del gas que determinan el nuevo límite de gas seguían en revisión, no finalizadas, en la llamada All Core Devs del 13 de agosto. Esto es lo que realmente ocurrió y lo que aún debe suceder antes de que Glamsterdam y Hegota se lancen.
Fusaka se lanzó primero, después se movió el objetivo de Glamsterdam
Pectra se lanzó el 7 de mayo de 2025 con abstracción de cuentas (EIP-7702) y duplicó el rendimiento de blobs. La siguiente bifurcación después de Pectra no fue Glamsterdam, sino Fusaka: Fusaka se activó en la mainnet de Ethereum el 3 de diciembre de 2025 en la época 411392, con PeerDAS (EIP-7594) como principal novedad, que permite a los validadores muestrear datos de blobs en lugar de descargarlos por completo (anuncio de Ethereum Foundation).
La actualización Ethereum Glamsterdam se definió originalmente para H1 2026. La propia publicación de Ethereum Foundation sobre prioridades de protocolo de febrero de 2026 todavía la describía como "prevista para la primera mitad de 2026" (blog.ethereum.org). Ese objetivo no se mantuvo. La actual página de la hoja de ruta de ethereum.org para Glamsterdam ahora afirma que la actualización está "planificada para Q4 2026", y hasta la llamada All Core Devs Execution del 13 de agosto de 2026, los desarrolladores seguían debatiendo devnet-8 (con nombre en clave Platåberget) y finalizando las cifras de recotización del gas (issue #2178 de ethereum/pm). Una hard fork que debía estar activa a mediados de 2026 ni siquiera había fijado sus parámetros a mediados de agosto.
Glamsterdam: ejecución paralela y PBS integrado
La actualización Ethereum Glamsterdam aborda el cuello de botella de la ejecución secuencial de Ethereum con dos cambios principales.
Listas de acceso a nivel de bloque (EIP-7928)
EIP-7928 añade un campo block_access_list_hash a las cabeceras de bloque, un hash de cada cuenta y slot de almacenamiento tocado durante la ejecución del bloque, incluidas las cuentas sin cambios. Esto permite a los clientes leer el estado, ejecutar transacciones y reconstruir raíces de estado en paralelo en lugar de una instrucción a la vez, y es un requisito previo para la verificación sin estado de bloques (texto de EIP-7928). EIP-7928 se encuentra actualmente en estado Review en el sitio de EIPs, lo que significa que la especificación es lo bastante estable para que los equipos de clientes la implementen, pero aún no está finalizada.
Separación integrada entre proponente y constructor (EIP-7732)
Hoy Ethereum depende de relés externos como MEV-Boost para separar la propuesta de bloques de la construcción de bloques. EIP-7732 traslada esa separación al protocolo: los proponentes publican una oferta firmada de un registro de constructores dentro del protocolo (los constructores hacen staking de un mínimo de 1 ETH y están sujetos a slashing), y la validación de la carga útil de ejecución se difiere al siguiente slot en lugar de bloquear el actual. Un Payload Timeliness Committee de 512 validadores certifica que la carga útil se reveló a tiempo, sin volver a ejecutarla (texto de EIP-7732). Al igual que EIP-7928, está en estado Review, no Final.
Ambos EIPs se siguen bajo el meta-EIP de Glamsterdam, EIP-7773, que enumera 22 EIPs programados para su inclusión (que abarcan recotización del gas, cambios de opcode y actualizaciones de red) y 39 EIPs que se propusieron formalmente y se rechazaron. EIP-7773 en sí sigue en estado Draft; afirma claramente que los detalles de activación para Sepolia, Holesky y mainnet "aún deben determinarse".
La cuestión del límite de gas sigue abierta
El plan original planteaba un salto de aproximadamente 60 millones de gas a 100-200 millones. Esa cifra no está decidida. En la llamada ACDE del 13 de agosto, los desarrolladores revisaron una propuesta independiente, PFI EIP-8261, que advierte específicamente que establecer el límite de gas de 200M en el software de los clientes antes de que se active la bifurcación "arriesga un aumento prematuro" (ethereum/pm #2178). La página de la hoja de ruta de ethereum.org confirma que los equipos de clientes están probando actualmente con un bloque de referencia de 150 millones como paso intermedio para obtener una tarificación precisa del acceso al estado, no con el objetivo completo de 200 millones (ethereum.org/roadmap/glamsterdam). En términos simples: el aumento del límite de gas es real, pero la cifra final no está fijada, y los desarrolladores que lo construyen señalaron que lanzarlo demasiado pronto supone un riesgo para el protocolo.
Hay una segunda cuestión abierta específica de esta bifurcación: si los clientes están preparados para la expiración del historial, el plan de que los nodos completos dejen de almacenar para siempre todos los datos históricos de la cadena de Ethereum. Seguía siendo un punto abierto del orden del día, no una decisión resuelta, en la misma llamada de agosto.
Hegota: árboles Verkle, FOCIL y una cronología que no se ha fijado
Hegota sigue a Glamsterdam. Dos funciones la sustentan.
Árboles Verkle y clientes sin estado
Ethereum almacena actualmente el estado en Merkle Patricia Tries, que requieren pruebas grandes, varios kilobytes, para verificar una sola pieza de datos. Los árboles Verkle sustituyen esa estructura por otra que produce pruebas de aproximadamente 150 bytes. Las pruebas más pequeñas hacen posibles los clientes sin estado: un nodo puede verificar un bloque usando solo la cabecera y las pruebas Verkle que lo acompañan, sin conservar por sí mismo el estado completo de varios cientos de gigabytes. Ese es el cambio para el que las BALs anteriores están sentando las bases en el lado de ejecución.
FOCIL: resistencia a la censura a nivel de protocolo
La versión original de este artículo trataba Hegota como una bifurcación de una sola función (árboles Verkle). No lo es. Las Fork-Choice Enforced Inclusion Lists, EIP-7805, seleccionan aleatoriamente un comité de participantes por slot que puede forzar transacciones pendientes específicas en el siguiente bloque, cerrando la brecha por la que un constructor de bloques podría excluir silenciosamente transacciones válidas. La abstracción de cuentas nativa también está sobre la mesa para Hegota: EIP-7701 y EIP-8141 ("Frame Transactions") se mencionaron en la publicación de Ethereum Foundation sobre prioridades de protocolo de 2026 como candidatos para la bifurcación (blog.ethereum.org), y en la llamada del 13 de agosto, Frames había sido Considered-For-Inclusion y Nethermind había lanzado soporte de cliente, mientras una serie de reuniones específicas se reiniciaba para resolver una objeción abierta de compatibilidad con EVM (ethereum/pm #2178).
Hegota no tiene una fecha de mainnet fijada. La propia publicación de proceso de Ethereum Foundation de diciembre de 2025 establece únicamente el calendario de propuestas y selección, propuestas principales hasta principios de febrero de 2026, finalización de las principales propuestas a finales de febrero, una ventana adicional de 30 días para EIPs menores, y explícitamente no nombra una fecha de activación, remitiendo a los lectores a Forkcast para el calendario en directo (blog.ethereum.org/2025/12/22/hegota-timeline). En la llamada ACDE del 13 de agosto de 2026, la lista Priority-For-Inclusion de Hegota todavía se estaba finalizando, con un plazo de dos semanas para las propuestas pendientes y una fecha límite del 10 de septiembre de 2026 para que los equipos de clientes presentaran clasificaciones de preferencia. Todo lo que no tenga un patrocinador Priority-For-Inclusion para entonces se rechaza automáticamente. Dado que no se espera Glamsterdam antes de Q4 2026, una fecha de mainnet de Hegota dentro de 2026 no es realista; la Foundation no ha publicado ninguna fecha objetivo, por lo que cualquier referencia a 2027 es una inferencia del calendario, no un plan anunciado.
Cómo encajan la actualización Ethereum Glamsterdam y Hegota
| Función | Glamsterdam (objetivo Q4 2026) | Hegota (cronología sin fijar) |
|---|---|---|
| Enfoque | Velocidad de ejecución | Gestión de estado, resistencia a la censura |
| EIPs clave | EIP-7928 (BALs), EIP-7732 (ePBS) | Árboles Verkle, EIP-7805 (FOCIL) |
| Límite de gas | 60M hoy, pruebas con referencia de 150M | No es un objetivo de esta bifurcación |
| Impacto en nodos | Ejecución paralela, mayor rendimiento | Menor almacenamiento mediante clientes sin estado |
| Estado (ago. 2026) | devnet-8 activo, recotización del gas en finalización | Lista PFI aún abierta, sin fecha de mainnet |
Glamsterdam aumenta cuántas transacciones puede procesar Ethereum por bloque. Hegota pretende mantener asequible la operación de un nodo una vez que llegue ese rendimiento, reduciendo lo que un nodo debe almacenar. Lanzar más rendimiento sin la parte de gestión de estado aceleraría el problema de inflación del estado que los árboles Verkle existen para resolver. Esta es la interpretación de este artículo sobre la secuenciación; la Foundation no ha publicado una justificación declarada para ejecutar las dos bifurcaciones por separado en lugar de agruparlas.
Qué significa esto para los rollups de Layer 2
El ecosistema Layer 2 de Ethereum, donde ahora se desarrolla gran parte de la actividad de transacciones de cara al usuario, puede beneficiarse de Glamsterdam, aunque mediante un canal distinto al que ya redujo los costes de los rollups. El mayor techo de gas de ejecución de Glamsterdam aumenta cuántas transacciones puede procesar la propia L1; la capacidad en la que los rollups publican realmente sus datos es el espacio de blobs que PeerDAS (Fusaka) amplió en diciembre de 2025, un parámetro independiente que Glamsterdam no aumenta por sí mismo. Que un mayor límite de gas de ejecución se traduzca en menores comisiones de rollups depende de la demanda de L1 para ese espacio de bloque adicional en ese momento; no es una reducción de costes fija.
Para operadores de rollups como Arbitrum, Optimism y Base, el mecanismo que se debe vigilar es la capacidad del espacio de blobs y la demanda del mismo, no el techo de gas de ejecución; la capacidad añadida por PeerDAS puede reducir la presión de las comisiones de blobs cuando la demanda no la absorbe, una condición que no depende de que se lance Glamsterdam; la magnitud de cualquier efecto para el usuario final sigue variando según la arquitectura y la demanda propias de cada rollup. Para el ecosistema más amplio, consulta nuestro análisis de las tendencias de consolidación de Layer 2.
Contexto competitivo: cómo se compara Ethereum
Ethereum no se actualiza en el vacío. El protocolo Alpenglow de Solana apunta a una finalidad de bloque de 100-150ms. Avalanche, Sui y Aptos anuncian finalidad de menos de un segundo en su propia documentación, y están lanzando mientras Ethereum aún finaliza las cifras de recotización del gas para una bifurcación cuyo objetivo pasó de una ventana de primera mitad a una de cuarto trimestre.
El enfoque de Ethereum difiere en lo que optimiza:
- Descentralización - ePBS y los clientes sin estado se presentan en sus propuestas como una forma de reducir la carga de operar un validador o un nodo completo, no de maximizar el rendimiento bruto
- Seguridad - El trabajo de validación con pruebas ZK continúa en paralelo, aunque la proporción objetivo de validadores que las ejecutan en 2026 no se ha reconfirmado desde el retraso de Glamsterdam
- Componibilidad - Los rollups L2 elegibles se liquidan en la misma capa de seguridad compartida y se basan en la capacidad de espacio de blobs que PeerDAS de Fusaka ya amplió en diciembre de 2025, con la actualización Ethereum Glamsterdam añadiendo margen de ejecución de L1 por encima; los efectos prácticos sobre comisiones y capacidad siguen variando según la arquitectura y la demanda propias de cada rollup; cómo se compara esto con competidores de cadena única es una comparación que este artículo no realiza.
Para una comparación detallada de cómo se posicionan las blockchains L1, consulta nuestro análisis de Layer 1 Wars 2026. Para conocer el posicionamiento institucional de Ethereum, lee nuestro análisis en profundidad de Year of Ethereum 2026.
Riesgos y cuestiones abiertas de la actualización Ethereum Glamsterdam
Lo que el registro realmente muestra en agosto de 2026:
- El objetivo de H1 2026 ya se incumplió. Glamsterdam se describía como una bifurcación de H1 2026 tan recientemente como febrero de 2026 y ahora es oficialmente Q4 2026. Dado que tanto EIP-7732 como EIP-7928 siguen en estado Review en lugar de Final, un nuevo retraso es un riesgo material que merece seguimiento, no algo para lo que este artículo tenga el historial de retrasos de la bifurcación necesario para calificarlo como probable o improbable.
- El límite de gas no está decidido. Los desarrolladores están probando explícitamente con un bloque de referencia de 150M, no con la cifra principal de 200M, y una propuesta activa (EIP-8261) argumenta en contra de establecer 200M en el código de clientes antes de que se active la bifurcación.
- La preparación para la expiración del historial no está resuelta. Que los equipos de clientes puedan soportarla a tiempo para Glamsterdam seguía siendo una cuestión abierta en la llamada del 13 de agosto, no una función resuelta.
- Hegota no tiene fecha. El proceso para seleccionar las funciones de Hegota sigue en curso; la lista Priority-For-Inclusion solo será definitiva en la segunda mitad de agosto de 2026, con las clasificaciones de preferencia de clientes previstas para el 10 de septiembre de 2026.
- El retraso de adopción persiste independientemente de la fecha de lanzamiento. Incluso cuando los clientes sin estado estén disponibles, la actualización de la infraestructura por parte de los operadores de nodos existentes requiere tiempo que no aparece en una cronología de protocolo.
Conclusión
La actualización Ethereum Glamsterdam es real, pero va retrasada respecto a su calendario original. Fusaka se lanzó en su fecha revisada de diciembre de 2025. Glamsterdam no: sus EIPs principales siguen en Review, su límite de gas aún se prueba con una cifra provisional y su propia página de hoja de ruta trasladó el objetivo de H1 a Q4 2026. Hegota, que incorpora árboles Verkle y FOCIL, sigue a Glamsterdam y todavía no tiene ninguna fecha de mainnet.
Para los inversores, la señal que merece seguimiento no es el texto de la hoja de ruta, sino si devnet-8 resuelve sus cuestiones abiertas restantes (recotización del gas, preparación para la expiración del historial) sin otro retraso. Con una puntuación STRICT de 88 y $41.24 billion en TVL (DefiLlama, Chains API), Ethereum entra en este ciclo de actualización con la mayor concentración de capital DeFi de cualquier cadena seguida aquí, incluso mientras su cronología de ejecución se ha extendido. Sigue directamente las notas de las llamadas All Core Devs Execution de ethereum/pm para la próxima actualización de devnet de Glamsterdam en lugar de una fecha fija del calendario, ya que la fecha del calendario ya se ha movido una vez.
Descargo de responsabilidad: El contenido anterior tiene únicamente fines informativos y no constituye asesoramiento financiero. Las inversiones en criptomonedas conllevan un riesgo significativo. Realiza siempre tu propia investigación y consulta con un asesor financiero cualificado antes de tomar decisiones de inversión.
Análisis Cripto Semanales
Análisis de mercado y insights accionables. Sin spam, nunca.