Ethereum activa Glamsterdam en Sepolia el 6 de octubre. Alpenglow de Solana ya está disponible en la red de pruebas. Ambas actualizaciones reescriben la mecánica de la capa de consenso durante el mismo mes. Este informe compara ambos cambios con datos.
Qué es Glamsterdam
Glamsterdam es la próxima bifurcación dura de Ethereum, programada para el cuarto trimestre de 2026 en la red principal. Combina dos actualizaciones de capa: Amsterdam (ejecución) y Gloas (consenso). La Fundación Ethereum confirmó la activación en la red de pruebas Sepolia en la época 353,024, ranura 11,296,768, el 6 de octubre a las 13:53:36 UTC.
La actualización se registra como Meta EIP-7773. Incluye diez EIP en las capas de consenso y ejecución. Las dos propuestas principales son EIP-7732 y EIP-7928. Estas dos EIP funcionan como un par interdependiente.
EIP-7732: separación consagrada entre proponente y constructor
Hoy, más del 90 % de los bloques de Ethereum son construidos por relés externos de MEV-Boost. Los cuatro principales constructores representan más del 90 % de todos los bloques (puntuación HHI: 3.892). Estos relés operan completamente fuera de la cadena, sin rendir cuentas al protocolo.
EIP-7732 incorpora directamente al protocolo de consenso la separación entre proponente y constructor. El constructor pasa a ser un actor de la capa de consenso con fondos en staking. El proponente se compromete con la oferta de un constructor. Luego, el constructor revela la carga útil. Un nuevo comité de puntualidad de carga útil (PTC) certifica si los datos llegaron a tiempo.
ePBS también amplía la ventana de propagación de datos de 2 a aproximadamente 9 segundos. Esto permite bloques más grandes y más capacidad para blobs por slot sin superar el plazo de 12 segundos del slot.
EIP-7928: listas de acceso a nivel de bloque
Como muestra el gráfico, el consumo diario de gas de Ethereum ha aumentado históricamente en escalones discretos junto con los incrementos del límite de gas por bloque, y se ha mantenido en torno a los 215–220 mil millones de gas diarios en 2026. EIP-7928 habilita tres cambios concretos en la ejecución para aumentar esta capacidad de forma segura: lecturas paralelas del disco entre núcleos de CPU, validación paralela de transacciones y reconstrucción del estado sin ejecución para clientes ligeros. En conjunto, estas optimizaciones permiten escalar de forma segura hasta un límite de 200M de gas en hardware estándar para validadores.
Sin EIP-7928, triplicar el límite de gas por encima de los niveles diarios actuales implicaría una sobrecarga de ejecución secuencial proporcionalmente mayor para cada validador. Devnet-11 ejecutó con éxito 84.000 validadores simulados con 200M de gas sin fallos de finalidad, lo que allanó el camino para la activación en la red de pruebas Sepolia el 6 de octubre.
Cambios en los precios del gas: EIP-8037 y EIP-8038
Glamsterdam reajusta el precio de dos categorías de acceso al estado. EIP-8037 aumenta el costo de crear nuevas entradas de estado. EIP-8038 actualiza el costo de leer el estado existente. El reajuste alinea mejor los costos de gas con el uso real de recursos de hardware. Los desarrolladores de aplicaciones deben probar sus contratos con las nuevas reglas antes de la red principal.
Calendario de activación de Glamsterdam
RedFechaEstadoNotasRed de pruebas Sepolia6 oct 2026 (13:53:36) UTCConfirmadoÉpoca 353.024 / Slot 11.296.768Red de pruebas Hoodi27 oct 2026 (provisional)No confirmadoSujeto a la estabilidad de SepoliaRed principalT4 2026 (sin fecha)No confirmadoAnuncio por separado pendiente
Los operadores de Arbitrum Sepolia deben actualizar a Nitro v3.11.4 antes del 6 de octubre. Glamsterdam añade nuevos campos a los encabezados de los bloques de Ethereum. Los lotes calculados antes de la bifurcación e incluidos después podrían fallar con las nuevas reglas de gas.
Prysm 7.2.0 establece por defecto un límite de gas de 60M tras la activación. Los validadores que apunten a 200M deben configurarlo manualmente mediante un archivo de configuración de proponente versión 2 o la API de keymanager. La opción «suggested-gas-limit» no tendrá efecto después de la bifurcación Gloas.
Qué es Alpenglow
Alpenglow es el mayor cambio de protocolo de Solana desde su lanzamiento. Reemplaza TowerBFT, el mecanismo de consenso actual, por un sistema de dos componentes llamado Votor y Rotor. La actualización superó la votación de gobernanza de los validadores (SIMD-0326) en septiembre de 2025, con un 98,27 % de aprobación y un 52 % de los tokens en staking participantes.
Alpenglow se activó en el clúster de pruebas comunitario dedicado y, después, en la red de pruebas durante la última semana de septiembre de 2026. La activación en la red principal llegará con Agave 4.3, prevista para octubre de 2026, sin una altura de bloque confirmada.
Fase 1: Votor
Con el consenso TowerBFT heredado de Solana, la red paga un alto costo de rendimiento: cada voto de cada validador debe procesarse y enviarse como una transacción estándar en la cadena. Estos votos de mantenimiento del consenso congestionan habitualmente el libro mayor y consumen enormes cantidades de espacio de bloque. El seguimiento académico de transacciones desde principios de 2024 hasta el primer trimestre de 2026 (según el gráfico) confirma que las transacciones de voto (en rosa) representaron sistemáticamente un promedio del 71,5 % y hasta aproximadamente el 75 % del total de transacciones en Solana, lo que infla artificialmente las métricas de rendimiento.
Votor elimina esta sobrecarga estructural al sacar por completo de la cadena las transacciones de voto. Los validadores intercambian certificados de firma BLS directamente entre pares y fuera de la cadena, y envían a la cadena un único certificado agregado de aproximadamente 1.000 bytes por bloque, en lugar de millones de transacciones de voto individuales. Esto libera estructuralmente más del 70 % de la capacidad actual de los bloques para transacciones reales de los usuarios.
Para lograrlo, Votor ejecuta dos vías de finalización simultáneas: una vía rápida, en la que los bloques finalizan en una sola ronda de votación, y una vía lenta, en la que una segunda ronda completa la finalización si responden menos validadores dentro del plazo. El objetivo combinado es alcanzar una finalidad económica de 100 a 150 milisegundos, lo que implica una reducción del 99 % en el tiempo de espera respecto de los 12,8 segundos actuales.
Tolerancia a fallos: del 33 % al 20 % + 20 %
TowerBFT requiere que más de dos tercios de la participación (67 %) sean honestos y estén en línea para que el consenso avance. Si el 34 % de los validadores de una red son adversarios, TowerBFT se paraliza.
Votor cambia el modelo de fallos. Tolera simultáneamente hasta un 20 % de participación adversaria y un 20 % de participación fuera de línea, lo que significa una resiliencia combinada del 40 % ante fallos por caída. La contrapartida es un umbral adversario bizantino más estricto (del 33 % al 20 %). Al reducir ese umbral, Votor puede finalizar en una sola ronda en vez de dos, lo que permite alcanzar el objetivo de 150 ms.
La prueba de seguridad que sustenta Votor fue desarrollada por Anza en colaboración con investigadores de ETH Zurich. Está verificada formalmente y no se basa en simulaciones, a diferencia del modelo de seguridad empírico de TowerBFT.
Fase 2: Rotor
Rotor reemplaza a Turbine, el protocolo actual de propagación de datos de bloques de Solana. Turbine usa un árbol de nodos de varios saltos para distribuir los datos de los bloques entre los validadores. Rotor reemplaza el árbol por una única capa de retransmisión, reduciendo los saltos de propagación. Rotor no tiene una fecha de activación confirmada y no forma parte del lanzamiento de Agave 4.3.
Comparación lado a lado
DimensiónEthereum GlamsterdamSolana Alpenglow (Votor)Tipo de actualizaciónBifurcación dura (cambio coordinado)Activación de función (supermayoría de participación)Fecha de la red de pruebasSepolia, 6 oct (confirmado)Red de pruebas activa desde el 24-25 sep (confirmado)Fecha de la red principalT4 2026 (sin fecha confirmada)Agave 4.3 (prevista para octubre, pero sin fecha clara)Cambio en la finalidadNinguno en esta actualizaciónDe 12,8 s a 100–150 ms (reducción del 99 %)Cambio en el rendimientoDe 60M a 200M de gas/bloque (3,3 veces)Se libera el 75 % del espacio de bloque ocupado por transacciones de votoCambio en retransmisión/confianzaMás del 90 % de los bloques mediante relés externos fuera de la cadenaSin cambios en los relésTolerancia a fallosSin cambios (máximo del 33 % de participación adversaria)20 % de participación adversaria + 20 % fuera de líneaTipo de prueba de seguridadSimulación y pruebas empíricasVerificación formal (ETH Zurich)Impacto en las tarifasSe prevé que las transferencias de ETH sean un 71 % más baratasAhorro en las tarifas de voto: aproximadamente 0,56 SOL por épocaFase 2 programadaRed de pruebas Hoodi, 27 oct (provisional)Rotor (sin fecha confirmada)Lo que NO solucionaLa velocidad de finalidad. Los supuestos de confianza de las L2.El rendimiento bruto. La propagación de bloques.
Diferencias clave en el enfoque
Según los datos actuales de la red en vivo destacados por Chainspect, existe un marcado contraste en la finalidad económica de referencia: Solana tarda actualmente 12,8 segundos en alcanzar el estado de finalidad completa con TowerBFT, mientras que Ethereum necesita 12 minutos y 48 segundos.
Alpenglow aborda directamente esta diferencia en Solana: usa Votor para reducir ese retraso de 12,8 segundos a 100–150 milisegundos en condiciones de consenso de vía rápida. Lo consigue eliminando las transacciones de voto, que actualmente consumen hasta el 75 % del espacio de bloque de Solana. Así libera indirectamente una enorme capacidad para las transacciones de los usuarios, sin aumentar directamente por sí solo el rendimiento bruto de las transacciones.
En cambio, Glamsterdam deja intacta la finalidad de Ethereum, de 12 min y 48 s, y se centra en escalar la capacidad de ejecución de un solo bloque de 60M a 200M de gas. Al hacer que sea más seguro construir bloques más grandes y ejecutarlos en paralelo, Glamsterdam amplía 3,3 veces el límite de gas para expandir el espacio de bloque.
En definitiva, ninguna de las dos actualizaciones resuelve el problema que aborda la otra: la finalidad de Ethereum a lo largo de varias épocas permanece intacta, y el motor central de transacciones de Solana depende de Votor para ganar velocidad, no para escalar la ejecución bruta. Estas métricas distintas muestran cómo cada red prioriza su principal limitación mediante soluciones paralelas: Ethereum amplía la capacidad del espacio de bloque, mientras que Solana apunta a la liquidación en menos de un segundo.
Qué observar en octubre
Para Ethereum: los datos de Sepolia a partir del 6 de octubre mostrarán si el objetivo de 200M de gas de Devnet-11 se mantiene en condiciones reales de validación. La activación de la red de pruebas Hoodi (provisionalmente el 27 de octubre) es el siguiente hito fijado antes del anuncio de la red principal.
Para Solana: Agave 4.3 no tiene una fecha de lanzamiento confirmada. Al 5 de octubre, la red principal sigue usando TowerBFT. La secuencia es: lanzamiento de Agave 4.3, actualizaciones de los validadores y activación de la función por supermayoría. No existe un número de bloque de activación concreto que pueda supervisarse de antemano.