Este es un seguimiento técnico del borrador de calendario de Glamsterdam del 1 de octubre. La novedad es la diferencia entre versiones del cliente Prysm, no una nueva decisión sobre la actualización de la red principal.
La Ethereum Foundation anunció el 28 de septiembre de 2026 que Gloas, la capa de consenso de Glamsterdam, y Amsterdam, la capa de ejecución, se activarán en Sepolia el 6 de octubre a las 13:53:36 UTC; las fechas para Hoodi y la red principal siguen sin determinarse. La EF también explicó que, aunque Prysm v7.2.0 admite esta bifurcación de prueba, el límite de gas predeterminado para los proponentes seguirá siendo de 60M tras la activación; para proponer bloques de 200M, los validadores deberán configurar explícitamente los ajustes del proponente o utilizar la API de keymanager. `--suggested-gas-limit` dejará de surtir efecto tras la activación de Gloas.
Las notas oficiales de la versión v7.2.1 de Prysm (2026-10-05) indicaron posteriormente que la nueva versión añade `GAS_LIMIT_SCHEDULE` para Sepolia, de modo que, desde esta bifurcación, los validadores usarán por defecto 200M de gas; para usar otro valor, deberán recurrir a los ajustes del proponente, la API de keymanager o una sobrescritura mediante los parámetros pertinentes. Es decir, v7.2.1 corrige la configuración predeterminada del schedule, pero eso no significa que todos los nodos Prysm se actualicen automáticamente. Los validadores aún deben comprobar la versión del cliente, los ajustes del proponente y las versiones correspondientes de la capa de ejecución.
Mi valoración: esto parece más un recordatorio de compatibilidad operativa para la red de pruebas que una señal de que la ampliación de Ethereum ya se haya implementado. Si los nodos usan versiones distintas o conservan una configuración explícita de 60M, podrían aplicar parámetros de propuesta diferentes durante las pruebas, lo que complicaría la resolución de problemas. Aunque Sepolia alcance con éxito 200M de gas, no se puede deducir que la capacidad de los bloques de la red principal vaya a aumentar en la misma medida ni que las tarifas vayan a bajar de inmediato. El efecto sobre $ETH aún dependerá de los resultados de las pruebas, las decisiones posteriores sobre el protocolo y el calendario de la red principal; no se debe tratar esta corrección de versión como un catalizador fundamental a corto plazo.
En cuanto a las medidas, los validadores de Sepolia deberían consultar primero las notas de la versión Prysm v7.2.1 y la tabla de clientes de la EF para verificar la compatibilidad de las versiones de las capas de consenso y ejecución; comprobar si los ajustes del proponente, la configuración de keymanager o los parámetros de la línea de comandos sobrescriben el schedule predeterminado; y, tras actualizar, observar la sincronización de la bifurcación, la propuesta de bloques y la coherencia del límite de gas. Los no validadores y los titulares habituales de la red principal no necesitan migrar fondos ni cambiar sus billeteras por este cambio de versión en la red de pruebas.
A continuación, habrá que estar atentos a si la activación de Sepolia se completa según lo previsto, a si el límite de gas de los bloques cambia de acuerdo con el schedule, a la participación y producción de bloques de los distintos clientes y a si la EF anuncia por separado las fechas de Hoodi o de la red principal. Si se aplaza la bifurcación de prueba, surge una incompatibilidad entre clientes o el plan para la red principal no incorpora el schedule correspondiente, la valoración de que «la configuración de prueba avanza sin problemas» perderá su fundamento. Solo cuando los resultados de las pruebas sean estables y se avance hacia un proceso definido para la red principal, valdrá la pena reevaluar sus efectos a largo plazo en la red.
Fuentes: Ethereum Foundation, «Glamsterdam Testnet Announcement» (2026-09-28): https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement . Versión oficial v7.2.1 de Prysm en GitHub (2026-10-05): https://github.com/OffchainLabs/prysm/releases/tag/v7.2.1 . La información de la Ethereum Foundation sobre las versiones de los clientes también aparece en el anuncio de la red de pruebas.
La Ethereum Foundation anunció el 28 de septiembre de 2026 que Gloas, la capa de consenso de Glamsterdam, y Amsterdam, la capa de ejecución, se activarán en Sepolia el 6 de octubre a las 13:53:36 UTC; las fechas para Hoodi y la red principal siguen sin determinarse. La EF también explicó que, aunque Prysm v7.2.0 admite esta bifurcación de prueba, el límite de gas predeterminado para los proponentes seguirá siendo de 60M tras la activación; para proponer bloques de 200M, los validadores deberán configurar explícitamente los ajustes del proponente o utilizar la API de keymanager. `--suggested-gas-limit` dejará de surtir efecto tras la activación de Gloas.
Las notas oficiales de la versión v7.2.1 de Prysm (2026-10-05) indicaron posteriormente que la nueva versión añade `GAS_LIMIT_SCHEDULE` para Sepolia, de modo que, desde esta bifurcación, los validadores usarán por defecto 200M de gas; para usar otro valor, deberán recurrir a los ajustes del proponente, la API de keymanager o una sobrescritura mediante los parámetros pertinentes. Es decir, v7.2.1 corrige la configuración predeterminada del schedule, pero eso no significa que todos los nodos Prysm se actualicen automáticamente. Los validadores aún deben comprobar la versión del cliente, los ajustes del proponente y las versiones correspondientes de la capa de ejecución.
Mi valoración: esto parece más un recordatorio de compatibilidad operativa para la red de pruebas que una señal de que la ampliación de Ethereum ya se haya implementado. Si los nodos usan versiones distintas o conservan una configuración explícita de 60M, podrían aplicar parámetros de propuesta diferentes durante las pruebas, lo que complicaría la resolución de problemas. Aunque Sepolia alcance con éxito 200M de gas, no se puede deducir que la capacidad de los bloques de la red principal vaya a aumentar en la misma medida ni que las tarifas vayan a bajar de inmediato. El efecto sobre $ETH aún dependerá de los resultados de las pruebas, las decisiones posteriores sobre el protocolo y el calendario de la red principal; no se debe tratar esta corrección de versión como un catalizador fundamental a corto plazo.
En cuanto a las medidas, los validadores de Sepolia deberían consultar primero las notas de la versión Prysm v7.2.1 y la tabla de clientes de la EF para verificar la compatibilidad de las versiones de las capas de consenso y ejecución; comprobar si los ajustes del proponente, la configuración de keymanager o los parámetros de la línea de comandos sobrescriben el schedule predeterminado; y, tras actualizar, observar la sincronización de la bifurcación, la propuesta de bloques y la coherencia del límite de gas. Los no validadores y los titulares habituales de la red principal no necesitan migrar fondos ni cambiar sus billeteras por este cambio de versión en la red de pruebas.
A continuación, habrá que estar atentos a si la activación de Sepolia se completa según lo previsto, a si el límite de gas de los bloques cambia de acuerdo con el schedule, a la participación y producción de bloques de los distintos clientes y a si la EF anuncia por separado las fechas de Hoodi o de la red principal. Si se aplaza la bifurcación de prueba, surge una incompatibilidad entre clientes o el plan para la red principal no incorpora el schedule correspondiente, la valoración de que «la configuración de prueba avanza sin problemas» perderá su fundamento. Solo cuando los resultados de las pruebas sean estables y se avance hacia un proceso definido para la red principal, valdrá la pena reevaluar sus efectos a largo plazo en la red.
Fuentes: Ethereum Foundation, «Glamsterdam Testnet Announcement» (2026-09-28): https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement . Versión oficial v7.2.1 de Prysm en GitHub (2026-10-05): https://github.com/OffchainLabs/prysm/releases/tag/v7.2.1 . La información de la Ethereum Foundation sobre las versiones de los clientes también aparece en el anuncio de la red de pruebas.