Glamsterdam: por qué ePBS retrasa el fork de Ethereum

El próximo hard fork de Ethereum, Glamsterdam, ya no llega en verano: la Ethereum Foundation lo ha movido a la segunda mitad de 2026 —finales de agosto como mejor caso, sin fecha de mainnet anunciada— y el cuello de botella tiene nombre propio: EIP-7732, conocido como ePBS. ePBS (enshrined Proposer-Builder Separation, separación proponente-constructor inscrita en el protocolo) es la pieza que reescribe cómo se construyen los bloques de Ethereum, y su complejidad —sumada a una interacción aún no testeada con las nuevas listas de acceso a nivel de bloque— es lo que ha frenado el calendario. Para los grandes stakers institucionales que hoy concentran buena parte de la red —Lido con unos 8,72 millones de ETH y Coinbase con cerca de 4,5 millones— no es un detalle técnico lejano: ePBS cambia de raíz de quién depende su operativa de construcción de bloques. Este artículo explica por qué se ha retrasado, qué cambia operativamente para quien hace staking y cuál es la cronología real de devnets a mainnet.

¿Qué es exactamente Glamsterdam y qué trae ePBS?

Glamsterdam es el nombre en clave del hard fork (actualización de la red que requiere que todos los nodos adopten las nuevas reglas a la vez) que sucede a Pectra, activado en mainnet el 7 de mayo de 2025. El paquete combina varias mejoras, pero la que domina el debate y marca el ritmo es EIP-7732, ePBS.

Para entender ePBS conviene fijar cuatro términos. El proposer es el validador al que el protocolo asigna el turno de proponer el siguiente bloque. El builder es quien ensambla el contenido de ese bloque: ordena las transacciones para maximizar su valor. El MEV (Maximal Extractable Value, valor máximo extraíble) es precisamente ese valor que se puede capturar reordenando, incluyendo o excluyendo transacciones dentro de un bloque. Y el relay es el intermediario externo que hoy conecta a builders y proposers para que el reparto sea de fiar sin que se vean las tripas del bloque por adelantado.

La analogía que mejor lo captura: el proposer elige el menú —qué slot se va a servir y bajo qué condiciones—, pero el builder es quien cocina el plato, decide el orden de los ingredientes y se queda con la propina del MEV. Hoy ese reparto entre quien elige el menú y quien cocina lo arbitra un intermediario de confianza fuera del protocolo: el relay, dentro del sistema MEV-Boost. ePBS coge ese arreglo y lo mete dentro de las reglas de Ethereum: el mercado de builders deja de depender de relays externos y pasa a estar inscrito (de ahí «enshrined») en el propio protocolo. La mecánica económica de por qué este reparto importa —y de cómo el MEV pasó de plaga a inscribirse y redistribuirse— está desarrollada en nuestro análisis de la Era III del MEV; quien parta de cero encontrará la base en qué es el MEV.

Junto a ePBS, Glamsterdam incorpora EIP-7928 (Block-Level Access Lists, BALs), que adjuntan a cada bloque la lista de cuentas y almacenamiento que las transacciones van a tocar, habilitando ejecución más paralela; y un paquete de reajuste de los precios de gas (gas repricing, en el que EIP-7904 es uno de los varios EIP implicados). FOCIL (Fork-Choice Inclusion Lists), que se daba por candidato, se ha movido a Hegotá, el fork posterior, precisamente para no cargar más a Glamsterdam.

¿Por qué se ha retrasado Glamsterdam?

El retraso no es un fallo: es cautela de ingeniería. ePBS es de las modificaciones más invasivas de la capa de consenso desde la transición a Prueba de Participación, porque cambia el flujo por el que un bloque pasa de proponerse a confirmarse. Hay dos causas técnicas concretas detrás del deslizamiento del calendario.

La primera es la complejidad intrínseca de implementar EIP-7732. Que el reparto proposer-builder viva dentro del protocolo obliga a coordinar pagos «trustless» (sin intermediario de confianza) entre ambas partes, a redefinir cómo y cuándo se valida el payload del bloque, y a que todos los clientes de consenso implementen la misma lógica de forma compatible. No es código que se prueba en una tarde.

La segunda es la interacción no testeada a escala mainnet entre ePBS y las BALs (EIP-7928). Cada una por separado es manejable; el problema es que se pisan. Las BALs adelantan a qué cuentas y almacenamiento tocará cada transacción para poder paralelizar la ejecución, mientras que ePBS separa el momento en que se compromete un bloque del momento en que se valida su payload. Combinar ambas crea caminos de ejecución nuevos —qué se sabe del contenido del bloque y cuándo— que solo afloran bajo carga real y con muchos clientes distintos hablando entre sí. Por eso el proceso se está tomando los devnets que haga falta antes de tocar testnets públicos: un fallo de consenso aquí no es un bug cualquiera, es una bifurcación de la cadena.

A esto se sumó una decisión de alcance. El equipo de ingeniería de Base (la L2 de Coinbase) alertó de que incluir FOCIL además de ePBS habría empujado el fork más allá de 2026. La respuesta fue sacar FOCIL del paquete y trasladarlo a Hegotá, el fork siguiente. Es la lógica que ha guiado todo el rediseño de Glamsterdam: en lugar de meter todo lo deseable y arriesgar un fork imposible de cerrar, se acota el alcance a ePBS más las dos EIP de soporte (BALs y gas repricing) y se aplaza el resto. Recortar ambición para proteger la fecha es, en sí mismo, una señal de madurez del proceso.

Conviene precisar el marco temporal para no caer en titulares engañosos. ethereum.org ya clasifica Glamsterdam como actualización de la segunda mitad de 2026. El objetivo interno aspiracional ronda finales de agosto de 2026, sin fecha de mainnet anunciada, con riesgo real de deslizarse hacia el cuarto trimestre si ePBS necesita más iteraciones en testnet. No se trata de un retraso respecto a la ventana prevista: el fork sigue dentro de su franja de la segunda mitad de 2026, pero con la pieza más pesada todavía endureciéndose.

¿Qué cambia operativamente para Lido y Coinbase?

Aquí está el verdadero diferencial, porque afecta a quien concentra la red. Hoy más del 90% del mercado de builders opera a través de MEV-Boost, con relays externos de actores como Flashbots o bloXroute (con Commit-Boost ganando terreno, en torno a un 20% de adopción como alternativa de middleware). Eso significa que un gran operador de staking, cuando le toca proponer un bloque, no construye el contenido: lo subasta a builders a través de un relay y se queda con la oferta más alta. La construcción de bloques —y la captura de MEV asociada— está externalizada a un puñado de intermediarios fuera del protocolo.

ePBS reescribe esa dependencia. Al inscribir el mercado de builders en el protocolo, el reparto proposer-builder deja de requerir un relay de confianza: el propio Ethereum garantiza que el proposer cobra y que el builder entrega. Para Lido, Coinbase y cualquier operador grande, esto cambia el punto de control y el perfil de riesgo de su operativa de construcción de bloques —menos dependencia de infraestructura de terceros, reglas de reparto más predecibles—, aunque el rediseño introduce requisitos nuevos (por ejemplo, capital inmovilizado para los builders inscritos) cuyo efecto sobre la competencia del mercado de builders es uno de los puntos en disputa.

El contexto de por qué esto pesa tanto: el staking de Ethereum está en máximos, con el mercado vigilando de cerca la arquitectura de quién valida. Lido lidera con unos 8,72 millones de ETH (en torno al 24% del staking total) y Coinbase gestiona cerca de 4,5 millones (alrededor del 12%, dato del primer trimestre de 2026). Ese contexto de staking récord lo cubrimos en la paradoja staking-ETF, y el estado concreto de Lido en staking institucional con stETH. Que el cap por validador subiera de 32 a 2.048 ETH con Pectra (EIP-7251) no hizo sino concentrar más stake por nodo, lo que vuelve más urgente resolver la centralización de la construcción de bloques que ePBS persigue atacar.

¿A quién afecta más el cambio y de qué forma?

El impacto no es uniforme. Conviene separarlo por tipo de actor, porque cada uno entra a ePBS desde una posición distinta.

El reparto desigual tiene un matiz que merece subrayarse para los builders. Hoy un puñado de builders profesionales captura la mayoría del flujo de MEV porque controlan la relación con los relays y la infraestructura de subasta. ePBS no elimina la ventaja del builder especializado —ordenar transacciones para extraer valor sigue siendo un negocio de escala—, pero al inscribir las reglas en el protocolo y exigir capital inmovilizado a los builders inscritos, cambia las palancas de la competencia. Si esa barrera de capital consolida a los grandes o, al contrario, abre hueco a nuevos entrantes al quitar de en medio al relay como guardián, es justamente el punto que nadie puede afirmar con certeza todavía y que el propio debate de Sigma Prime dejó abierto.

Para el inversor que no opera nodos, lo relevante es que el mercado vigila la fecha de Glamsterdam como señal sobre la salud del roadmap de Ethereum. Análisis bajistas como el de JPMorgan sobre el bajo rendimiento estructural del ETH usan precisamente la ejecución del roadmap como uno de sus ejes: un retraso ordenado y comunicado no es lo mismo que uno caótico, y los equipos están eligiendo lo primero. El staker que delega en Lido o Coinbase no nota nada de esto en su rendimiento del día a día; lo que cambia es la solidez de la infraestructura sobre la que descansa ese rendimiento.

¿Hay consenso en incluir ePBS en este fork?

No del todo, y la tensión es instructiva. El debate más citado partió de Sigma Prime, empresa detrás del cliente de consenso Lighthouse, y conviene retratarlo con precisión porque la posición de la casa no fue monolítica. Internamente hubo desacuerdo: Dapplion argumentó en contra de inscribir EIP-7732 en Glamsterdam, sosteniendo que enshrinar la separación proposer-builder hoy es innecesario —MEV-Boost funciona con incidencias mínimas, parte de los beneficios de escalado se logran con «payload split + delayed execution» sin necesidad de pagos trustless, y la red tiene margen para esperar un ciclo de fork más—. Su matiz: «si hay que enviar alguna forma de ePBS ya, votaré por programar EIP-7732 para Glamsterdam», reconociéndolo como la especificación más madura disponible.

Frente a esa posición, Mark Mackey lo defendió como headliner del fork, y la empresa acabó apoyando su inclusión. Es decir: no es «Sigma Prime en contra», sino un debate interno resuelto a favor, con argumentos serios en ambos lados que vale la pena conocer antes de leer titulares simplificadores. El eje de la discusión —¿se inscribe ePBS ahora o se espera?— es exactamente lo que un análisis de fuera no puede destilar sin haber leído las fuentes primarias. CleanSky no toma partido: expone que la cautela del cronograma y la propia existencia de este debate explican por qué el fork avanza despacio y bien acompañado de revisión técnica.

¿Cuál es la cronología real de devnets a mainnet?

El camino de un cambio de consenso de Ethereum tiene fases bien definidas: primero devnets (redes de prueba internas de los equipos de cliente), luego testnets públicos (Sepolia, Hoodi) y finalmente mainnet. Glamsterdam está todavía en la primera fase.

• A lo largo de 2024 — MEV-Boost consolida su dominio de la construcción de bloques (más del 90% del mercado de builders).
• 7 de mayo de 2025 — Pectra se activa en mainnet; el cap por validador sube de 32 a 2.048 ETH (EIP-7251).
• Principios de 2026 — Glamsterdam se perfila como el siguiente fork, con ePBS (EIP-7732) como pieza principal.
• ~Primera semana de mayo de 2026 — Concluye el devnet Soldøgn (fase de interoperabilidad entre clientes); Devnet-4 queda completo.
• Junio de 2026 (actual) — devnets de Glamsterdam activos (la línea de ePBS+BALs todavía en pruebas); testnets públicos (Sepolia, Hoodi) todavía pendientes.
• Finales de agosto de 2026 (mejor caso) — Objetivo aspiracional de activación, sin fecha de mainnet confirmada.
• Cuarto trimestre de 2026 (riesgo) — Ventana alternativa si ePBS requiere más iteraciones de testnet.

La lectura honesta de esta cronología es que el progreso es real pero la incertidumbre vive en el último tramo: el salto de devnets a testnets públicos es el siguiente hito a vigilar, y de su limpieza dependerá si finales de agosto sigue siendo plausible o el fork se desliza a otoño.

¿Qué queda como lectura para el staker?

Tres ideas para quien hace staking o invierte en ETH. Primero, el retraso de Glamsterdam es señal de disciplina, no de descomposición: el equipo prefiere endurecer ePBS en devnets antes que enviar a mainnet una reescritura del flujo de bloques con interacciones no testeadas. Segundo, el cambio operativo de fondo es que el mercado de builders pasa de depender de relays externos —donde se concentra hoy más del 90% del flujo— a estar inscrito en el protocolo, lo que reduce la dependencia de terceros para Lido, Coinbase y validadores independientes. Tercero, la fecha no está cerrada: finales de agosto de 2026 es el mejor caso, el cuarto trimestre es el riesgo, y el indicador a seguir es el salto de los devnets a los testnets públicos (Sepolia y Hoodi).

Para quien quiera profundizar en la mecánica económica del MEV que ePBS reordena, el desarrollo está en nuestro análisis de la Era III del MEV. Glamsterdam no es el final de esa historia: es el momento en que Ethereum decide meter el mercado de builders dentro de sus propias reglas.

Fuentes y enlaces: ethereum.org — roadmap Glamsterdam · Ethereum Foundation — Checkpoint #9 · Sigma Prime — debate sobre EIP-7732 · Everstake — Glamsterdam explicado · Figment — qué significa para stakers institucionales