Ethereum (ETH) ensayó su próxima gran actualización el 6 de octubre. Apenas trascendió fuera de los canales de desarrolladores. Sin embargo, la testnet Sepolia ya ejecuta normas que redefinen quién construye los bloques, cómo se fija el precio del gas y cuánta carga computacional puede asumir cada bloque.
Este análisis desglosa las 18 modificaciones centrales de Glamsterdam —lideradas por la separación enraizada entre proponente y constructor (ePBS), las listas de acceso a nivel de bloque y la nueva tarificación del gas— y qué implican para las comisiones, el MEV, los rollups y el salto previsto a un límite de 200 millones de gas.
- Glamsterdam se activó en la testnet Sepolia de Ethereum el 6 de octubre de 2026, y los desarrolladores han fijado el 26 de octubre para la testnet Hoodi. Aún no hay fecha para mainnet, aunque un borrador de propuesta de calendario baraja varias opciones a inicios de diciembre.
- La actualización integra en el protocolo la relación entre proponente y constructor, introduce listas de acceso a nivel de bloque para habilitar procesamiento en paralelo y redefine cómo cobra Ethereum por crear y leer estado.
- Tras Glamsterdam, los desarrolladores se alinearon en un suelo de 200 millones de gas por bloque, más de triple del valor por defecto actual de 60 millones, aunque el efecto real sobre las comisiones dependerá de la demanda y de la adopción por parte de los validadores.
¿Qué es la actualización Glamsterdam de Ethereum y por qué es relevante?
Glamsterdam es la siguiente gran actualización de red tras Fusaka, y su nombre combina dos mitades. El lado de la capa de ejecución se denomina Amsterdam, en honor a la ciudad anfitriona de Devconnect 2022, mientras que la parte de consenso se llama Gloas, por una estrella.
La Fundación Ethereum publicó el anuncio de la fase de pruebas el 28 de septiembre. Programó la activación en Sepolia para el epoch 353.024, slot 11.296.768, a las 13:53:36 UTC del 6 de octubre.
La bifurcación se produjo en hora.
La investigadora independiente de Ethereum Christine D. Kim informó el 9 de octubre de que la actualización en Sepolia «transcurrió sin contratiempos». A partir de ahí, los desarrolladores fijaron Glamsterdam para Hoodi —la segunda y última testnet pública— el lunes 26 de octubre, con lanzamientos de clientes esperados para el 16 de octubre.
El alcance técnico está recogido en la propuesta de seguimiento EIP-7773. Incluye 18 cambios de núcleo, respaldados por cinco propuestas de red y dos de carácter informativo.
El escenario en mainnet es otro. La Fundación señaló que las fechas para Hoodi y mainnet «aún no se han decidido», y ethereum.org sigue mencionando únicamente un objetivo general en el cuarto trimestre de 2026.
Un borrador de calendario en GitHub plantea el 1, 8 y 9 de diciembre como posibles ventanas para mainnet, pero la comunidad de desarrolladores todavía no ha consensuado ninguna.
¿Por qué importa? Durante años, Ethereum ha volcado la mayor parte del esfuerzo de escalado en los rollups y ha mantenido muy conservadora su capa base. Glamsterdam marca un giro visible en ese enfoque.
La Fundación presenta la actualización como el siguiente paso en su hoja de ruta para escalar la capa 1. Sus principales novedades buscan que la cadena base pueda procesar con seguridad mucha más actividad, ajustando el precio del gas de forma más cercana al coste real de ejecución y al crecimiento del estado.
También puede interesar: La interfaz inteligente de ChatGPT integra gráficos y calculadoras en las respuestas para 1.200 millones de usuarios
¿En qué se diferencia Glamsterdam de Pectra y Fusaka?
Las dos últimas grandes actualizaciones de Ethereum se centraron, sobre todo, en el staking y los datos. Glamsterdam ataca la ejecución, la parte del sistema que realmente procesa las transacciones.
Pectra se activó el 7 de mayo de 2025, en el epoch 364.032. Permitió que las carteras convencionales delegaran en contratos inteligentes mediante la EIP-7702, elevó el balance máximo de los validadores de 32 a 2.048 Ether y aumentó el objetivo de blobs a seis, con un máximo de nueve por bloque.
Fusaka entró en vigor el 3 de diciembre de 2025, a las 21:49:11 UTC. Su gran novedad fue PeerDAS, la EIP-7594, que permite a los nodos verificar datos de blobs muestreando pequeños fragmentos en lugar de descargarlo todo.
Fusaka también introdujo las bifurcaciones «solo de parámetros de blob», pequeñas actualizaciones de configuración que ajustan la capacidad de blobs sin empaquetar otras funciones. Se aplicaron dos más, el 9 de diciembre de 2025 y el 7 de enero de 2026.
La actualización Checkpoint de enero de la Fundación destacó que Ethereum ahora apunta a 14 blobs por bloque, con un máximo de 21. Calculó que eso supone multiplicar por 2,3 el espacio de datos disponible para capas 2 respecto al periodo anterior a Fusaka.
En la parte de ejecución, Fusaka limitó las transacciones individuales a unos 16,8 millones de gas y fijó en el software de cliente un límite por defecto de 60 millones de gas por bloque.
Glamsterdam cambia las prioridades. En lugar de añadir aún más espacio para datos de rollups, reconstruye la forma en que se producen, validan y valoran los bloques, con el objetivo de que esos 60 millones de gas puedan subir mucho más.
Pectra y Fusaka ensancharon las tuberías para las capas 2; Glamsterdam reconfigura la sala de máquinas de la capa 1.
También puede interesar: ¿Puede TRON blindar 95.000 millones en ‘stablecoins’ ante ataques cuánticos? Sun asegura que está listo
¿Qué es la separación enraizada proponente‑constructor, o ePBS?
Hoy, la mayoría de los bloques de Ethereum no los monta el validador que los propone. Constructores especializados compiten por ensamblar el bloque más rentable, y un validador que ejecute el software MEV-Boost de Flashbots elige la puja más alta.
Ese relevo se apoya en «relays» o repetidores, que actúan como intermediarios de confianza. El relay retiene el bloque del constructor, muestra al proponente solo la cabecera y la oferta económica, y revela el contenido completo cuando el proponente firma.
El sistema funciona, pero opera por completo fuera del protocolo. Si un relay falla, se comporta de forma desleal o censura bloques, las reglas de consenso de Ethereum no ofrecen remedio alguno.
La EIP-7732 lleva ese intercambio al propio Ethereum. Trata a los constructores como participantes de protocolo y asigna a los validadores una nueva responsabilidad: las «atestaciones de puntualidad de payload» (payload timeliness attestations).
Con el nuevo flujo, el proponente incluye en el bloque beacon el compromiso firmado del constructor con un payload de ejecución, y el propio constructor revela ese payload después. El protocolo se encarga del pago al proponente, lo que reduce la dependencia de middleware de confianza.
Un subconjunto de validadores forma el comité de puntualidad de payload. Sus miembros atestiguan si el constructor reveló su payload a tiempo y si los datos de blobs correspondientes estaban disponibles.
El cambio también separa la validación de consenso de la validación de ejecución; ahí es donde entra el componente de escalado.
La hoja de ruta de ethereum.org explica que esta separación amplía la ventana para propagar datos por la red de unos 2 segundos a alrededor de 9 segundos. Más margen de tiempo implica que los validadores pueden gestionar con seguridad cargas de datos mucho mayores.
Los relays no desaparecerán de un día para otro. La misma página señala que constructores y proponentes pueden seguir utilizando relays externos o middleware para funciones avanzadas que el protocolo base todavía no incorpora.
También puede interesar: Claude Mythos 5 llegó a webs gubernamentales y Anthropic decidió cortar las pruebas
¿Cómo podría Glamsterdam cambiar el MEV y la economía de los validadores de Ethereum?
El valor máximo extraíble, o MEV, es el beneficio que se obtiene al ordenar, incluir o excluir transacciones dentro de un bloque. A través de MEV-Boost, gran parte de ese valor se traslada a los validadores como pujas de los constructores, pero el mercado detrás de esas pujas está muy concentrado.
El panel Relayscan de Flashbots mostraba a Titan construyendo el 52,6 % de los bloques MEV-Boost en las 24 horas previas a la madrugada del 12 de octubre. Quasar firmó el 18,5 % y BuilderNet el 13,3 %, dejando a tres constructores con alrededor del 84 % del flujo.
El ePBS no elimina el MEV, ni rompe automáticamente la concentración de constructores. Lo que cambia es el modelo de confianza: el pago al proponente ya no depende de que un relay cumpla su promesa.
Para los stakers, la ventaja se aprecia en el margen. Un validador en solitario gana una vía, reforzada por el propio protocolo, para vender espacio en bloque, mientras que los constructores deben depositar una participación propia para poder operar.
Los stakers también obtienen salidas más ágiles. Con la EIP-8061, la capacidad de salida escala con el total de Ether en staking, lo que según ethereum.org la cuadruplica en los niveles actuales y dobla el margen para consolidar validadores.
La contrapartida es una ventana de seguridad más corta para los nodos que se desconectan. Ethereum.org señala que el periodo de «subjetividad débil», tras el cual un nodo que regresa necesita un checkpoint reciente de confianza, baja de unos 15,7 días a unos 7 días.
Durante el encuentro Soldøgn interop en Svalbard, una reunión primaveral con poco más de un centenar de contribuyentes clave, los desarrolladores pusieron sobre la mesa dos cuestiones controvertidas sobre ePBS. Una de ellas es cómo proteger un diseño que exige solo 1 ETH de stake a los constructores frente a ataques Sybil sobre la red peer‑to‑peer.
Esa preocupación reapareció antes de Sepolia. En la llamada de consenso del 17 de septiembre, el desarrollador de Prysm Potuz advirtió de que el Ether de pruebas gratuito permitiría a un atacante ganar subastas con constructores desechables y luego retener los payloads: «Puedo lanzar mil constructores sin coste real».
Los primeros datos en Sepolia apuntan a un mercado muy fino. Un resumen comunitario de la llamada de capa de ejecución del 8 de octubre citaba a EthPandaOps señalando que solo cuatro o cinco constructores habían estado activos, con los grandes actores ausentes y muchos bloques aún construidos localmente por los propios validadores.
El verdadero valor de ePBS solo se demostrará cuando haya competencia real entre constructores por los bloques, lo que convierte a Hoodi en la prueba más significativa.
También puede interesar: El iPhone Duo podría saludar personalmente al usuario al arrancar por primera vez el plegable de 1.999 dólares
¿Qué son las listas de acceso a nivel de bloque y cómo mejoran el procesamiento de transacciones?
En la actualidad, los clientes de Ethereum procesan en gran medida las transacciones de un bloque de forma secuencial. No pueden saber de antemano qué cuentas o posiciones de almacenamiento tocará cada transacción, por lo que ejecutar varias al mismo tiempo conlleva riesgo de colisiones.
La EIP-7928 introduce las block-level access lists, o BALs, listas de acceso a nivel de bloque que registran todas las cuentas y posiciones de almacenamiento a las que accede un bloque, junto con los cambios de estado que provoca cada transacción. Los constructores generan esta lista y la cabecera del bloque la incorpora como referencia estructural para los clientes de ejecución. Con ese mapa en mano, los clientes pueden ejecutar varias tareas en paralelo:
- Leer desde disco todo el estado necesario a la vez, en lugar de ir descubriéndolo paso a paso.
- Validar en paralelo, en distintos núcleos de CPU, las transacciones que no se solapan.
- Calcular la raíz de estado posterior al bloque de forma más eficiente.
- Actualizar el estado a partir de los resultados registrados sin volver a reproducir cada transacción, lo que acelera la sincronización.
Un cambio de red complementario, el EIP-8159, permite que los nodos se intercambien estas listas entre sí. Otro, el EIP-8189, utiliza los datos BAL para reparar el estado durante la sincronización “snap”.
En Soldøgn, los equipos de clientes midieron cada optimización BAL por separado, detrás de su propia feature flag. La idea era acelerar primero los cuellos de botella de cada cliente, porque mejorar la implementación más débil eleva el límite de gas seguro para todo el ecosistema.
BAL y ePBS forman un tándem. ePBS amplía el tiempo de ejecución en cada slot, y los BAL permiten a los clientes aprovechar ese margen de forma mucho más eficiente.
También lea: Bezos dice que la IA podría llevar a semanas laborales de tres días tras el recorte de 30.000 empleos en Amazon
¿Cómo cambiará Glamsterdam la contabilidad de gas y los costes de ejecución en Ethereum?
Los precios de gas para operaciones sobre el estado no se replanteaban a fondo desde la actualización Berlin de 2021. Desde entonces, el estado de Ethereum ha crecido de forma notable, y los últimos aumentos del límite de gas han acelerado ese crecimiento.
En un artículo para desarrolladores de smart contracts publicado el 24 de agosto, la Fundación explicó que el nuevo esquema permite “aproximadamente un aumento de 3x en el throughput base”. El reprofilado de estas operaciones, añadía, es un requisito previo para volver a subir el límite de gas.
Dos EIP asumen la mayor parte del trabajo. El EIP-8037 encarece y mide por separado el coste de crear nuevo estado, mientras que el EIP-8038 eleva el coste de leerlo y escribirlo mediante operaciones como SLOAD, SSTORE y el acceso en frío a cuentas.
El EIP-8037 fija un precio de 1.530 unidades de gas por cada nuevo byte de estado, cifra derivada de un objetivo de crecimiento anual de 120 GiB de estado con un límite de gas de referencia de 150 millones.
Con esa tarifa, una nueva storage slot pasa a costar 97.920 unidades de “gas de estado”, frente a las 20.000 actuales, y una nueva cuenta sube a 183.600 frente a las 25.000 de hoy. Desplegar un contrato de tamaño máximo, 24 KiB, se vuelve aproximadamente ocho veces más caro.
El gas de estado, además, tendrá su propio contador. El tope por transacción introducido en Fusaka pasa a aplicarse solo al gas de ejecución, y cada bloque se mide por la dimensión —ejecución o estado— que esté más cerca de su respectivo límite.
El resto del paquete de gas es más específico, pero en conjunto es relevante:
- El EIP-7778 impide que las devoluciones de gas computen contra el límite de gas por bloque, aunque los usuarios siguen recibiendo la devolución sobre lo pagado.
- El EIP-7976 eleva el mínimo de calldata a 64 unidades de gas por byte para transacciones intensivas en datos.
- El EIP-7981 cobra los datos de las access lists al mismo tipo: 64 unidades de gas por byte.
- El EIP-2780 reconstruye el gas intrínseco de las transacciones en función del uso real de recursos, con un coste base de 12.000 unidades de gas.
- El EIP-7954 aumenta el tamaño máximo de contrato de 24 KiB a 64 KiB.
El borrador actual del EIP-2780 mantiene en 21.000 unidades de gas una simple transferencia de Ether a una cuenta existente, mientras que una transferencia que crea una nueva cuenta añade 183.600 unidades de gas de estado. La página de Glamsterdam en Ethereum.org, actualizada por última vez el 6 de agosto, todavía describe transferencias hasta un 71% más baratas.
Las cifras aún pueden cambiar. Varias de estas propuestas, incluido el EIP-2780 y el EIP-8037, siguen en fase de Last Call hasta el 1 de noviembre, y ethereum.org recuerda que el alcance podría ajustarse antes del lanzamiento en mainnet.
También lea: Zcash fija un objetivo cuántico en enero para el 70% de ZEC, lo que le falta es una fecha
¿Podría la actualización aumentar el throughput de la capa 1 y abaratar las comisiones?
El throughput es la gran recompensa. En Soldøgn, los desarrolladores consensuaron un “suelo creíble de 200M de gas después de Glamsterdam”, unas 3,3 veces el valor por defecto actual de 60 millones.
Esa cifra se apoya en tres pilares. ePBS da más tiempo de ejecución por slot, las optimizaciones BAL aportan margen en los clientes, y el EIP-8037 evita que un límite de gas más alto dispare sin control el crecimiento del estado.
Sepolia ya funciona con un límite de 200 millones, programado en la época de fork bajo el EIP-8261, que convierte el límite de gas en un parámetro fijado por fork.
El código de cliente para Hoodi programa el mismo umbral de 200 millones. Los resúmenes de llamadas apuntan a que la red principal seguirá el mismo enfoque de “época de fork”, pero aún no hay cifra ni fecha formalmente anunciadas para mainnet.
¿Bajarán las comisiones? Ethereum.org sostiene que Glamsterdam “muy probablemente reducirá las comisiones para los usuarios habituales”. Más espacio en bloque con la misma demanda debería presionar los precios a la baja, pero el resultado dependerá de cuánta actividad nueva llene ese espacio adicional.
Las operaciones intensivas en estado, como crear nuevas cuentas o storage slots, exigirán más gas, de modo que la actualización redistribuye los costes tanto como los reduce.
También lea: Kalshi se enfrenta a la NFL en el Supremo mientras 1.800 millones de dólares se juegan en un solo domingo de fútbol
¿Qué deben preparar monederos, smart contracts, proveedores de infraestructura y validadores?
Para los titulares minoristas, la respuesta es: nada. La Fundación afirma que los usuarios de la red principal no tienen que hacer ningún cambio, y ethereum.org advierte que cualquiera que pida “actualizar” el ETH de los usuarios está perpetrando una estafa.
El resto sí tiene deberes, y el reprofilado de gas es el principal. La reproducción de transacciones históricas de mainnet ha identificado un pequeño conjunto de contratos que podrían romperse o degradar su rendimiento, normalmente porque dependen de supuestos de gas codificados a fuego.
Según la Fundación, en la mayoría de los casos basta con aumentar el límite de gas para resolver los problemas detectados, y la gran mayoría de los contratos inteligentes no se ve afectada.
La lista de tareas, basada en las recomendaciones de la Fundación y de los equipos de clientes, es la siguiente:
- Los desarrolladores de smart contracts deben comprobar direcciones en la herramienta de contratos afectados de la Fundación y probar correcciones en la testnet Platåberget, prestando atención al estipendio fijo de 2.300 unidades de gas de Solidity, a valores de gas codificados y a lógicas que ramifican en función del gas restante.
- Monederos, proveedores RPC y herramientas de nodo tienen que actualizar sus sistemas de estimación de gas, ya que las constantes en caché infraestimarán los costes y provocarán fallos de transacción.
- Casas de cambio, puentes e indexadores pueden aprovechar los nuevos logs del EIP-7708, que hacen que toda transferencia o quema de Ether distinta de cero emita un evento estándar.
- Los operadores de nodos deben actualizar tanto los clientes de ejecución como los de consenso antes de cada activación, y los validadores deben actualizar el beacon node y el cliente de validador.
- Los operadores de staking y los equipos de builders deberían revisar las nuevas funciones e interfaces de ePBS, incluido el payload timeliness committee, antes de cada fork.
Los clientes de ejecución preparados para Sepolia incluían Geth 1.17.7, Nethermind 2.1.0, Besu 26.9.0, Erigon 3.7.1, Reth 2.7.0 y Ethrex 29.0.1. En consenso, la lista incluía Lighthouse 8.3.0-rc.0, Prysm 7.2.1, Teku 26.9.1, Lodestar 1.49.0, Nimbus 26.10.0 y Grandine 3.0.0-rc.0.
Los valores por defecto del límite de gas ilustran la importancia de los detalles. La versión 7.2.0 de Prysm y la versión para Sepolia de Teku dejaban a los validadores en 60 millones tras el fork, salvo que los operadores ajustasen manualmente el límite a 200 millones.
Prysm fusionó una corrección el 2 de octubre para que los validadores sin una configuración explícita sigan el calendario de 200 millones de Sepolia, y la Fundación ya lista Prysm 7.2.1. Los validadores de Teku que quieran operar con 200 millones todavía tienen que fijarlo mediante una opción de configuración.
También lea: ¿Catástrofe de IA en 12 meses? OpenAI y Anthropic supuestamente se preparan para el impacto
¿Cómo afecta Glamsterdam a la relación entre la capa 1 de Ethereum y las redes de capa 2?
Glamsterdam no da la espalda a los rollups. La hoja de ruta oficial enmarca la actualización como un avance simultáneo de sus objetivos “Scale L1” y “Scale Blobs”.
La conexión es mecánica. Como ePBS amplía la ventana de propagación, ethereum.org explica que Ethereum puede transportar con seguridad muchos más datos, incluidos más blobs para los rollups, sin tensionar la red.
Glamsterdam en sí no fija nuevos límites de blobs. Desde Fusaka, los cambios en capacidad de blobs se introducen mediante forks exclusivos de parámetros de blob, de modo que la capacidad de datos para rollups puede seguir creciendo con su propio calendario.
En este frente, los desarrolladores no tienen prisa. El January Checkpoint señalaba que un tercer fork de este tipo no era prioritario mientras el uso de blobs no alcanzase los incrementos ya aprobados.
Dos mejoras más pequeñas ayudan directamente a las capas 2. El EIP-7997 sitúa un contrato factoría determinista en la misma dirección en todas las cadenas EVM participantes, para que los desarrolladores puedan desplegar monederos y aplicaciones en direcciones idénticas cross-chain.
El segundo, el EIP-8070, introduce un sparse blobpool, un cambio de red en la forma en que los nodos gestionan las transacciones de blob.
La tensión estratégica es real. Una capa 1 más barata y rápida hace más atractivo desplegar directamente en mainnet, lo que la coloca en competencia con los rollups que liquidan allí sus operaciones.
La respuesta de Ethereum, hasta ahora, es escalar ambas capas a la vez. La hoja de ruta trata la capacidad de ejecución y la capacidad de blobs como objetivos paralelos, y el diseño de Glamsterdam refleja ese doble mandato en lugar de forzar una elección entre capas.
Para los usuarios de rollups, el efecto práctico es una capa de liquidación más robusta y con menos supuestos de confianza bajo sus transacciones.
También lea: Los ETF de XRP atraen 8 millones de dólares en plena oleada de ventas de fondos cripto liderada por Bitcoin
¿Qué viene después de Glamsterdam en la hoja de ruta de escalado de Ethereum?
El próximo fork será Hegotá. Igual que Glamsterdam, combina en su nombre una ciudad de la capa de ejecución, Bogotá, con una estrella de la capa de consenso, Heze.
Sus protagonistas ya están definidos. El cluster de Protocolo de la Fundación designó al EIP-7805, listas de inclusión reforzadas por la regla de elección de bloque (fork-choice enforced inclusion lists o FOCIL), para la capa de consenso, y al EIP-8141, Frame Transactions, para la capa de ejecución.
FOCIL llegó a estar sobre la mesa para Glamsterdam. Los desarrolladores lo desplazaron a Hegotá para acotar el alcance del fork, según la documentación técnica.Checkpoint de enero de la fundación
FOCIL permite que múltiples validadores fuercen a los builders a incluir transacciones válidas, abordando de forma directa el riesgo de censura que genera la concentración en el mercado de construcción de bloques. Las transacciones Frame hacen que la validación y el pago de gas sean programables, dando a las cuentas una vía nativa para alejarse de las claves secp256k1 que dominan hoy.
La lista de niveles asociada al clúster evaluó 62 EIPs propuestos, a partir de 397 calificaciones aportadas por un grupo de unas 60 personas. Dos se calificaron como “imprescindibles”, 15 como “probables de incluir” y 28 fueron descartados.
El calendario es ambicioso. El clúster considera realista que los equipos de clientes puedan empezar a implementar Hegotá a finales del cuarto trimestre de 2026, y su planificación parte de que Glamsterdam se active en diciembre, una hipótesis de trabajo más que una fecha firmemente programada.
Más allá de Hegotá, el clúster organiza su agenda en torno a cinco grandes líneas de investigación, que abarcan varios forks:
- Finalidad rápida, cuyo objetivo es reducir el tiempo de finalidad de minutos a segundos, con el consenso desacoplado como principal candidato estrella para el fork posterior a Hegotá.
- Seguridad poscuántica, guiada por el objetivo autoimpuesto de lograr una Capa 1 resistente a la computación cuántica —en ejecución, consenso y datos— antes de diciembre de 2029.
- Privacidad, que arranca en Hegotá con soporte de protocolo para transacciones privadas en Layer 1 sin necesidad de confianza y resistentes a la censura.
- Estado, centrada en un nuevo trie, un crecimiento del estado sostenible y un acceso descentralizado tanto al estado actual como al histórico.
- zkEVM, que busca pasar de pruebas de ejecución opcionales a obligatorias, de modo que los validadores terminen verificando pruebas en lugar de reejecutar cada bloque.
También lea: Venta de Bitcoin de MARA sigue sin probarse tras el envío de 81 millones de dólares a una wallet de Galaxy Digital
Conclusión: Qué significa Glamsterdam para Ethereum
Glamsterdam no es tanto una funcionalidad aislada como una reorganización de la capa base de Ethereum. Integra el mercado de builders dentro del propio protocolo, ofrece a los clientes una hoja de ruta para trabajar en paralelo y hace que el coste del estado permanente sea más transparente y acorde con su impacto real.
El despliegue en Sepolia fue fluido, pero las pruebas más exigentes aún están por venir. Potuz ha señalado que Hoodi concentra pools de staking y validadores domésticos, lo que la convierte en una bifurcación mucho más compleja que Sepolia.
Una propuesta de planificación de los desarrolladores centrales fija el fork de Hoodi en la época 132.352, es decir, a las 17:42:48 UTC del 26 de octubre. Aún no hay fecha para mainnet, y la fundación ha indicado que se anunciará por separado.
Las dudas abiertas son tanto económicas como técnicas. Que aparezcan builders reales, que los validadores adopten el nuevo límite superior de gas y que la demanda llegue a ocupar ese espacio adicional determinará qué consigue en la práctica Glamsterdam.
Si la apuesta sale bien, la capa base de Ethereum podrá escalar bajo sus propios términos, con los rollups construyendo por encima en lugar de absorber por completo la carga.
Lea a continuación: Salida a bolsa de Evernorth en Nasdaq pasa al 12 de octubre: qué cambia con el retraso de la fusión
