La semana pasada, poco más de 100 colaboradores principales de Ethereum se reunieron por encima del círculo polar ártico, en Longyearbyen, Svalbard, para el Interop de Soldøgn: una semana de intenso trabajo en la actualización de la red Glamsterdam.
Soldøgn siguió al Berlinterop del año pasado, pero volvió al formato utilizado por Amphora 🏺, Edelweiss 🏔️ y Nyota ✨: una semana de un solo tema centrada en el progreso de múltiples clientes hacia una actualización específica, en este caso, el fortalecimiento de Glamsterdam.
Para el viernes, el grupo había cumplido sus tres objetivos principales: alineación en un piso del límite de gas posterior a Glamsterdam de 200M, implementaciones estables de ePBS ejecutándose con constructores externos y los números finales de reajuste de precios de la EIP-8037 confirmados. También se logró un progreso significativo en las características de Hegotá, como FOCIL y la abstracción de cuentas nativa, así como en una gran cantidad de otros temas.
¿Por qué Svalbard?
Svalbard es uno de los pocos lugares en la Tierra donde cualquier persona, independientemente de su nacionalidad, puede vivir y trabajar sin visa. También alberga la Bóveda Global de Semillas y el Archivo Mundial del Ártico, dos instalaciones de almacenamiento en frío excavadas en el permafrost a las afueras de Longyearbyen. Entre ambas guardan copias de seguridad de cultivos, libros, películas, manuscritos y código fuente que la humanidad podría necesitar dentro de mil años, incluido un Snapshot del código fuente de Ethereum. Por último, pero no menos importante, desde finales de abril hasta agosto, el sol no se pone en Svalbard. Tiene un tiempo de actividad de 24/7, al igual que Ethereum, ¡lo cual los desarrolladores principales aprovecharon al máximo durante la semana!
Fortalecer Glamsterdam, escalar Ethereum
El objetivo de la semana era fortalecer las implementaciones de Glamsterdam y derivar un objetivo para un piso del límite de gas posterior a la actualización. Aumentar el límite de gas de manera segura es un problema multidimensional y Glamsterdam aborda varios de ellos: cómo se construyen y proponen los bloques, cuánto margen tienen las implementaciones de clientes bajo carga y cómo escalan los costos de creación de estado junto con la capacidad de procesamiento.
En la práctica, eso significó terminar la semana con una red de desarrollo de Glamsterdam multicliente estable ejecutando las últimas especificaciones de ePBS, reajuste de precios y listas de acceso a bloques, junto con datos de evaluación comparativa para respaldar una propuesta de límite de gas creíble.
La mayor parte del tiempo se pasó trabajando concentrados escribiendo código, a menudo hasta altas horas de la madrugada, intercalado con sesiones de trabajo para alinearse en las decisiones de diseño y discutir elementos de la hoja de ruta a más largo plazo.
Tres equipos de la EF proporcionaron infraestructura para la semana: EthPandaOps lanzó ethIQ y un servidor MCP panda para respaldar los flujos de trabajo de los agentes de los equipos; Protocol Support configuró soldogn.xyz como la única fuente de verdad para los objetivos, el cronograma y las notas del Interop; y el equipo de EF Digital Studio capturó la semana en video. ¡Esperen el primer documental sobre un Interop 🔜!
ePBS
Más allá de limpiar la relación entre el proponente y el constructor, ePBS reestructura los slots agregando fechas límite para la construcción de bloques, la revelación de la carga útil y las certificaciones. Esto hace explícito cuánto tiempo se puede asignar para la ejecución, aumentando el margen que tenemos para elevar el límite de gas.
Los equipos comenzaron la semana apuntando a una red de desarrollo de Glamsterdam de 4 EL × 4 CL para el lunes por la noche. Los primeros intentos revelaron suficientes problemas como para posponer el objetivo hasta el martes, cuando una configuración de 4×3 se ejecutó de manera lo suficientemente estable como para que comenzaran las pruebas de estrés.
A partir de ahí, el resto de la semana fue un ciclo de fortalecimiento de ePBS: pruebas de estrés, exposición de casos extremos, correcciones y repetición. Una sesión de trabajo el martes por la mañana sobre la API del constructor simplificó sustancialmente la especificación en torno al registro de validadores, el flujo de ofertas/encabezados/compromisos, el modelo de confianza para los pagos a los constructores y el comportamiento del interruptor de circuito. La depuración a mediados de semana se centró en casos extremos entre clientes, en particular en torno a la invalidación de solicitudes de ejecución de las solicitudes de la cadena de balizas, donde un nuevo conjunto de pruebas reveló una brecha en todas las implementaciones de clientes. Para el jueves por la mañana, los equipos de CL informaban de un ePBS estable, mientras que las vías de oferta del lado de EL aún se estaban depurando; estas se resolvieron entre el jueves y el viernes. Dos cuestiones siguen siendo genuinamente polémicas para ACD: si una firma de solicitud debe comprometerse con el constructor receptor, y cómo mantener un diseño de constructor con 1 ETH de participación resistente a los ataques de vitalidad basados en Sybil P2P.
Para el viernes, casi todos los clientes se ejecutaban juntos en glamsterdam-devnet-2 con el flujo de trabajo de los constructores externos probado de principio a fin.
Optimizaciones de BAL
Si ePBS es el lado de la capa de consenso de la historia de escalado de Glamsterdam, la contraparte de la capa de ejecución tiene dos piezas dominantes: los reajustes de precios del gas y las Listas de Acceso a Nivel de Bloque (BAL). Al brindar a los clientes suficiente información sobre el conjunto de lectura/escritura de un bloque por adelantado, las BAL permiten la ejecución en paralelo, la E/S con procesamiento por lotes y el cálculo en paralelo de la raíz del estado, todo lo cual determina qué tan grande es el bloque que los clientes pueden manejar cómodamente.
El grupo de trabajo de BAL de Soldøgn se ejecutó en sus propias redes de desarrollo, separadas de las cadenas ePBS de Glamsterdam, por lo que las evaluaciones comparativas de optimización no se enredaron con el trabajo de estabilización de la capa de consenso. Cada optimización se situó detrás de su propio indicador de función para que el trabajo de medición de la semana pudiera compararlas de forma aislada en lugar de como un solo paquete. El panel de evaluación comparativa de BAL y la tabla de clasificación mostraron los peores escenarios de cada cliente en todo el conjunto de pruebas: al centrarse en mejorar primero las rutas más lentas, los equipos pudieron elevar el piso del límite de gas en todos los ámbitos, no solo para la implementación más rápida.
Reajustes de precios del gas
Glamsterdam incluye una serie de reajustes de precios del gas en la EL, calibrando los costos para que coincidan mejor con el uso de recursos a una mayor capacidad de procesamiento. La EIP-8037, el aumento del costo del gas para la creación de estado, se encuentra en el centro: eleva el precio de escribir un nuevo estado para que un límite de gas más alto no se traduzca en un crecimiento ilimitado del estado.
Al llegar a Soldøgn, la especificación 8037 conllevaba un precio dinámico por byte de estado vinculado al límite de gas del bloque, lo que hacía que las pruebas fueran combinatoriamente dolorosas (una matriz de fuzzing por banda de límite de gas) y la evaluación comparativa casi intratable. Los equipos acordaron a principios de la semana abandonar los precios dinámicos a favor de un cost_per_state_byte fijo, y los futuros reajustes de precios se manejarían en los límites de la bifurcación en lugar de dentro de una bifurcación.
El modelo de contabilidad en sí tomó un camino más iterativo. La sesión de trabajo del lunes trasladó la contabilidad del gas de estado de la mitad de la ejecución al final del marco de llamada; un seguimiento el martes cerró los costos de creación de cuentas, los costos de depósito de código y las reversiones de transacciones CREATE; el miércoles surgieron casos extremos de reembolso/recarga del depósito que obligaron a un replanteamiento. La sesión del jueves revirtió la contabilidad al nivel del código de operación, habiendo concluido que la verdadera complejidad residía en el modelo del depósito, no en el cálculo contable. Para el viernes, la especificación se había estabilizado en bal-devnet-6, y el grupo de trabajo de BAL entregó los números finales de reajuste de precios.
Todo este arco destaca uno de los aspectos más importantes del Interop: la capacidad de resolver problemas complejos de especificación, implementación, pruebas, depuración y diseño en horas en lugar de semanas. En su mejor momento, ¡las semanas de Interop pueden comprimir un mes de progreso asincrónico en cada día!
Para el viernes, los tres hilos convergieron en el número principal de la semana: un piso del límite de gas posterior a Glamsterdam creíble de 200M. Este aumento significativo es posible porque ePBS estructura el slot para darle más tiempo a la ejecución, las optimizaciones de BAL brindan a los clientes el margen de capacidad de procesamiento bajo esa estructura, y la 8037 garantiza que el límite de gas más alto no se traduzca en un crecimiento descontrolado del estado.
Otros hilos de Glamsterdam
Más allá de ePBS, las BAL y los reajustes de precios, la mayor parte del alcance restante de Glamsterdam se debatió en sesiones de trabajo.
Los equipos de CL finalizaron las decisiones sobre las EIP más pequeñas de Glamsterdam: la EIP-8061 (aumento de la rotación de salida/consolidación) se incluyó en glamsterdam-devnet-1; la EIP-8080 (salidas a través de la cola de consolidación) fue rechazada para su inclusión; la EIP-8045 (eliminación de las obligaciones del validador con recorte) se redujo únicamente a las obligaciones del proponente dentro de la ventana de anticipación; y la EIP-7688 (contenedores estables de SSZ) permanece en el alcance de Glamsterdam, pero se mantiene fuera de glamsterdam-devnet-1 mientras el equipo trabaja en el tamaño limitado del mensaje de chismes para las certificaciones bajo listas progresivas.
Una sesión de trabajo sobre la arquitectura de sincronización de EL/CL el miércoles por la mañana aplazó la EIP-8237 fuera de Glamsterdam a favor de preservar la opcionalidad para una arquitectura de "sincronización de recarga" a más largo plazo en una futura bifurcación. En su lugar, la sala acordó redactar una EIP que normalice la secuenciación de forkchoiceUpdated / newPayload / getPayload, especifique un protocolo de enlace de inicio de sincronización rápida y refuerce la coherencia válida/inválida entre las superficies de la API del motor.
El fortalecimiento fue un tema constante de la semana. Una sesión del jueves cubrió los marcos de prueba de cumplimiento de la elección de bifurcación, el repositorio Diamond de escenarios de casos extremos reproducibles de CL, y buildoor, la herramienta de prueba de constructores externos de PandaOps, demostrada a mitad de la sesión ante una larga serie de escenarios de ataque que los asistentes sugirieron en el momento.
Más allá de Glamsterdam
Varias sesiones de trabajo miraron hacia Hegotá y las bifurcaciones que le siguen.
Una sesión deliberadamente independiente de la propuesta sobre la abstracción de cuentas nativa dio inicio a las cosas, trabajando en los requisitos y restricciones que cualquier diseño futuro debe satisfacer. Los objetivos del conjunto de características, como esquemas de firma alternativos, agregación, procesamiento por lotes, recuperación, patrocinio de gas, nonces flexibles y billeteras de almacén de claves, se sentaron junto a restricciones estrictas en torno a la compatibilidad con la mempool pública, la ausencia de estado y la resistencia a DoS de la capa 2 (l2).
Una sesión de trabajo sobre FOCIL el jueves se centró en las actualizaciones de implementación: los primeros prototipos ya eran funcionales, con la interoperabilidad multicliente y una red de desarrollo dedicada a FOCIL como los próximos pasos inmediatos. También se tomaron dos decisiones de diseño notables: deshabilitar FOCIL durante la no finalidad de 2 épocas (reflejando el comportamiento del interruptor de circuito de impulso del proponente), y adoptar un enfoque de marcador basado en índices para la compatibilidad con transacciones de marco / EIP-7702.
Más adelante, un grupo de trabajo de larga duración sobre ETH P2P esbozó un reemplazo basado en QUIC para libp2p con privacidad por defecto e integración consciente del slot, junto con un prototipo de transmisión codificada por borrado que simuló una propagación ~6 veces más rápida que GossipSub en cargas útiles de 2.4 MB. El grupo de trabajo de CL también mostró un fuerte sentimiento hacia la eventual desaprobación de las consolidaciones por completo (declarando una bifurcación final que las admita y luego forzando la salida y el posterior redepósito) como la respuesta a largo plazo más limpia para el crecimiento del estado del conjunto de validadores.
Proceso de ACD
El miércoles por la tarde, Nixo y Ansgar, los dos colíderes de ACDE, dirigieron una sesión para recopilar opiniones de los colaboradores principales sobre el proceso de ACD. La sesión revisó el concepto de titular, debatió los pros y los contras de tener un mapa preliminar y formalizó los criterios de SFI de las EIP. En general, la sala quería mantener los titulares, pero relajar la rigidez de EIP frente a tema, aceptando "tema + EIP candidata" como un patrón viable. Las asignaciones de años por bifurcación del mapa preliminar posteriores a 2026 se marcaron como sobrecanonizadas y es probable que se suavicen. Se presentó una nueva definición de SFI de cuatro puntos, con ACDT indicando la preparación y ACDE/ACDC reteniendo la decisión final. Un nuevo proceso de orden de priorización, producido después de las decisiones de CFI y reflejado en la meta-EIP, reemplazará el antiguo papel de SFI de impulsar la inclusión en la red de desarrollo, comenzando con Hegotá.
En el lado de la coordinación de llamadas, Alex Stokes anunció que se tomará un año sabático de tres meses a partir de la próxima semana, con Pari cubriendo la moderación de ACDC en el ínterin y Barnabas reemplazando en ACDT. En resumen: Nixo y Ansgar presiden ACDE, Pari es interino en ACDC, y Mario, Barnabas y Danceratopz rotan la moderación de ACDT.
Todo lo demás
Además de todo lo anterior, los equipos utilizaron el tiempo en persona para avanzar en todo, desde mejores entornos de prueba (comprimiendo los ciclos de retroalimentación de Hive de horas a minutos), hasta mejoras en la infraestructura de la API del motor (desduplicación de chismes, llamadas con procesamiento por lotes y descubrimiento de la cabeza impulsado por clientes ligeros), hasta difíciles concesiones en torno a la diversidad de clientes y muchos otros temas. La lista completa de notas de las sesiones está disponible en soldogn.xyz.
Próximos pasos
A partir de aquí, los equipos regresan a casa para tomar lo que se prototipó durante la semana y prepararlo para producción. Esperen que las próximas semanas estén enfocadas en fortalecer las implementaciones de los clientes frente a las nuevas especificaciones, finalizar la cobertura de las pruebas y convertir los PR en borrador de Soldøgn en código fusionado.
Como siempre, las decisiones finales para valores como el objetivo del límite de gas de 200M y los números finales de reajuste de precios se tomarán y compartirán públicamente en las llamadas de AllCoreDevs. ¡Esperen que estos sean los temas principales de la próxima semana!
¡Muchas gracias a todos los que vinieron hasta los 78°N e hicieron de esta semana un éxito! Un agradecimiento especial a EthPandaOps por poner al grupo en forma todos los días, y a todos los que trabajaron bajo el sol de medianoche para asegurarse de que alcanzáramos nuestros objetivos diarios, incluido el equipo de Ethrex, que se unió a nosotros para su primer Interop. Fue una semana increíblemente productiva y, afortunadamente, tendremos un cortometraje completo para recordarla ☀️