Ethereum fija meta de 200M de gas tras Soldøgn y acelera la actualización Glamsterdam

Ethereum cerró una semana de trabajo intensivo en Svalbard con avances decisivos para Glamsterdam, la próxima actualización de la red. Los equipos lograron alinear un suelo creíble de límite de gas de 200M, estabilizar implementaciones de ePBS con builders externos y fijar los números finales de repricing de EIP-8037, en un impulso clave para la escalabilidad del protocolo.

***

• Más de 100 colaboradores principales de Ethereum se reunieron en Svalbard para endurecer la actualización Glamsterdam.
• La semana terminó con tres hitos centrales: meta creíble de 200M de gas, ePBS estable con builders externos y repricing final de EIP-8037.
• También hubo avances relevantes en abstracción nativa de cuentas, FOCIL, redes P2P basadas en QUIC y el proceso de AllCoreDevs.

 

---

Ethereum concluyó una nueva semana de interoperabilidad técnica con resultados que podrían influir de forma directa en su próxima etapa de escalado. Más de 100 colaboradores principales del ecosistema se reunieron en Longyearbyen, Svalbard, para el Soldøgn Interop, un encuentro centrado en endurecer la actualización Glamsterdam y acelerar el trabajo multi cliente sobre una misma meta de fork.

El balance fue concreto. Al cierre del viernes, los equipos reportaron alineación en un suelo creíble de límite de gas posterior a Glamsterdam de 200M, implementaciones estables de ePBS con builders externos y números finales de repricing para EIP-8037. Además, se registraron avances en funciones previstas para Hegotá, entre ellas FOCIL y la abstracción nativa de cuentas.

Para lectores menos familiarizados con la hoja de ruta de Ethereum, el límite de gas define cuánta actividad computacional puede procesarse dentro de un bloque. Elevarlo permite mayor capacidad transaccional, pero también presiona a los clientes, el estado de la red y la coordinación entre capas. Por eso, cualquier aumento importante requiere rediseños técnicos y pruebas cruzadas entre implementaciones.

De acuerdo con el recuento publicado por la Ethereum Foundation, Soldøgn retomó el formato de semanas de trabajo concentradas usado en interops anteriores como Amphora, Edelweiss y Nyota. A diferencia de reuniones más abiertas, aquí el objetivo fue uno solo: endurecer Glamsterdam para que las decisiones sobre escalado descansen en evidencia de implementación y benchmarking, no solo en teoría.

Por qué Svalbard fue el escenario elegido

La sede no fue un detalle menor. Svalbard es uno de los pocos territorios del mundo donde cualquier persona, sin importar su nacionalidad, puede vivir y trabajar sin visa. Esa característica lo convierte en un punto singular para reunir a desarrolladores de múltiples países en un mismo lugar durante varios días de trabajo intensivo.

La región también alberga dos instalaciones emblemáticas de preservación en frío: la Global Seed Vault y el Arctic World Archive. Allí se conservan copias de respaldo de cultivos, libros, películas, manuscritos y código fuente que la humanidad podría necesitar dentro de siglos. Entre esos archivos también existe una instantánea del código fuente de Ethereum.

El contexto simbólico reforzó la narrativa del encuentro. Desde finales de abril hasta agosto, el sol no se pone en Svalbard. La Ethereum Foundation destacó esa coincidencia con el funcionamiento ininterrumpido de la red, una analogía que, según el recuento del evento, los desarrolladores aprovecharon al máximo con jornadas de código que se extendieron hasta la madrugada.

Tres equipos de la fundación aportaron infraestructura para la semana. EthPandaOps desplegó ethIQ y un servidor MCP de panda para apoyar flujos de trabajo agentic. Protocol Support montó soldogn.xyz como fuente única de verdad para objetivos, calendario y notas. EF Digital Studio, por su parte, grabó material en video para un futuro documental del interop.

ePBS, el eje de consenso para escalar Glamsterdam

Uno de los frentes centrales fue ePBS, una propuesta que reorganiza la relación entre proposer y builder en Ethereum. Más allá de ese cambio, también modifica la estructura temporal de los slots al añadir plazos explícitos para construcción de bloques, revelación del payload y attestations. Eso delimita mejor cuánto tiempo puede dedicarse a la ejecución y abre margen para subir el límite de gas de forma más segura.

Los equipos arrancaron la semana con el objetivo de tener una devnet Glamsterdam de 4 EL × 4 CL operativa para el lunes por la tarde. Los primeros intentos revelaron suficientes fallas como para mover la meta al martes. Ese día, una configuración 4 × 3 logró la estabilidad mínima necesaria para comenzar con las pruebas de estrés.

A partir de allí, el trabajo fue iterativo. El patrón se repitió durante varios días: someter la red a estrés, revelar casos límite, corregir errores y volver a probar. Una sesión paralela sobre Builder API simplificó elementos de la especificación, incluidos el registro de validadores, el flujo de bid, header y commitments, el modelo de confianza para pagos del builder y el comportamiento del circuit breaker.

La depuración de mitad de semana puso bajo foco casos límite entre clientes. Uno de los más notorios giró en torno a la invalidación de beacon requests por execution-request, donde una nueva suite de pruebas dejó al descubierto una brecha presente en todas las implementaciones de clientes. Para la mañana del jueves, los equipos de la capa de consenso ya informaban un ePBS estable, mientras el lado de ejecución seguía ajustando rutas de bid.

Esos problemas terminaron de resolverse entre el jueves y el viernes. Al cierre, casi todos los clientes corrían juntos en glamsterdam-devnet-2 con la canalización de builders externos probada de extremo a extremo. Aun así, quedaron dos temas sensibles para futuras discusiones de AllCoreDevs: si la firma de request debe comprometerse con el builder receptor y cómo blindar un diseño de builder con stake de ETH 1 frente a ataques de vivacidad basados en P2P Sybil.

Optimización de ejecución: BAL y repricings de gas

Si ePBS fue la gran pieza de consenso, la capa de ejecución se apoyó en dos líneas dominantes: los repricings de gas y las Block-Level Access Lists, o BAL. Estas listas entregan a los clientes información anticipada sobre el conjunto de lectura y escritura de un bloque. Con ello, se habilita ejecución en paralelo, I/O por lotes y cálculo paralelo de la state root, factores decisivos para sostener bloques más grandes.

El trabajo sobre BAL se mantuvo en devnets separadas de las cadenas ePBS de Glamsterdam. El objetivo fue evitar que las métricas de optimización quedaran contaminadas por problemas de estabilización de consenso. Cada mejora se ubicó detrás de su propio feature flag, lo que permitió medir el impacto de cada cambio de forma aislada y no solo como parte de un paquete general.

Un panel de benchmarks y su tabla de clasificación mostraron los peores escenarios de cada cliente dentro de la suite de pruebas. El enfoque no fue exprimir al cliente más rápido, sino elevar primero los caminos más lentos. Esa lógica es relevante en Ethereum, donde el rendimiento útil de la red depende de la diversidad de implementaciones y del mínimo común de desempeño, no del máximo teórico de una sola.

En paralelo, Glamsterdam incluyó varios repricings de gas de la capa de ejecución. El más importante fue EIP-8037, enfocado en elevar el costo de creación de estado para que un mayor límite de gas no se traduzca en crecimiento descontrolado del estado global. Antes de Soldøgn, esa especificación usaba un precio dinámico por state-byte vinculado al límite de gas del bloque. Según el recuento oficial, ese enfoque hacía las pruebas combinatoriamente difíciles y casi inmanejable el benchmarking.

Los equipos acordaron al inicio de la semana abandonar el esquema dinámico y pasar a un cost_per_state_byte fijo. La intención fue dejar futuros repricings para límites entre forks y no dentro de un mismo fork. Después, el modelo de contabilidad fue mutando durante varios días: el lunes se movió el state-gas a fin del call-frame, el martes se cerraron costos sobre creación de cuentas, depósito de código y reverts de CREATE, el miércoles aparecieron problemas en refund y refill del reservoir, y el jueves se devolvió la contabilidad al nivel de opcode.

Para el viernes, la especificación se estabilizó en bal-devnet-6 y el trabajo de BAL entregó los números finales de repricing. La convergencia entre ePBS, optimizaciones BAL y EIP-8037 permitió llegar a la cifra más importante de la semana: un suelo creíble de límite de gas posterior a Glamsterdam de 200M. La lógica de ese número es tripartita. ePBS da más tiempo efectivo a la ejecución, BAL mejora el rendimiento de clientes bajo esa estructura y 8037 contiene el crecimiento del estado.

Decisiones adicionales dentro de Glamsterdam

Más allá de esos tres frentes, el interop también dejó decisiones sobre otros EIPs menores incluidos o evaluados para Glamsterdam. Los equipos de la capa de consenso confirmaron que EIP-8061, relacionado con el aumento del churn de exit y consolidation, fue incluido en glamsterdam-devnet-1. En cambio, EIP-8080, sobre salidas vía la consolidation queue, fue rechazado para inclusión.

También se redujo el alcance de EIP-8045. En lugar de abarcar toda la eliminación de deberes de validadores slashed, quedará limitado a los deberes del proposer dentro de la ventana look-ahead. EIP-7688, sobre contenedores SSZ estables, sigue dentro del alcance general de Glamsterdam, pero quedó fuera de glamsterdam-devnet-1 mientras se resuelve el tamaño acotado de los mensajes gossip para attestations bajo progressive lists.

Otra sesión relevante trató la arquitectura de sincronización entre las capas de ejecución y consenso. Allí se decidió aplazar EIP-8237 fuera de Glamsterdam para preservar opcionalidad hacia una arquitectura de top-up sync en un fork futuro. En su lugar, el grupo acordó redactar un nuevo EIP que estandarice la secuencia de forkchoiceUpdated, newPayload y getPayload, además de definir un handshake de inicio de snap-sync y reforzar la consistencia de válido e inválido en la engine API.

El endurecimiento de herramientas fue otro tema constante. Una sesión del jueves revisó marcos de pruebas de cumplimiento de fork-choice, el repositorio Diamond con escenarios reproducibles de casos límite de la capa de consenso, y buildoor, una herramienta de PandaOps para probar builders externos que fue presentada en vivo frente a una larga cadena de escenarios de ataque propuestos por los asistentes.

Más allá de Glamsterdam: Hegotá, FOCIL y red P2P

Soldøgn no se limitó al siguiente fork. Varias sesiones miraron hacia Hegotá y actualizaciones posteriores. En abstracción nativa de cuentas, la discusión se planteó de manera deliberadamente agnóstica respecto de propuestas concretas. El objetivo fue mapear requisitos y restricciones que cualquier diseño futuro tendrá que cumplir.

Entre los objetivos funcionales aparecieron esquemas alternativos de firma, agregación, batching, recuperación, patrocinio de gas, nonces flexibles y keystore wallets. A la vez, se fijaron restricciones duras en torno a compatibilidad con mempool público, statelessness y resistencia a ataques de denegación de servicio en L2. El enfoque deja claro que la función sigue siendo atractiva, pero aún no tiene una forma final consensuada.

La sesión de FOCIL del jueves se concentró en el estado de implementación. Los primeros prototipos ya funcionan, y los pasos inmediatos serán interop multi cliente y una devnet dedicada. Allí también se adoptaron dos decisiones de diseño. La primera fue desactivar FOCIL durante un escenario de no finality de 2 epochs, en línea con el circuit breaker de proposer boost. La segunda fue usar un enfoque de bookmark basado en índices para compatibilidad con frame transactions y EIP-7702.

En el frente de red, una línea de trabajo extensa sobre ETH P2P esbozó un reemplazo basado en QUIC para libp2p, con privacidad por defecto e integración consciente del slot. Según los resultados compartidos en el evento, un prototipo de difusión con borrado codificado simuló una propagación cerca de 6 × más rápida que GossipSub sobre payloads de 2,4 MB. En la capa de consenso también se observó un sentimiento fuerte a favor de eventualmente desaprobar por completo las consolidations y pasar luego a un modelo de exit-then-redeposit como respuesta más limpia al crecimiento del estado del conjunto de validadores.

Cambios en el proceso ACD y próximos pasos

El miércoles por la tarde, Nixo y Ansgar, co líderes de ACDE, guiaron una sesión dedicada al proceso de AllCoreDevs. Allí se revisó el llamado headliner construct, se discutieron ventajas y problemas del strawmap y se formalizaron criterios para EIP SFI. La dirección general fue mantener los headliners, pero con menos rigidez entre tema y EIP, aceptando el patrón tema más EIP candidato.

Las asignaciones por año y por fork del straw map más allá de 2026 fueron vistas como excesivamente canonizadas y podrían suavizarse. También se propuso una nueva definición de SFI de cuatro puntos, con ACDT señalando preparación y ACDE o ACDC reteniendo la decisión final. A eso se sumará un proceso renovado de ordenación de prioridades, reflejado en la meta EIP, que reemplazará el antiguo papel de SFI como impulsor de inclusión en devnet a partir de Hegotá.

En el plano de coordinación, Alex Stokes anunció que tomará un sabático de tres meses desde la próxima semana. Durante ese periodo, Pari cubrirá de forma interina la moderación de ACDC y Barnabas sustituirá en ACDT. El esquema resumido quedó así: Nixo y Ansgar al frente de ACDE, Pari de manera interina en ACDC, y Mario, Barnabas y Danceratopz rotando la moderación de ACDT.

La semana también sirvió para avanzar en mejoras de test harnesses, compresión de ciclos de retroalimentación de Hive de horas a minutos, ajustes del plumbing de engine API, deduplicación de gossip, llamadas por lotes, descubrimiento de head impulsado por light clients y debates sobre diversidad de clientes. Los equipos regresan ahora a sus bases para convertir prototipos en código listo para producción, mientras las decisiones finales sobre la meta de 200M de gas y los repricings se discutirán públicamente en próximas llamadas de AllCoreDevs.

En términos prácticos, Soldøgn dejó algo más que una postal técnica desde el Ártico. Dejó una señal de que Ethereum quiere acelerar su escalado sin sacrificar coordinación multi cliente, límites de seguridad ni control sobre el crecimiento del estado. La cifra de 200M todavía debe formalizarse, pero el interop convirtió una aspiración en una meta defendible con pruebas, implementaciones y consenso técnico creciente.

---

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA.