Ethereum adia fork Glamsterdam na testnet Hoodi

•

Desenvolvedores do Ethereum mantêm suspenso o fork da atualização Glamsterdam na testnet Hoodi. As equipes planejavam ativá-lo em 26 de outubro, mas adiaram o processo após uma revisão sobre contratos com pouco gas. Em 6 de novembro, a Ethereum Foundation informou que os desenvolvedores ainda analisavam os problemas identificados.

A revisão mostrou que contratos criados antes da atualização podem reagir de outra forma sob as regras propostas. Isso ocorre porque Glamsterdam altera a cobrança de operações ligadas à criação e ao acesso ao estado da rede. Por isso, clientes, carteiras e aplicações precisam verificar quais pressupostos antigos continuam válidos.

URGENTE: a atualização Glamsterdam do Ethereum seria ativada na Sepolia em 6 de outubro. A implementação na testnet marcaria a próxima etapa para aproximar Glamsterdam da mainnet do Ethereum.

cryptodotnews no X

Novas regras alteram a contabilização de gas

A EIP-8037 muda a contabilização de operações que criam estado, como registros no armazenamento de contratos. Esses dados podem permanecer na rede após o encerramento da transação e gerar custos para os nós. Assim, a proposta separa parte dessa cobrança do gas normal de execução e cria uma reserva para operações elegíveis.

Já a EIP-8038 altera os preços de operações que acessam o estado existente. Uma execução pode ler um valor, chamar outro contrato e gravar um resultado. Nesse contexto, os custos da leitura e da chamada também afetam o gas disponível para a gravação final.

Uma transação com os mesmos dados enviados pelo usuário pode produzir um resultado diferente. A análise busca separar os efeitos esperados da nova precificação de falhas em pressupostos usados por clientes ou contratos. Enquanto isso, as equipes continuam trabalhando na atualização Hegota.

Falhas em chamadas podem mudar o resultado

Contratos podem chamar outros contratos e escolher como agir quando uma chamada falha. Um processador em lote, por exemplo, pode registrar um item malsucedido e continuar a execução. Contudo, a transação externa pode reverter por completo se faltar gas para concluir esse tratamento.

A análise da ChainSecurity indicou que a nova contabilização pode alterar essa distinção. Pela regra EIP-150, o chamador retém aproximadamente um sessenta e quatro avos do gas em determinado cenário. Ainda assim, o resultado depende do orçamento restante após o retorno e do custo das instruções seguintes.

Antes, um caminho de execução poderia reverter toda a transação externa. Com as mudanças propostas, o chamador pode conservar gas suficiente para tratar a falha e concluir a transação. Como resultado, uma chamada interna malsucedida pode deixar registros diferentes no estado da rede.

Auditores examinam oito pressupostos de contratos

A Ethereum Foundation reuniu exemplos em um repositório de auditoria que apresenta oito pressupostos sob análise. ChainSecurity, Dedaub e revisores internos participaram do processo. Entretanto, os valores refletem uma versão específica da proposta e podem mudar após novas revisões.

Parte dos riscos envolve limites fixos de gas e reservas usadas para encerrar operações depois de uma chamada. Um valor que antes financiava uma gravação final pode deixar de ser suficiente. Em contrapartida, o gas retido pelo chamador pode concluir um caminho de falha que antes causava uma reversão.

A reserva separada da EIP-8037 cria outro cenário. Se ela ainda financiar a criação de estado elegível, um contrato poderá gravar um registro após uma chamada falhar. Além do mais, apagar um slot criado na mesma transação ou reverter uma chamada pode devolver gas de estado conforme a especificação analisada.

gasleft() e delegações também exigem testes

Contratos que usam gasleft() para comparar o orçamento restante com limites fixos também podem apresentar comportamento inesperado. A diferença entre duas medições não revela necessariamente todos os recursos consumidos ou devolvidos durante a execução. Desse modo, contratos que usam esse cálculo para cobranças ou reembolsos podem enfrentar resultados distintos.

O oitavo caso envolve a EIP-7702, que permite a uma conta autorizar uma delegação para código de contrato. Uma transação pode entrar no bloco mesmo quando uma autorização interna falha por falta de gas. Logo, carteiras e serviços não devem interpretar apenas a inclusão da transação como prova de que a delegação funcionou.

O repositório destaca que muitos achados envolvem valores fixos ou reservas predeterminadas. Isso não significa que todos os contratos com esses padrões sofrerão perdas. Mesmo assim, os responsáveis convidaram desenvolvedores e auditores a testar aplicações com os exemplos disponíveis.

Hoodi testará clientes, carteiras e estimativas

Glamsterdam já chegou à testnet Sepolia, onde desenvolvedores testaram um limite de 200 milhões de gas por bloco. A Hoodi oferecerá outro ambiente compartilhado para executar uma versão revisada da atualização. Dessa forma, operadores poderão atualizar clientes no mesmo cronograma e comparar os resultados.

Os testes precisam verificar se diferentes clientes alcançam o mesmo estado final e registram o mesmo consumo de gas. As equipes de aplicações também devem analisar mudanças na lógica dos contratos sob orçamentos restritos. Sobretudo, casos próximos ao gas necessário para iniciar ou terminar um tratamento de falha exigem atenção.

Carteiras dependem de simulações e estimativas de gas feitas conforme as regras ativas da rede. Um serviço com configuração antiga pode fornecer uma estimativa inadequada após o fork. Da mesma maneira, relayers e patrocinadores podem pagar por uma execução que não entrega a ação solicitada.

URGENTE: o Ethereum adiou a atualização Glamsterdam na testnet Hoodi. A Ethereum Foundation postergou a ativação de 26 de outubro para revisar como a EIP-8037 interage com contratos inteligentes da mainnet, sem anunciar nova data.

cryptodotnews no X

Nova data depende da revisão técnica

Uma reprodução consistente deve comparar a mesma transação, o mesmo estado e o mesmo limite de gas sob as duas regras. O teste precisa mostrar qual chamada falhou, como o contrato reagiu e quais alterações permaneceram no estado. Além disso, testes acima e abaixo do limite ajudam a identificar efeitos restritos a uma faixa estreita do orçamento.

Um fork bem-sucedido na Hoodi fornecerá evidências sobre as versões de clientes e as transações avaliadas. No entanto, a estabilidade da testnet não substitui testes direcionados de contratos que operam perto dos limites de gas. A próxima comunicação deverá apresentar o cronograma revisado, a configuração do fork e as versões disponíveis aos operadores.

Os desenvolvedores também revisaram a especificação de depósitos de validadores durante a análise das regras de gas. Essa correção exige testes próprios porque afeta outra parte do fork. Por ora, a ativação na Hoodi depende da resolução dos casos que apresentaram diferenças após chamadas falharem com pouco gas.

Google Notícias

Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.