Os desenvolvedores do Ethereum agendaram provisoriamente a ativação da atualização Glamsterdam na Sepolia para 13:53 UTC de 6 de outubro de 2026, enquanto outro teste em devnet privada ainda é necessário antes que o fork da testnet pública prossiga.
Resumo
- Os desenvolvedores do Ethereum agendaram provisoriamente a ativação da Glamsterdam na Sepolia para 6 de outubro, precisamente às 13:53 UTC.
- A Glamsterdam não completou uma ativação estável em nenhuma devnet privada, deixando o momento da Sepolia ainda condicional.
- Os desenvolvedores agora planejam a Devnet-11 para 14 de setembro, substituindo expectativas anteriores centradas nos planos de teste da Devnet-10.
- Os testes em devnet expuseram bugs de consenso e execução, incluindo um problema de implementação relacionado ao código da EIP-8037.
- Nenhuma data para Hoodi ou mainnet está confirmada, embora os desenvolvedores tenham discutido uma possível ativação em dezembro.
As notas da reunião ACDC #186 e reportagens subsequentes da pesquisadora do protocolo Ethereum Christine D. Kim mostram que a data permanece condicional. Os desenvolvedores não haviam concluído uma ativação estável da Glamsterdam em uma rede de desenvolvimento privada quando selecionaram o cronograma da Sepolia.
O plano de testes desde então avançou mais uma iteração. Kim disse em 11 de setembro que a atenção havia se voltado para a Glamsterdam-Devnet-11, que deve ser lançada na segunda-feira, 14 de setembro. Planos anteriores haviam identificado a Devnet-10 como o próximo grande teste.
Nenhuma data de ativação foi confirmada para a testnet Hoodi ou para a mainnet do Ethereum. Os desenvolvedores discutiram um possível lançamento na mainnet em dezembro, mas os resultados dos testes determinarão se esse cronograma permanece prático.
A data da atualização Glamsterdam do Ethereum permanece provisória
Durante a reunião All Core Developers Consensus de 3 de setembro, os participantes concordaram com a época 351232 da Sepolia para a ativação proposta. Kim relatou que o horário correspondente seria 6 de outubro às 13:53 UTC. A reunião foi realizada antes que os desenvolvedores tivessem demonstrado desempenho estável nas redes de teste privadas usadas para a Glamsterdam.
Selecionar a época dá às equipes de clientes, operadores de infraestrutura e desenvolvedores de aplicativos um alvo de planejamento comum. Isso não torna a ativação definitiva. Os desenvolvedores podem adiar o fork se a próxima fase de testes descobrir uma falha grave ou se as equipes de clientes não conseguirem preparar versões confiáveis.
A ressalva permanece relevante após a Devnet-9 ter experimentado problemas de finalidade. De acordo com o material da reunião, a rede incluía aproximadamente 1.000 nós validadores, tornando-a a maior devnet Glamsterdam por contagem de validadores naquele estágio.
A finalidade exige que validadores suficientes concordem sobre o estado da cadeia. Quando uma rede de teste falha em finalizar, os desenvolvedores devem determinar se a causa envolve software cliente, participação de validadores, configuração de rede ou uma interação entre mudanças de protocolo separadas.
A Devnet-11 testará correções antes da Sepolia
O plano original previa a Devnet-10 após falhas aparecerem durante testes anteriores. A atualização mais recente de Kim agora identifica a Devnet-11 como o próximo teste que os desenvolvedores estão observando, indicando que a sequência de testes privados avançou além do plano anterior.
Uma Devnet-11 estável daria às equipes de clientes Ethereum outro ambiente para testar as especificações combinadas da Glamsterdam. Equipes de Layer-2, provedores de staking e outros operadores de infraestrutura precisam de implementações de clientes funcionais antes de poderem testar seus sistemas com segurança contra o fork proposto.
A diversidade de clientes torna o processo mais complexo. O Ethereum opera através de vários clientes de execução e consenso desenvolvidos independentemente, e a atualização deve funcionar em diferentes combinações de clientes. Uma falha confinada a uma implementação ainda pode interromper uma rede de teste quando os validadores afetados detêm peso suficiente.
A agenda do ACDC #186 registra pedidos da Lido e da Optimism por pelo menos um dia estável antes de um fork. A agenda listou correções de clientes e interoperabilidade bem-sucedida como questões que exigiam confirmação antes da Sepolia.
Uma Devnet-11 falha ou instável não cancelaria automaticamente a ativação de 6 de outubro. Os desenvolvedores precisariam avaliar a causa e o tempo necessário para reparos. Um problema sério poderia levá-los a reconsiderar a data durante uma reunião de Todos os Desenvolvedores Principais.
Bugs de consenso e do EIP-8037 estenderam os testes
Testes anteriores do Glamsterdam expuseram falhas em ambos os lados da arquitetura do Ethereum. O engenheiro de operações de desenvolvedores da Ethereum Foundation, Stefan Starflinger, relatou que a Devnet-8 revelou um problema na camada de consenso envolvendo blocos que repetiam um hash pai.
“Você poderia fazer toda a rede parar”, disse Starflinger ao descrever o cenário de teste.
O problema afetou o sistema responsável pelo acordo de blocos. A Devnet-9 então sofreu não-finalidade, levando engenheiros a investigar mais casos extremos em um conjunto maior de validadores.
No lado da execução, a pesquisadora da Ethereum Foundation Maria Silva relatou um problema de implementação envolvendo o EIP-8037. A proposta altera como o Ethereum cobra gas pela criação de novo estado, incluindo novas contas, contratos e entradas de armazenamento.
O EIP-8037 separa os custos de criação de estado dos custos normais de execução por meio de um modelo multidimensional de gas. Sua especificação publicada diz que o design busca controlar o crescimento do estado à medida que o Ethereum aumenta seu limite de gas por bloco. A proposta permanece em revisão por pares.
O problema descoberto exigiu que os clientes de execução revisassem suas implementações e levou a trabalho de especificação. Como a crypto.news relatou em sua cobertura do progresso anterior da devnet do Glamsterdam, o EIP-8037 foi testado junto com as outras mudanças de protocolo da atualização.
Os testes servem a um propósito diferente de aprovar cada proposta individualmente. Os desenvolvedores devem confirmar que todas as mudanças selecionadas operam juntas em vários clientes, configurações de validadores e padrões de transação.
Datas da Hoodi e da mainnet dependem dos resultados dos testes
Os desenvolvedores se recusaram a agendar o Glamsterdam na Hoodi enquanto a Sepolia permanece condicional. Espera-se que a Hoodi sirva como o segundo estágio de testnet pública, dando aos operadores de staking e equipes de protocolo outro ambiente que representa mais de perto as condições da mainnet.
O desenvolvedor do Teku, Enrico del Fante, apoiou esperar antes de fixar a data da Hoodi. Durante o ACDC #186, ele citou os recentes problemas da Devnet-9 e preferiu permitir mais tempo de teste após a decisão da Sepolia.
Uma ativação na mainnet em dezembro permanece como um alvo possível, não uma janela de lançamento confirmada. Agendar a Sepolia para o início de outubro preserva tempo de calendário suficiente para outra fase de testnet pública e preparação de lançamento de clientes, desde que os testes progridam sem atrasos prolongados.
Os desenvolvedores não publicaram uma época da mainnet, carimbo de data/hora de ativação ou cronograma final de lançamento de clientes. Nenhum prazo formal foi anunciado para decidir se 6 de outubro permanece adequado para a Sepolia.
O evento processual imediato é o lançamento planejado da Devnet-11 em 14 de setembro. As equipes de clientes examinarão a finalidade, o comportamento entre clientes e as correções introduzidas após testes anteriores antes de decidir se a Sepolia pode prosseguir sob o cronograma atual.
