Na semana passada, pouco mais de 100 contribuidores principais da Ethereum se reuniram acima do Círculo Polar Ártico — em Longyearbyen, Svalbard — para a Interop Soldøgn: uma semana de trabalho intenso na atualização da rede Glamsterdam.
A Soldøgn seguiu a Berlinterop do ano passado, mas retornou ao formato usado pela Amphora 🏺, Edelweiss 🏔️ e Nyota ✨: uma semana de trilha única de progresso focado e multicliente em direção a uma atualização específica — neste caso, o fortalecimento da Glamsterdam.
Até sexta-feira, o grupo havia cumprido seus três objetivos principais: alinhamento em um piso de limite de gas pós-Glamsterdam de 200M, implementações estáveis de ePBS rodando com construtores externos e os números finais de reprecificação da EIP-8037 definidos. Um progresso significativo também foi feito em recursos da Hegotá, como FOCIL e abstração de conta nativa, além de uma série de outros tópicos.
Por que Svalbard?
Svalbard é um dos poucos lugares na Terra onde qualquer pessoa, independentemente da nacionalidade, pode viver e trabalhar sem visto. Também abriga o Global Seed Vault (Cofre Global de Sementes) e o Arctic World Archive (Arquivo Mundial do Ártico), duas instalações de armazenamento a frio escavadas no permafrost nos arredores de Longyearbyen. Juntos, eles mantêm backups de plantações, livros, filmes, manuscritos e códigos-fonte que a humanidade pode precisar daqui a mil anos, incluindo um Snapshot do código-fonte da Ethereum. Por último, mas não menos importante, do final de abril a agosto, o sol não se põe em Svalbard. Tem um tempo de atividade de 24 horas por dia, 7 dias por semana, assim como a Ethereum, o que os desenvolvedores principais aproveitaram ao máximo durante a semana!
Fortalecer a Glamsterdam, Escalar a Ethereum
O objetivo da semana era fortalecer as implementações da Glamsterdam e derivar uma meta para um piso de limite de gas pós-atualização. Aumentar o limite de gas com segurança é um problema multidimensional e a Glamsterdam aborda vários deles: como os blocos são construídos e propostos, quanta margem as implementações de clientes têm sob carga e como os custos de criação de estado escalam junto com a vazão.
Na prática, isso significava terminar a semana com uma devnet multicliente estável da Glamsterdam executando as especificações mais recentes de ePBS, reprecificação e lista de acesso de bloco, juntamente com dados de benchmarking para ancorar uma proposta de limite de gas crível.
A maior parte do tempo foi gasta com foco total escrevendo código, muitas vezes até as primeiras horas da manhã, pontuada por sessões de discussão para alinhar decisões de design e discutir itens do roteiro de longo prazo.
Três equipes da EF forneceram infraestrutura para a semana: a EthPandaOps lançou o ethIQ e um servidor MCP panda para apoiar os fluxos de trabalho agênticos das equipes; o Protocol Support configurou o soldogn.xyz como a única fonte de verdade para os objetivos, cronograma e notas da interop; e a equipe do EF Digital Studio capturou a semana em filme. Aguarde o primeiro documentário de interop 🔜!
ePBS
Além de organizar a relação proponente/construtor, o ePBS reestrutura os slots adicionando prazos para a construção de blocos, revelação de carga útil (payload) e atestados. Isso torna explícito quanto tempo pode ser alocado para a execução, aumentando a margem que temos para elevar o limite de gas.
As equipes começaram a semana visando uma devnet da Glamsterdam com 4 EL × 4 CL até a noite de segunda-feira. As primeiras tentativas revelaram problemas suficientes para adiar a meta para terça-feira, quando uma configuração 4×3 rodou de forma estável o suficiente para o início dos testes de estresse.
A partir daí, o resto da semana foi um ciclo de fortalecimento do ePBS: teste de estresse, exposição de casos extremos, correção, repetição. Uma sessão de discussão sobre a API do Construtor na manhã de terça-feira simplificou substancialmente a especificação em torno do registro de validador, o fluxo de lances/cabeçalhos/compromissos, o modelo de confiança para pagamentos de construtores e o comportamento do disjuntor (circuit-breaker). A depuração no meio da semana focou em casos extremos entre clientes — notavelmente em torno da invalidação de solicitações de execução de solicitações do beacon, onde um novo conjunto de testes revelou uma lacuna em todas as implementações de clientes. Na manhã de quinta-feira, as equipes de CL estavam relatando um ePBS estável, enquanto os caminhos de lances do lado da EL ainda estavam sendo depurados; estes foram resolvidos de quinta para sexta-feira. Duas questões permanecem genuinamente controversas para a ACD: se uma assinatura de solicitação deve se comprometer com o construtor receptor e como manter um design de construtor com stake de 1 ETH resiliente contra ataques de vivacidade baseados em Sybil P2P.
Até sexta-feira, quase todos os clientes estavam rodando juntos na glamsterdam-devnet-2 com o pipeline de construtores externos testado de ponta a ponta!
Otimizações de BAL
Se o ePBS é o lado da camada de consenso da história de escalabilidade da Glamsterdam, a contraparte da camada de execução tem duas peças dominantes: reprecificações de gás e Listas de Acesso em Nível de Bloco (BALs). Ao fornecer aos clientes informações suficientes sobre o conjunto de leitura/gravação de um bloco antecipadamente, as BALs permitem a execução paralela, E/S com processamento em lote e computação paralela da raiz de estado, os quais determinam o tamanho de um bloco que os clientes podem lidar confortavelmente.
A trilha de BAL da Soldøgn rodou em suas próprias devnets, separadas das cadeias ePBS da Glamsterdam, para que os benchmarks de otimização não se misturassem com o trabalho de estabilização da camada de consenso. Cada otimização ficou atrás de sua própria flag de recurso (feature flag) para que o trabalho de medição da semana pudesse compará-las isoladamente, em vez de como um único pacote. O painel de benchmark de BAL e a tabela de classificação revelaram os piores cenários de cada cliente em todo o conjunto de testes — ao focar em melhorar os caminhos mais lentos primeiro, as equipes puderam elevar o piso do limite de gas de forma geral, não apenas para a implementação mais rápida.
Reprecificações de Gás
A Glamsterdam inclui uma série de reprecificações de gás na EL, calibrando os custos para melhor corresponder ao uso de recursos em uma vazão mais alta. A EIP-8037, o aumento do custo de gás para criação de estado, está no centro: ela aumenta o preço de gravar um novo estado para que um limite de gas mais alto não se traduza em um crescimento de estado ilimitado.
Entrando na Soldøgn, a especificação 8037 trazia uma precificação dinâmica por byte de estado vinculada ao limite de gas do bloco, o que tornava os testes combinatoriamente dolorosos (uma matriz de fuzz por faixa de limite de gas) e o benchmarking quase intratável. As equipes concordaram no início da semana em abandonar a precificação dinâmica em favor de um cost_per_state_byte fixo, com reprecificações futuras tratadas nos limites da bifurcação, em vez de dentro de uma bifurcação.
O próprio modelo de contabilidade seguiu um caminho mais iterativo. A sessão de segunda-feira moveu a contabilidade de gás de estado do meio da execução para o final do quadro de chamadas (call-frame); um acompanhamento na terça-feira encerrou os custos de criação de conta, custos de depósito de código e reversões de transação CREATE; a quarta-feira revelou casos extremos de reembolso/reabastecimento de reservatório que forçaram um repensar. A sessão de quinta-feira reverteu a contabilidade para o nível de código de operação, tendo concluído que a verdadeira complexidade estava no modelo de reservatório, não no cálculo contábil. Até sexta-feira, a especificação havia se estabilizado em bal-devnet-6, com a trilha de BAL entregando os números finais de reprecificação.
Todo esse arco destaca um dos aspectos mais importantes da interop: a capacidade de resolver problemas complexos de especificação, implementação, testes, depuração e design em horas, em vez de semanas. No seu melhor, as semanas de interop podem comprimir um mês de progresso assíncrono em cada dia!
Até sexta-feira, as três frentes convergiram para o número principal da semana: um crível piso de limite de gas pós-Glamsterdam de 200M. Esse aumento significativo é possível porque o ePBS estrutura o slot para dar mais tempo à execução, as otimizações de BAL dão aos clientes a margem de vazão sob essa estrutura e a 8037 garante que o limite de gas mais alto não se traduza em um crescimento de estado descontrolado.
Outras Frentes da Glamsterdam
Além do ePBS, BALs e reprecificações, a maior parte do escopo restante da Glamsterdam foi discutida em sessões de grupo.
As equipes de CL finalizaram as decisões sobre EIPs menores da Glamsterdam: a EIP-8061 (aumento da rotatividade de saída/consolidação) foi incluída em glamsterdam-devnet-1; a EIP-8080 (saídas via fila de consolidação) foi recusada para inclusão; a EIP-8045 (remoção de deveres de validador com penalização) foi reduzida apenas aos deveres do proponente dentro da janela de previsão (look-ahead); e a EIP-7688 (contêineres estáveis SSZ) permanece no escopo da Glamsterdam, mas é mantida fora de glamsterdam-devnet-1 enquanto a equipe trabalha no tamanho limitado da mensagem de fofoca (gossip) para atestados sob listas progressivas.
Uma sessão de arquitetura de sincronização EL/CL na manhã de quarta-feira adiou a EIP-8237 para fora da Glamsterdam em favor de preservar a opcionalidade para uma arquitetura de "sincronização de recarga" (top-up sync) de longo prazo em uma bifurcação futura. Em seu lugar, a sala concordou em redigir uma EIP que normaliza o sequenciamento de forkchoiceUpdated / newPayload / getPayload, especifica um handshake de iniciação de snap-sync e reforça a consistência válida/inválida entre as superfícies da API da engine.
O fortalecimento foi um tema constante da semana. Uma sessão na quinta-feira cobriu frameworks de testes de conformidade de escolha de bifurcação (fork-choice), o repositório Diamond de cenários de casos extremos reproduzíveis de CL e o buildoor, a ferramenta de testes de construtor externo da PandaOps, demonstrada no meio da sessão para um longo fluxo de cenários de ataque que os participantes sugeriram na hora.
Além da Glamsterdam
Várias sessões olharam para a Hegotá e as bifurcações que se seguem.
Uma sessão deliberadamente agnóstica em relação a propostas sobre abstração de conta nativa deu o pontapé inicial, trabalhando nos requisitos e restrições que qualquer design futuro deve satisfazer. Objetivos de conjunto de recursos como esquemas de assinatura alternativos, agregação, processamento em lote, recuperação, patrocínio de gás, nonces flexíveis e carteiras de repositório de chaves ficaram ao lado de restrições rígidas em torno da compatibilidade com a mempool pública, ausência de estado e resistência a DoS na camada 2 (l2).
Uma sessão sobre FOCIL na quinta-feira focou em atualizações de implementação: os primeiros protótipos já estavam funcionais, com interop multicliente e uma devnet dedicada para FOCIL como os próximos passos imediatos. Duas decisões de design notáveis também foram tomadas: desativar o FOCIL durante a não finalidade de 2 épocas (espelhando o comportamento do disjuntor de proposer-boost) e adotar uma abordagem de marcador baseada em índice para compatibilidade com transações de quadro (frame) / EIP-7702.
Mais adiante, uma trilha de longa duração de P2P da ETH esboçou um substituto baseado em QUIC para a libp2p com privacidade por padrão e integração ciente de slot, juntamente com um protótipo de transmissão com codificação de apagamento (erasure-coded) que simulou uma propagação ~6 vezes mais rápida que o GossipSub em cargas úteis de 2,4 MB. A trilha de CL também revelou um forte sentimento em direção a eventualmente descontinuar as consolidações por completo — declarando uma bifurcação final que as suporte e, em seguida, forçando a saída e o redepósito depois — como a resposta de longo prazo mais limpa para o crescimento do estado do conjunto de validadores.
Processo ACD
Na tarde de quarta-feira, Nixo e Ansgar, os dois colíderes da ACDE, conduziram uma sessão para coletar opiniões dos principais contribuidores sobre o processo ACD. A sessão revisitou a construção de headliner, debateu os prós e contras de ter um strawmap (mapa provisório) e formalizou os critérios de SFI de EIP. A sala, de modo geral, queria manter os headliners, mas afrouxar a rigidez EIP-vs-tema, aceitando "tema + EIP candidata" como um padrão viável. As atribuições de ano por bifurcação do strawmap após 2026 foram sinalizadas como excessivamente canonizadas e provavelmente serão suavizadas. Uma nova definição de SFI de quatro pontos foi apresentada, com a ACDT sinalizando prontidão e a ACDE/ACDC mantendo a decisão final. Um novo processo de ordenação de priorização — produzido após as decisões de CFI e refletido na meta-EIP — substituirá o antigo papel da SFI de impulsionar a inclusão em devnet, começando com a Hegotá.
Do lado da coordenação de chamadas, Alex Stokes anunciou que tirará um período sabático de três meses a partir da próxima semana, com Pari cobrindo a moderação da ACDC nesse ínterim e Barnabas substituindo na ACDT. Resumindo: Nixo e Ansgar presidem a ACDE, Pari é interina na ACDC e Mario, Barnabas e Danceratopz se revezam na moderação da ACDT.
Todo o Resto
Além de tudo o que foi mencionado acima, as equipes usaram o tempo presencial para progredir em tudo, desde melhores ambientes de teste (comprimindo os ciclos de feedback do Hive de horas para minutos), até melhorias na infraestrutura da API da engine (desduplicação de gossip, chamadas com processamento em lote e descoberta de cabeçalho orientada por cliente leve), até difíceis compensações (tradeoffs) em torno da diversidade de clientes e muitos outros tópicos. A lista completa de notas das sessões está disponível em soldogn.xyz.
Próximos Passos
A partir daqui, as equipes voltam para casa para pegar o que foi prototipado durante a semana e deixá-lo pronto para produção. Espere que as próximas semanas sejam de foco total no fortalecimento das implementações de clientes em relação às novas especificações, finalizando a cobertura de testes e transformando os PRs de rascunho da Soldøgn em código mesclado.
Como sempre, as decisões finais para valores como a meta de limite de gas de 200M e os números finais de reprecificação serão tomadas e compartilhadas publicamente nas chamadas AllCoreDevs. Espere que esses sejam os principais tópicos da próxima semana!
Muito obrigado a todos que vieram até 78°N e fizeram desta semana um sucesso! Um agradecimento especial à EthPandaOps por colocar o grupo em forma todos os dias, e a todos que trabalharam sob o sol da meia-noite para garantir que atingíssemos nossas metas diárias — incluindo a equipe da Ethrex, que se juntou a nós para sua primeira interop. Foi uma semana incrivelmente produtiva e, felizmente, teremos um curta-metragem completo para lembrá-la ☀️