Ethereum alerta para abuso de construtores na testnet Glamsterdam

A transcrição da reunião de 17 de setembro do All Core Developers Consensus da Ethereum mostra que os participantes aceitaram a data de 6 de outubro após rever os resultados recentes da devnet Glamsterdam, embora os programadores tenham levantado simultaneamente preocupações sobre como a Separação Proposer-Builder Consagrada (ePBS) poderia comportar-se numa rede pública onde o ETH de teste não tem custo económico significativo.

No centro do aviso está a EIP-7732, o design da Separação Proposer-Builder Consagrada da Glamsterdam. A Ethereum.org descreve a ePBS como uma alteração de protocolo que separa a tarefa de montar payloads de execução das funções de consenso do validador, movendo uma relação que atualmente depende fortemente de infraestrutura externa para as regras de consenso da Ethereum.

Neste design, os construtores podem submeter propostas pelo direito de fornecer um payload de execução. Uma vez que um proponente se compromete com a proposta vencedora, espera-se que o construtor divulgue as transações por trás dela. A especificação de consenso da Ethereum define os construtores como atores com stake separados que submetem propostas assinadas de payload de execução antes de transmitir o envelope de payload correspondente.

Durante a chamada de programadores de quinta-feira, o programador de consenso Potuz avisou que a economia muda numa testnet porque os atacantes podem obter ETH de teste sem pagar o seu valor de mercado na mainnet. Um operador malicioso poderia criar muitas identidades de construtor, submeter propostas muito acima dos concorrentes legítimos e depois recusar-se a fornecer o payload prometido após vencer.

"Posso simplesmente criar mil construtores", disse Potuz, explicando que o atacante poderia alterná-los, fazer propostas agressivas e reter payloads. Acrescentou depois: "Qualquer adolescente consegue fazer isto."

O programador enquadrou a preocupação como um problema de disponibilidade da testnet pública, não como uma nova via 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. O ETH de teste torna a disrupção persistente muito mais barata.

Clientes podem precisar de disjuntores ao nível do construtor

As salvaguardas existentes podem não ser suficientes para o ambiente Sepolia. Potuz disse aos programadores que alguns disjuntores de clientes só recorrem a blocos construídos localmente após vários payloads falhados, e que não tinha conhecimento de proteções universais que pudessem rejeitar construtores abusivos individualmente.

A sua preocupação centrava-se nos atacantes que regressam com identidades novas. Mesmo que um cliente reaja a payloads em falta, construtores descartáveis poderiam continuar a fazer propostas, a menos que a lógica defensiva identifique e restrinja o comportamento com rapidez suficiente.

Os programadores não apresentaram o ataque de construtor como uma exploração confirmada contra a Sepolia. A discussão dizia respeito a um cenário que esperam que os testes públicos possam expor assim que pessoas externas possam participar nas condições da ePBS. Potuz argumentou que as testnets da Ethereum precisam de salvaguardas mais fortes porque as equipas de aplicações e infraestrutura dependem delas para testar software contra blocos funcionais.

A Ethereum.org observa que a Sepolia usa um conjunto de validadores permissionado controlado por equipas de clientes e testes, enquanto a Hoodi tem um conjunto de validadores aberto destinado a testes de staking e protocolo. A estrutura da Sepolia dá aos programadores da Ethereum mais controlo operacional se a primeira implementação pública de longa duração da Glamsterdam encontrar problemas.

Como noticiado anteriormente pelo crypto.news, os programadores tinham 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 avançou esse calendário depois de a Devnet-11 ter concluído o ensaio de fork programado.

Devnet-11 testou 200 milhões de gás antes da Sepolia

A Devnet-11 da Glamsterdam foi criada como um ensaio controlado de "caminho feliz", em vez de uma rede de ataque adversária. A sua especificação oficial agendou a génese 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 pouco depois.

A rede de teste usou 84.000 validadores numa configuração multi-cliente e transportou o mesmo conjunto central de EIPs planeado para os testes da Glamsterdam. Os seus organizadores excluíram explicitamente ataques deliberados do âmbito da Devnet-11, mantendo as experiências adversárias no ambiente Platåberget de longa duração.

A CoinDesk noticiou que a Devnet-11 concluiu a transição e moveu o limite de gás para 200 milhões sem perder finalidade. A definição de 200 milhões é um parâmetro de teste, não um compromisso confirmado de limite de gás na mainnet.

O próprio roteiro da Glamsterdam da Ethereum diz que a atualização foi concebida para aumentar a capacidade da Camada 1, alterando a forma como os blocos são construídos e verificados. A EIP-7732 alarga a janela de propagação do payload de execução de cerca de 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 ao Nível de Bloco e uma série de alterações na tarifação do gás. A cobertura anterior de compatibilidade da Glamsterdam noticiou que carteiras, indexadores e estimadores de gás que usam pressupostos fixos podem exigir alterações porque a criação de novas contas e algumas operações com estado intensivo recebem tratamento de gás diferente no fork planeado.

Uma revisão separada de risco de contratos inteligentes concluiu 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 de a atualização chegar à mainnet.

Janela de revisão de clientes da Sepolia cai para sete dias

O calendário de 6 de outubro dá às equipas de clientes menos tempo de revisão do que o processo normal de atualização da Ethereum recomenda.

Durante a chamada de 17 de setembro, o programador Fredrik Svantes disse aos participantes que o processo padrão exige pelo menos 14 dias entre o software de cliente pronto para lançamento e a primeira ativação em testnet pública. Disse que essas duas semanas são normalmente usadas para revisões de segurança internas, exposição a bug bounty e possível trabalho de segurança externo.

Com a Sepolia a aproximar-se, os programadores discutiram 29 de setembro como data-limite 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 o seu conjunto de validadores é relativamente centralizado e a rede pode ser recuperada mais facilmente se o software falhar.

O programador principal Alex Stokes instou as equipas a lançar software mais cedo, quando possível, para que mais revisores o pudessem examinar. Assim que os clientes prontos para lançamento estiverem disponíveis, podem entrar imediatamente no processo de bug bounty da Ethereum.

O calendário comprimido surge após vários problemas de teste anteriores. Uma agenda de programadores de 3 de setembro registou não-finalidade durante a ativação da Gloas na Devnet-8, afetando vários clientes de consenso, enquanto testes posteriores da Devnet examinaram correções e casos-limite adicionais.

Outra chamada de testes registou problemas em que um cenário Platåberget derrubou 12 dos 13 nós Besu e abrandou os nós Erigon e Ethrex. A Devnet-9 sofreu não-finalidade não planeada, empurrando as equipas para novas iterações antes da Devnet-11.

Ativação na mainnet continua sem data confirmada

O roteiro público da Ethereum continua a listar a 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 a 6 de outubro.

Espera-se que a Hoodi siga a Sepolia porque fornece um ambiente de validadores aberto para testes de staking e atualizações. Os programadores discutiram a fase Hoodi durante a chamada de 17 de setembro, mas ligaram o seu calendário ao progresso da Sepolia, o que significa que problemas na primeira testnet pública poderiam adiar as datas subsequentes.

O rascunho do plano de resposta a incidentes da mainnet da Ethereum ainda não contém época ou carimbo de data/hora de ativação. O documento deixa os campos de informação da atualização em branco, listando as funções de cliente e coordenação que serão preenchidas antes da implementação na mainnet.

Como a cobertura anterior do crypto.news sobre a Glamsterdam noticiou, a atualização centra-se na ePBS, Listas de Acesso ao Nível de Bloco e reprecificação do gás concebida para maior débito da Camada 1. Os programadores continuaram a tratar testes multi-cliente bem-sucedidos como pré-requisito antes de definir o fork da mainnet.

Por agora, as equipas de clientes enfrentam o prazo de software de 29 de setembro discutido na chamada, seguido da ativação da Sepolia a 6 de outubro. Os programadores da Ethereum não publicaram uma época de mainnet nem um carimbo de data/hora de ativação final.