Os desenvolvedores do Ethereum confirmaram a ativação do Glamsterdam em Sepolia para 6 de outubro, enquanto alertam que o ether de teste barato poderia permitir que construtores maliciosos vencessem repetidamente leilões de blocos e retivessem seus payloads de transação durante a fase de teste público.
A transcrição do Consenso de Todos os Desenvolvedores Principais do Ethereum de 17 de setembro mostra que os participantes aceitaram a data de 6 de outubro após revisar os resultados recentes do devnet Glamsterdam, embora os desenvolvedores tenham levantado simultaneamente preocupações sobre como a Separação Enraizada Proponente-Construtor (Enshrined Proposer-Builder Separation) poderia se comportar em uma rede pública onde o ETH de teste não tem custo econômico significativo.
No centro do alerta está a EIP-7732, o design da Separação Enraizada Proponente-Construtor (Enshrined Proposer-Builder Separation) do Glamsterdam. Ethereum.org descreve o ePBS como uma mudança de protocolo que separa a tarefa de montar payloads de transação dos deveres de consenso do validador, movendo uma relação que atualmente depende fortemente de infraestrutura externa para as regras de consenso do Ethereum.
Sob este design, os construtores podem submeter lances pelo direito de fornecer um payload de execução. Uma vez que um proponente se compromete com o lance vencedor, espera-se que o construtor libere as transações por trás dele. A especificação de consenso do Ethereum define construtores como atores separados com stake que submetem lances de payload de execução assinados antes de transmitir o envelope de payload correspondente.
Durante a chamada de desenvolvedores de quinta-feira, o desenvolvedor de consenso Potuz alertou que a economia muda em uma testnet porque invasores podem obter ETH de teste sem pagar seu valor de mercado na mainnet. Um operador malicioso poderia criar muitas identidades de construtor, submeter lances muito acima dos concorrentes legítimos e então se recusar a fornecer o payload prometido após vencer.
“Eu posso simplesmente criar mil construtores,” disse Potuz, explicando que o invasor poderia rotacioná-los, dar lances agressivamente e reter payloads. Ele acrescentou depois: “Qualquer adolescente pode fazer isso.”
O desenvolvedor enquadrou a preocupação como um problema de disponibilidade da testnet pública, não uma nova rota para roubar ETH da mainnet. Na mainnet, um participante já pode pagar para produzir um bloco vazio, mas o custo econômico de obter espaço de bloco limita o comportamento. ETH de teste torna a interrupção persistente muito mais barata.
As salvaguardas existentes podem não ser suficientes para o ambiente Sepolia. Potuz disse aos desenvolvedores que alguns disjuntores de cliente voltam a usar blocos construídos localmente apenas depois que vários payloads são perdidos, enquanto ele não estava ciente de proteções universais que pudessem rejeitar construtores abusivos individuais.
Sua preocupação centrava-se em invasores retornando com novas identidades. Mesmo que um cliente reaja a payloads perdidos, construtores descartáveis poderiam continuar dando lances a menos que a lógica defensiva identifique e restrinja o comportamento rapidamente o suficiente.
Os desenvolvedores não apresentaram o ataque do construtor como um exploit confirmado contra a Sepolia. A discussão se referia a um cenário que eles esperam que o teste público possa expor uma vez que pessoas de fora possam participar sob as condições do ePBS. Potuz argumentou que as testnets do Ethereum precisam de salvaguardas mais fortes porque as equipes de aplicação e infraestrutura dependem delas para testar software contra blocos em funcionamento.
Ethereum.org observa que a Sepolia usa um conjunto de validadores permissionados controlado por equipes de clientes e testes, enquanto a Hoodi tem um conjunto de validadores aberto destinado a staking e testes de protocolo. A estrutura da Sepolia dá aos desenvolvedores do Ethereum mais controle operacional se a primeira implantação pública de longa duração do Glamsterdam encontrar problemas.
Conforme relatado anteriormente pelo crypto.news, os desenvolvedores haviam selecionado provisoriamente 6 de outubro antes da última chamada, com a data ainda dependente de outra transição estável de devnet privada. A chamada de consenso de 17 de setembro adiantou esse cronograma depois que o Devnet-11 completou seu ensaio de fork agendado.
O Devnet-11 do Glamsterdam foi criado como um ensaio controlado de "caminho feliz" em vez de uma rede de ataque adversarial. Sua especificação oficial agendou o genesis para 14 de setembro, a transição Gloas para 16 de setembro e um aumento do limite de gás do bloco de 60 milhões para 200 milhões logo depois.
A rede de teste usou 84.000 validadores em uma configuração multi-cliente e carregava o mesmo conjunto central de EIPs planejado para os testes do Glamsterdam. Seus organizadores excluíram explicitamente ataques deliberados do escopo do Devnet-11, mantendo experimentos adversariais no ambiente Platåberget de longa duração.
O CoinDesk relatou que o Devnet-11 completou a transição e moveu o limite de gás para 200 milhões sem perder a finalidade. A configuração de 200 milhões é um parâmetro de teste, não um compromisso confirmado de limite de gás da mainnet.
O próprio roteiro do Glamsterdam do Ethereum afirma que a atualização é projetada para aumentar a capacidade da Camada 1 enquanto muda como os blocos são construídos e verificados. A EIP-7732 estende a janela de propagação de payload de execução de aproximadamente dois segundos para cerca de nove segundos, dando aos nós mais tempo para distribuir e validar payloads maiores.
A atualização inclui Listas de Acesso no Nível do Bloco (Block-Level Access Lists) e uma série de mudanças nos preços do gás também. Coberturas anteriores sobre a compatibilidade do Glamsterdam relataram que carteiras, indexadores e estimadores de gás que usam suposições fixas podem exigir mudanças porque a criação de novas contas e algumas operações de estado pesado recebem tratamento de gás diferente sob o fork planejado.
Uma revisão separada de risco de contratos inteligentes descobriu que contratos que usam estipêndios de gás fixos ou padrões de execução sensíveis ao gás podem exigir testes antes que a atualização chegue à mainnet.
O cronograma de 6 de outubro dá às equipes de clientes menos tempo de revisão do que o processo normal de atualização do Ethereum recomenda.
Durante a chamada de 17 de setembro, o desenvolvedor Fredrik Svantes disse aos participantes que o processo padrão exige pelo menos 14 dias entre o software cliente pronto para lançamento e a primeira ativação da testnet pública. Ele disse que essas duas semanas são normalmente usadas para revisões de segurança internas, exposição a programas de recompensas por bugs (bug-bounty) e possível trabalho de segurança externa.
Com a Sepolia se aproximando, os desenvolvedores discutiram uma data limite de 29 de setembro para os lançamentos de clientes. Sete dias entre 29 de setembro e 6 de outubro deixariam metade do período normal de revisão. Os participantes aceitaram esse risco para a Sepolia em parte porque seu conjunto de validadores é relativamente centralizado e a rede pode ser recuperada mais facilmente se o software falhar.
O desenvolvedor principal Alex Stokes instou as equipes a lançar o software mais cedo, sempre que possível, para que mais revisores pudessem examiná-lo. Uma vez que os clientes prontos para lançamento estejam disponíveis, eles podem entrar no processo de recompensa por bugs (bug-bounty) do Ethereum imediatamente.
O cronograma comprimido segue vários problemas de teste anteriores. Uma agenda de desenvolvedores de 3 de setembro registrou não-finalidade durante a ativação Gloas do Devnet-8, afetando vários clientes de consenso, enquanto testes posteriores do Devnet examinaram correções e casos extremos adicionais.
Outra chamada de teste registrou problemas nos quais um cenário Platåberget derrubou 12 dos 13 nós Besu e desacelerou os nós Erigon e Ethrex. O Devnet-9 experimentou não-finalidade não planejada, impulsionando as equipes para novas iterações antes do Devnet-11.
O roteiro público do Ethereum continua a listar Glamsterdam para o quarto trimestre de 2026, mas afirma que a data da mainnet não foi confirmada. O próximo marco publicado é o fork da Sepolia em 6 de outubro.
Espera-se que a Hoodi siga a Sepolia porque ela fornece um ambiente de validador aberto para staking e teste de atualização. Os desenvolvedores discutiram a fase Hoodi durante a chamada de 17 de setembro, mas vincularam seu cronograma ao progresso da Sepolia, o que significa que problemas na primeira testnet pública poderiam alterar as datas subsequentes.
O rascunho do plano de resposta a incidentes da mainnet do Ethereum ainda não contém época de ativação ou timestamp. O documento, em vez disso, deixa os campos de informação de atualização em branco enquanto lista as funções de cliente e coordenação que serão preenchidas antes da implantação na mainnet.
Conforme relatado anteriormente pela cobertura do Glamsterdam do crypto.news, a atualização se concentra em ePBS, Listas de Acesso no Nível do Bloco (Block-Level Access Lists) e reprecificação de gás projetados para maior rendimento da Camada 1. Os desenvolvedores continuaram a tratar testes multi-cliente bem-sucedidos como um pré-requisito antes de definir o fork da mainnet.
Por enquanto, as equipes de clientes enfrentam o prazo de software de 29 de setembro discutido na chamada, seguido pela ativação da Sepolia em 6 de outubro. Os desenvolvedores do Ethereum não publicaram uma época da mainnet ou um timestamp de ativação final.
ETH