Saltar al contenido principal

Glamsterdam se retrasa: la reforma MEV de Ethereum choca con la realidad de la ingeniería mientras ePBS llega tarde

· 14 min de lectura
Dora Noda
Dora Noda
Software Engineer

Por primera vez en la cadencia acelerada de bifurcaciones (forks) de Ethereum para 2026-2027, la hoja de ruta ha parpadeado. A mediados de abril de 2026, los desarrolladores principales reconocieron públicamente lo que los equipos de clientes habían susurrado durante semanas: la Separación Proponente-Constructor Integrada (ePBS, Enshrined Proposer-Builder Separation) — la pieza más ambiciosa del hard fork Glamsterdam — es "más complicada de lo previsto", y la ventana original para la red principal (mainnet) de mayo-junio está casi con seguridad fuera de alcance. El retraso empuja a Glamsterdam hacia el Q3 o Q4 de 2026, reduciendo el margen con la ya programada bifurcación Hegota y reabriendo una pregunta que Ethereum pensaba haber resuelto: ¿puede una capa base de cinco clientes seguir actualizándose al ritmo que exige una economía L2 post-Pectra?

La respuesta importa mucho más allá del propio ecosistema de Ethereum. Cada semana que ePBS permanece en la red de desarrollo (devnet) es una semana en la que el actual oligopolio de repetidores (relays) de Flashbots sigue mediando decenas de miles de millones en flujos anuales de MEV, una semana en la que las L2 siguen fijando el precio de los blobs frente a una curva de oferta que se suponía que la bifurcación debía flexibilizar, y una semana en la que Solana — que aseguró un 98.27 % de aprobación de los validadores para su revisión de consenso Alpenglow en septiembre de 2025 — amplía su ventaja con una cadencia de actualización monolítica notablemente más rápida. Glamsterdam nunca fue solo otro hard fork. Fue la respuesta de Ethereum a la tesis de la "L1 rápida". La respuesta ahora llega tarde.

Las dos EIP que definen Glamsterdam​

Glamsterdam — un término compuesto por Gloas (el nombre en clave de la capa de consenso) y Ámsterdam (el nombre en clave de la capa de ejecución, siguiendo la tradición de la ciudad anfitriona de la Devcon) — está anclado por dos EIP principales que juntos reformularían cómo Ethereum produce bloques.

EIP-7732 (ePBS) divide el bloque de consenso del bloque de ejecución a nivel de protocolo. Hoy en día, los validadores que ejecutan MEV-Boost delegan la construcción de bloques a un mercado de constructores ajenos al protocolo a través de repetidores centralizados. La propia migración de Flashbots en diciembre de 2024 de todos los constructores y el flujo de órdenes a BuilderNet fue en sí misma una admisión de que la arquitectura de repetidores crea un riesgo de concentración. ePBS integra la división: los proponentes y los constructores se convierten en participantes del protocolo de primera clase que interactúan directamente, sin necesidad de repetidores.

EIP-7928 (Listas de acceso a nivel de bloque) hace que los bloques declaren de antemano su huella de lectura / escritura — cuentas y espacios de almacenamiento afectados —. Los clientes pueden entonces paralelizar la ejecución y la verificación, reduciendo el tiempo que un bloque permanece en propagación. Combinado con ePBS, el par apunta a una reducción de ~ 50 % en la latencia efectiva de los bloques.

Sobre el papel, estas se complementan perfectamente. En la implementación, están interactuando con cada otra pieza de la pila post-Pectra — incluyendo la consolidación de validadores MaxEB de la EIP-7251, ya lanzada en Pectra — de formas que las especificaciones originales no anticiparon plenamente.

Lo que realmente se retrasó​

La llamada de consenso de todos los desarrolladores principales (All Core Developers Consensus, ACDC #177) del 16 de abril de 2026 dejó clara la realidad de la ingeniería. Hasta este mes, las pruebas estaban bifurcadas en dos redes separadas: epbs-devnet para la separación proponente-constructor, y bals-devnet para las listas de acceso. La "devnet generalizada" que las fusiona — el primer entorno donde coexisten todos los componentes de Glamsterdam — solo recibió luz verde después de que Lighthouse y un puñado de otros clientes de consenso produjeran versiones estables durante la ventana de interoperabilidad de abril.

"ePBS Devnet Zero se trata menos de rendimiento y más de interoperabilidad", señaló un ingeniero de clientes en el resumen de la llamada. Traducción: todavía estamos descubriendo qué se rompe cuando cinco clientes de consenso y cinco clientes de ejecución interpretan la especificación de forma independiente. Las primeras ejecuciones producen principalmente bloques vacíos — no es un fallo estructural, sino una señal de que el camino ideal todavía se está pavimentando, por no hablar del camino adversario —.

Las consecuencias en el cronograma se acumulan:

  • Devnet Zero debe estabilizarse en Lighthouse, Prysm, Teku, Nimbus y Lodestar en el lado del consenso, además de Geth, Nethermind, Besu, Erigon y Reth en el lado de la ejecución.
  • Devnet One y Two necesitan sacar a la luz errores de interacción entre ePBS, BAL (listas de acceso), el ajuste de precios del gas y las más de 25 EIP no principales bajo consideración.
  • Redes de prueba públicas (sucesoras de Holesky, Sepolia) necesitan al menos 6-8 semanas de actividad de bifurcación en la sombra (shadow-fork) antes de que se pueda establecer de forma creíble cualquier fecha objetivo para la red principal.
  • Versiones de los clientes deben ser finalizadas, auditadas y distribuidas a los stakers con suficiente antelación para que un problema de elección de bifurcación en la red principal no se convierta en un incidente de disponibilidad (liveness).

Cada paso se mide en semanas, no en días. Un lanzamiento en mayo-junio requería que la Devnet Zero fuera estable en febrero. No lo fue. Junio-julio requería estabilidad en marzo. No lo fue. Para abril, las cuentas simplemente no salen — de ahí el discreto reconocimiento de que la bifurcación principal se está deslizando hacia el H2 de 2026 —.

La paradoja de la diversidad de clientes​

La diversidad de cinco clientes de ejecución de Ethereum es posiblemente su propiedad de neutralidad creíble más valiosa — un error en un solo cliente no puede derribar la red —. Pero esa diversidad es también la razón por la que Glamsterdam es difícil.

Cada equipo de implementación debe construir, probar y estabilizar ePBS de forma independiente. Cada uno saca a relucir diferentes casos límite. Las actas de la ACDC de abril describen "solicitudes de extracción (pull requests) pendientes" en múltiples clientes y señalan que los cambios en las especificaciones de consenso podrían bloquear la ePBS Devnet Two por completo hasta que se resuelvan. Este es precisamente el impuesto de coordinación que una cadena de una sola implementación no paga.

Comparemos con la cadencia de Solana. Alpenglow, el reemplazo de consenso de Solana que apunta a una finalidad determinista de 100-150 ms, pasó una votación de validadores con un 98.27 % de apoyo — uno de los mandatos más fuertes en la historia de la red — en septiembre de 2025. El plan de despliegue es sencillo: el cliente Agave de Anza lanza la actualización en el Q3 de 2026; Firedancer, la segunda implementación de Jump Crypto, le sigue. Debido a que Solana efectivamente tuvo un solo cliente de producción hasta que Firedancer superó el 20 % de participación (stake) en la red principal a principios de este año, su superficie de coordinación es una fracción de la de Ethereum.

Esta no es una observación neutral. Las cadenas monolíticas lanzan actualizaciones más rápido. Las cadenas multicliente las lanzan de forma más segura. El retraso de Glamsterdam es el precio de la elección arquitectónica de Ethereum — y por primera vez desde el Merge, el mercado está sopesando si ese precio todavía vale la pena pagarlo —.

Lo que significa el retraso para las L2 y el MEV​

El fork Pectra se lanzó en 2025 según lo previsto. Fusaka añadió PeerDAS y amplió la capacidad de blobs poco después. Los equipos de L2 construyeron sus planes de capacidad para 2026 en torno al aterrizaje de Glamsterdam en el segundo trimestre (Q2), con una mayor expansión de blobs y la redistribución de MEV llegando para satisfacer la creciente demanda de rollups.

Esos planes ahora deben rediseñarse.

Precios de blobs. Se esperaba que Glamsterdam aumentara aún más el número de blobs por bloque — potencialmente a 72 o más — brindando a los rollups optimistas y ZK una disponibilidad de datos significativamente más barata. Un retraso hacia el Q3 - Q4 significa 2 - 4 meses más de suministro de blobs ajustado, lo que importa más para los rollups que ya han saturado sus carriles de tarifas.

Redistribución de MEV. La arquitectura MEV-boost actual recompensa a los constructores (builders) más grandes de manera desproporcionada. Los rendimientos superlineales en la agregación de flujo de órdenes significan que, una vez que un constructor asegura una ventaja, la economía empuja hacia el monopolio. ePBS no elimina el MEV, pero elimina el relé como un cuello de botella de coordinación — lo que debería, en teoría, redistribuir una fracción de la extracción actual de vuelta a los proponentes (proposers) y, aguas abajo, a los stakers. Cada mes de retraso es un mes en el que persisten las dinámicas de MEV existentes.

Competencia de L2. Base ya ha alcanzado tiempos de bloque de 2 segundos. Arbitrum y Optimism están lanzando sus propias mejoras de secuenciador y disponibilidad de datos (DA) en cadencias independientes. Cuanto más tiempo persista el cuello de botella en la L1, más divergirán las hojas de ruta de las L2 de cualquier actualización unificada de la L1 — y más se convertirá la "hoja de ruta centrada en rollups" en N hojas de ruta de rollups separadas que casualmente liquidan en la misma capa base.

La cuestión de FOCIL y la presión de Hegota​

Una de las decisiones más trascendentales de la ACDC de abril fue trasladar las Listas de Inclusión de Elección de Fork (FOCIL) fuera de Glamsterdam y hacia Hegota, donde ha sido seleccionada formalmente como la protagonista de la capa de consenso para finales de 2026.

FOCIL es la respuesta de Ethereum a la resistencia a la censura — un mecanismo que permite que un comité de proponentes imponga colectivamente la inclusión de transacciones, de modo que ningún constructor individual pueda excluir sistemáticamente cargas útiles (direcciones sancionadas por la OFAC, por ejemplo). El equipo de ingeniería de Base había advertido públicamente que agrupar FOCIL con ePBS retrasaría Glamsterdam más allá de 2026 por completo. Sacarlo alivia el calendario de Glamsterdam — a costa de comprimir la ventana entre la eventual activación de la red principal (mainnet) de Glamsterdam y la de Hegota.

Si Glamsterdam se lanza en el Q4 de 2026 y Hegota apunta a finales del Q4, la brecha podría ser de tan solo 6 - 8 semanas. Ese es un margen de tiempo corto para que los validadores, constructores de bloques, proveedores de staking y equipos de L2 absorban un cambio de protocolo antes de que llegue el siguiente. La hoja de ruta de Hegota también incluye un trabajo significativo sobre el crecimiento del estado (state bloat) — las discusiones iniciales se han centrado en los árboles Verkle (Verkle Trees), que reducirían los requisitos de hardware de los nodos pero requerirían sus propias pruebas exhaustivas.

El escenario que Ethereum está planeando silenciosamente ahora: dos forks principales aterrizando con un trimestre de diferencia, sobre una matriz de pruebas que Solana lanza en una sola actualización coordinada.

Por qué esto no es una crisis — todavía​

Sería un error interpretar el retraso de Glamsterdam como algo existencial. El proceso de forks de Ethereum está funcionando exactamente como fue diseñado. ePBS se está retrasando no porque la coordinación haya fallado, sino porque la coordinación detectó un problema — ambigüedades en las especificaciones y casos extremos de implementación — antes de que llegaran a la red principal. La alternativa, lanzar según lo previsto y apagar incendios de errores reales de elección de fork con más de $ 400 mil millones en valor liquidado en juego, es inconmensurablemente peor.

La pregunta más profunda es si la cadencia actual de Ethereum es sostenible a medida que crece la complejidad por fork. Glamsterdam no son solo dos EIP; son dos características principales más de 25 + cambios menores, cada uno interactuando con un conjunto de validadores post-Pectra que ya tiene consolidación maxEB, blobs habilitados por PeerDAS y un ecosistema L2 maduro encima. Cada nuevo fork amplía la matriz de pruebas.

Se han planteado propuestas para dividir Glamsterdam en sí — lanzando BALs en el Q3 y ePBS en el Q1 de 2027 — y hasta ahora han sido rechazadas. El contraargumento es convincente: las BALs sin ePBS ofrecen un valor marginal, porque las ganancias de ejecución paralela se ven obstaculizadas por la arquitectura actual de los constructores. Las características son genuinamente complementarias, y desagruparlas ahorra tiempo a costa de la coherencia de la actualización.

Qué vigilar en los próximos 90 días​

Para desarrolladores, stakers y cualquier persona que fije el precio del espacio de bloque de L2 para la segunda mitad de 2026, tres señales importan:

  1. Estabilidad de la Devnet Zero. Si la devnet generalizada funciona más de 30 días sin un incidente crítico para principios de junio, un objetivo para el Q3 de 2026 se vuelve creíble. Si no es así, el Q4 es el suelo.
  2. Activación de la red de prueba pública. El sucesor de Holesky y Sepolia necesitan hacer el fork al menos 8 semanas antes de la red principal. Sin fecha de fork en la red de prueba = sin fecha de fork en la red principal.
  3. Selección de EIP de Hegota. El protagonista de Hegota en febrero de 2026 fue FOCIL; el protagonista de la capa de ejecución aún se está debatiendo. Lo que se elija restringirá aún más qué tan estrechamente se pueden secuenciar los dos forks.

La hoja de ruta 2026 - 2027 de Ethereum siempre fue ambiciosa. El retraso de Glamsterdam es el primer recordatorio concreto de que ambicioso no significa puntual. Para una red cuya credibilidad se basa en hacer cosas difíciles con cuidado, un retraso medido no es un fracaso. Es la característica principal.

BlockEden.xyz opera infraestructura de Ethereum de grado empresarial a través de Pectra, Fusaka y cada etapa de red de prueba para las reglas del fork de Glamsterdam. Si está desarrollando frente a un objetivo de actualización móvil y necesita nodos que sigan la red principal, las redes de prueba y las devnets en paralelo, explore nuestros servicios de API de Ethereum — infraestructura diseñada para equipos que no pueden permitirse un estado bifurcado en el lado equivocado de un cambio de especificación.

Fuentes​

Share on Twitter