Glamsterdam sai do calendário de outubro da Hoodi enquanto Ethereum verifica riscos em contratos

O teste Hoodi de 26 de outubro foi cancelado, incluindo seu limite planejado de 200 milhões de gas. Os desenvolvedores estão examinando uma proposta de reprecificação em relação a contratos já presentes na mainnet.

O Ethereum cancelou um teste que estava previsto para ocorrer na próxima segunda-feira. O aviso da Ethereum Foundation de 22 de outubro afirma que o Glamsterdam não será ativado na Hoodi às 17:42:48 UTC de 26 de outubro, e nenhuma nova época foi definida. O aumento do limite de gas para 200 milhões que o acompanhava também foi retirado do cronograma da testnet. Trata-se de um adiamento de configuração futura, não de uma reversão de blocos já registrados pela Hoodi.

Os desenvolvedores tomaram a decisão de investigar como a EIP-8037, uma mudança no preço de criação de novo estado do Ethereum, interage com contratos na mainnet. A Foundation não afirmou que a atualização quebrou a mainnet. Também não definiu uma data para um fork de produção. O risco operacional imediato está na Hoodi: clientes ou configurações personalizadas que ainda carregam o antigo horário de ativação podem divergir do cronograma revisado. A questão mais profunda é como alterar o custo de trabalho dentro de uma transação sem prejudicar aplicações que incorporaram os antigos números no código.

O fork da Hoodi de 26 de outubro está fora do calendário

O anúncio da Hoodi de 16 de outubro especificava a época 132.352 e o slot 4.235.264. Ele combinava as mudanças Amsterdam da camada de execução com as mudanças Gloas da camada de consenso e um limite de 200 milhões de gas. O novo aviso substitui integralmente essas instruções. Os operadores devem ler as notas de versão mais recentes para ambos os tipos de cliente; uma versão anterior descrita como compatível com Glamsterdam pode ainda conter a ativação da Hoodi agora cancelada.

Isso é mais do que uma nota de rodapé de agendamento. Um validador precisa seguir as mesmas regras de rede que seus pares. Se parte de seu software espera novas regras de execução ou deveres de consenso na antiga época enquanto a rede não o faz, ele pode perder a capacidade de seguir a cadeia canônica. A infraestrutura de builders e validadores pode ter sua própria configuração. A Foundation, portanto, orienta os operadores a verificar as versões revisadas dos clientes e remover configurações personalizadas obsoletas antes de 26 de outubro, em vez de presumir que não fazer nada é seguro porque um fork foi adiado.

A Sepolia ativou o Glamsterdam em 6 de outubro e testou um limite de 200 milhões de gas, conforme registrado pela cobertura dessa ativação. A ativação bem-sucedida de uma testnet é útil, mas não conclusiva para outra. O ensaio restante da Hoodi foi adiado precisamente porque a investigação dos contratos precisa de tempo. Não há carimbo de data/hora substituto publicado para extrapolar uma data para a mainnet.

O Glamsterdam foi ativado na Sepolia em 6 de outubro, onde os desenvolvedores testaram um limite de 200 milhões de gas. O teste bem-sucedido não resolve como a EIP-8037 afetará contratos já em execução na mainnet. O ensaio da Hoodi está adiado enquanto os desenvolvedores investigam essas interações, e nenhuma data substituta foi anunciada.

A sequência mudou mais de uma vez este ano. A reportagem de setembro sobre o plano do Sepolia descreveu problemas na devnet e um problema de implementação do EIP-8037 antes de o teste público prosseguir. Esses problemas anteriores não são prova da mesma causa que a investigação contratual de 22 de outubro. Eles mostram por que as datas têm sido condicionais à medida que as equipes de clientes passam de testes privados para redes públicas. Preocupações separadas sobre o comportamento dos builders em testnets dizem respeito a outra parte do Glamsterdam e não devem ser confundidas com a reprecificação. O aviso mais recente dá uma razão específica para a pausa no Hoodi: investigação adicional da interação do EIP-8037 com contratos da mainnet.

Por que criar estado custa mais na proposta

Uma transação pode executar cálculos e pode deixar dados que a rede precisa reter e acessar posteriormente. Criar uma nova conta, abrir um novo slot de armazenamento ou implantar bytecode de contrato aumenta esse estado persistente. O EIP-8037 propõe cobrar mais por essas operações e medir a parte de criação de estado separadamente. O objetivo é aproximar o preço da carga de maior duração sobre os nós, especialmente se os blocos forem autorizados a carregar mais trabalho.

A tabela ilustrativa da proposta coloca o componente de criação de estado de uma nova conta em 183.600 de gas, em comparação com os atuais 25.000; um novo slot de armazenamento em 97.920, em comparação com 20.000; e uma implantação de 24 kilobytes em 37.784.880, em comparação com 4.947.200. A tabela não é uma previsão universal da taxa em ETH que um usuário pagará. Ela isola um componente sob uma constante proposta, com outras cobranças de execução por cima, e o custo final em moeda depende do preço do gas no momento. A dimensão da mudança explica por que contratos com limites apertados merecem uma análise mais atenta.

Uma proposta relacionada de acesso ao estado, o EIP-8038, reprecifica algumas leituras e escritas. O guia de impacto para desenvolvedores da Fundação diz que esses custos de gas foram ajustados substancialmente pela última vez no fork Berlin em 2021, enquanto o estado cresceu. A reprecificação planejada foi concebida em conjunto com o trabalho para aumentar a taxa de transferência; tornar os blocos maiores sem contabilizar operações caras de estado poderia tornar a validação mais difícil para os operadores de nós. A pausa, portanto, afeta tanto a compatibilidade das aplicações quanto o plano de escalabilidade, embora seu gatilho anunciado seja a interação do EIP-8037.

Uma chamada externa mostra por que isso pode ser difícil de perceber antecipadamente. Um chamador pode deliberadamente passar apenas gas suficiente para que um destinatário execute uma ação limitada, assumindo que qualquer trabalho adicional falhará com segurança. Se uma conta ou acesso de armazenamento reprecificado agora consumir essa permissão, o destinatário pode falhar durante um pagamento rotineiro, mesmo que o usuário tenha fornecido bastante gas para a transação externa. Alterar a estimativa da carteira não reescreve a permissão interna. Os desenvolvedores precisam inspecionar o caminho do código e o tratamento de falhas em torno dele, porque algumas aplicações consideram uma chamada externa falhada como motivo para reverter, enquanto outras continuam e registram um resultado diferente.

Os padrões transfer e send do Solidity historicamente encaminham um estipêndio de 2.300 de gas. Muitas equipes já deixaram de depender desse estipêndio, mas contratos implantados podem permanecer em uso por anos. A Fundação identifica estipêndios fixos como uma categoria de risco; ela não diz que toda chamada que os utiliza falhará. Um destinatário que realiza pouco trabalho pode permanecer dentro da permissão, enquanto um contrato que toca estado recentemente reprecificado pode excedê-la. Testar as contrapartes reais importa mais do que tratar a mera presença de um nome de função como prova de quebra.

Uma segunda classe de problema está na automação. Carteiras, relayers e custodiantes podem armazenar limites de gas padrão para tarefas regulares. Uma operação que funcionou com sucesso por anos pode começar a ficar sem gas mesmo que o contrato da aplicação em si esteja sólido. Aumentar uma estimativa no frontend pode corrigir essa rota, mas um agente agendado ou um cliente usando uma carteira mais antiga pode continuar a enviar o limite anterior. Os desenvolvedores, portanto, precisam identificar não apenas o código afetado, mas também os serviços que constroem transações para ele.

Quais contratos podem enfrentar problemas?

A Fundação reproduziu transações históricas da mainnet sob o cronograma proposto. A maioria não teve problema significativo. Dos casos sinalizados, muitos foram concluídos após o aumento do limite de gas; um grupo menor poderia falhar mesmo com substancialmente mais gas. Um estipêndio fixo, uma quantidade de gas codificada de forma rígida enviada para outro contrato, ou um desvio baseado no resultado de gasleft() pode alterar o caminho que uma transação percorre. O aviso anterior sobre contratos descreveu essas categorias antes de Hoodi adquirir sua data de outubro. O adiamento atual torna os casos sem resposta urgentes, mas não mostra que todos os contratos Ethereum são vulneráveis.

Considere uma aplicação que envia fundos para outro contrato enquanto fornece uma permissão de gas fixa. O contrato receptor pode precisar de mais gas sob o novo cronograma para acessar o armazenamento. Se a permissão do chamador estiver embutida no código implantado, simplesmente aumentar o limite da transação de nível superior pode não dar mais espaço à chamada receptora. Uma falha poderia então exigir uma correção no nível do contrato ou uma rota diferente para os usuários. Por outro lado, se o único problema for que uma carteira estimou uma transação usando preços antigos, uma estimativa atualizada e um limite fornecido mais alto podem ser suficientes. Os dois casos são operacionalmente distintos.

Um problema particularmente incomum do EIP-8037 envolve código que mede o trabalho subtraindo duas leituras do gas restante. A proposta explica que o reservatório de gas de estado pode fazer gasleft() aumentar sob algumas circunstâncias. Um cálculo que espera uma diminuição não negativa poderia se comportar de forma diferente, e contratos implantados imutáveis não podem ser corrigidos no local. O impacto preciso depende do código e do caminho da transação, razão pela qual uma reprodução de transações históricas reais importa mais do que um aviso genérico sobre taxas mais altas.

A ferramenta de busca da Fundação permite que construtores examinem endereços de contratos afetados e o motivo de uma divergência sinalizada. Ela recomenda testar em uma devnet usando o novo cronograma e inspecionar código que assume limites fixos mesmo quando um contrato não aparece na lista. Uma reprodução histórica é uma triagem, não um inventário completo do comportamento futuro: uma rota que nenhum usuário chamou durante a amostra ainda pode conter uma suposição vulnerável. As equipes precisam de seus próprios testes para os ramos que operam.

O resultado de uma reprodução também depende da amostra de transações. Um contrato pode conter uma permissão de gas fixa em uma função que raramente foi chamada; se essa rota estiver ausente do histórico reproduzido, a ferramenta não pode demonstrar sua falha. A Fundação aconselha os mantenedores a verificar o código mesmo quando seu endereço não aparece na lista de afetados. Uma aplicação grande pode ter vários contratos, frontends atualizáveis e agentes automatizados, cada um fornecendo um limite de gas diferente. A equipe precisa testar a operação como seus usuários realmente a invocam, incluindo uma carteira ou bot que pode estar mantendo uma estimativa antiga em um cache.

Para um contrato cujo comportamento muda, corrigir a interface que envia transações nem sempre é suficiente. Se a permissão de gas de uma chamada interna foi compilada em código imutável, seu proprietário pode precisar de uma migração para um novo contrato. Tal migração pode envolver mover saldos, aprovações ou permissões de usuário, e comunicar o novo endereço. A dificuldade depende do design do produto; não há evidências de que todo contrato sinalizado exija esse trabalho. É precisamente por isso que a distinção entre uma falha corrigível por limite e um contrato potencialmente quebrado importa tanto para a equipe quanto para seus clientes.

A orientação de testes é especialmente relevante para aplicações que usam abstração de conta ou múltiplas chamadas de contrato para completar uma única ação do usuário. Um checkout pode aprovar um ativo, encaminhar uma troca e liquidar um comerciante em uma única sequência. Se uma etapa interna usa uma permissão codificada de forma rígida, o cliente pode ver um pagamento falho sem saber qual contrato atingiu o limite. Reproduzir toda a sequência sob as regras propostas é mais informativo do que verificar o método público de cada contrato isoladamente. Os mantenedores devem registrar a primeira etapa que falhou e se um limite de gas externo maior realmente altera o resultado.

Os contratos também podem se comportar de forma diferente após uma chamada falha, em vez de simplesmente parar. Um fallback que registra um evento, credita um saldo interno ou tenta uma segunda rota pode continuar em condições que seus autores originais nunca esperaram. Essa divergência é o motivo pelo qual um resultado de teste descrito apenas como “transação bem-sucedida” pode ser inadequado. O estado de saída e os eventos precisam ser comparados com a execução antiga. A categoria da Fundação de execução bem-sucedida com alterações captura essa possibilidade sem declará-la automaticamente prejudicial.

Carteiras, RPCs e fábricas enfrentam trabalhos diferentes

Carteiras e provedores de chamada de procedimento remoto estimam o gás que uma transação precisa antes de o usuário assinar. A EIP-8037 diz que eth_estimateGas e o software de nó devem considerar tanto o gás de execução quanto a nova dimensão de state-gas. Uma constante antiga em cache pode subestimar uma transação com uso intenso de estado. Os usuários podem então ver transações falhas, mesmo que o contrato funcionasse com um limite estimado adequadamente. Atualizações de infraestrutura são, portanto, parte da compatibilidade, não apenas uma conveniência sobreposta ao protocolo.

Fábricas de implantação determinística apresentam outro caso restrito. A EIP-8037 discute fábricas originalmente colocadas em endereços padrão usando transações pré-assinadas com limites de gás codificados. Em uma rede nova que adota o novo cronograma antes de a fábrica existir, a antiga implantação pré-assinada poderia ficar sem gás. A proposta diz explicitamente que instâncias já implantadas na mainnet existente e em redes de camada 2 não são afetadas por esse cenário de gênese específico. Relatar a ressalva é importante: seria enganoso sugerir que toda fábrica já usada na Ethereum está prestes a desaparecer.

Os construtores também precisam distinguir um contrato inalterado de custos inalterados. Uma transação pode ter sucesso, mas consumir uma quantidade diferente de gás. Um negócio que agrupa implantações ou cria muitos slots de armazenamento pode enfrentar uma estrutura de custos materialmente diferente, mesmo quando nenhuma função falha. Seu produto pode precisar de cotações de taxas diferentes, uma política de subsídio revisada ou uma mudança na forma como armazena informações. As categorias de replay da Fundação separam execução idêntica, execução alterada mas bem-sucedida, falhas corrigíveis por limite e contratos potencialmente quebrados justamente por esse motivo.

Os números na EIP-8037 merecem outra qualificação. Seu exemplo converte o gás proposto para ETH usando uma taxa base assumida de 0,08 gwei. Se a taxa base mudar, o ETH pago pelo mesmo gás também muda. Um desenvolvedor que compara a tabela com uma fatura existente deve adicionar encargos de execução e as condições reais da transação, em vez de apresentar uma mudança de custo de estado de sete vezes como um aumento de sete vezes no pagamento completo de um usuário. O propósito da proposta é atribuir custos aos recursos; a taxa final de uma pessoa depende da mistura desses recursos na transação.

A escala da reprecificação proposta deve ser lida em conjunto com o objetivo de capacidade. Mais espaço para transações em um bloco pode tornar a rede cara de validar se essas transações criarem desproporcionalmente estado persistente. A EIP-8037 atribui um medidor separado a esse crescimento para que o custo não desapareça dentro de um limite de gás nominal maior. A EIP-8038 trata dos acessos ao estado existente. Elas resolvem partes diferentes da questão de recursos, e um construtor de blocos funcional sozinho não consegue estabelecer que as aplicações lidam corretamente com a reprecificação.

As listas de acesso de bloco da Ethereum têm uma tarefa separada. Elas informam aos clientes quais contas e locais de armazenamento um bloco toca, ajudando a organizar parte do trabalho de validação em paralelo. Isso pode permitir maior throughput em condições favoráveis, mas não apaga o armazenamento persistente adicionado por novas contas e slots. Uma testnet precisa executar a atualização combinada sob atividade realista, porque uma melhoria em uma dimensão pode expor uma restrição em outra. O adiamento deixa esse exercício combinado na Hoodi por fazer, por enquanto.

Muitos usuários encontrarão essas mudanças primeiro indiretamente, por meio do limite de gás cotado pela carteira ou da estimativa de taxa de uma aplicação. Uma transação que não cria novo estado pode ter um efeito diferente de uma que implanta um contrato considerável. Uma interface de negociação que promete um custo de transação fixo precisaria verificar se sua promessa ainda cobre as operações que realiza. Generalizações de que todas as taxas da Ethereum se movem em uma direção seriam prematuras sem um cronograma final para a mainnet, demanda observada e os parâmetros finais.

O número de 200 milhões era uma configuração de testnet

A Glamsterdam combina mais do que reprecificação. A separação propositor-construtor consagrada muda a transferência de um payload de bloco, enquanto as listas de acesso em nível de bloco ajudam os clientes a identificar as contas e o armazenamento que um bloco tocará. Os desenvolvedores planejavam testar essas mudanças com um limite de gás de 200 milhões na Hoodi, igual ao da Sepolia. O número era um parâmetro de testnet. Nunca foi uma promessa de que a mainnet da Ethereum adotaria imediatamente o mesmo limite ou que as taxas dos usuários cairiam em uma certa porcentagem.

Remover o cronograma de limite de gas da Hoodi mantém juntos os componentes do fork adiado. Os operadores não estarão testando a capacidade maior pretendida sob o Glamsterdam naquela rede na próxima segunda-feira. Os desenvolvedores ainda podem usar a Sepolia e devnets criadas especificamente para investigar os efeitos da reprecificação. O ensaio ausente na Hoodi afeta a sequência na qual as equipes de clientes podem ganhar confiança antes de escolher um momento para a mainnet, mas a Fundação não publicou um cronograma de produção revisado.

A economia é menos direta do que um slogan sobre gas mais barato. Cobrar mais pela criação de estado durável pode tornar uma transação específica mais cara com o mesmo preço de gas. Uma capacidade segura maior, se posteriormente adotada e utilizada, poderia aliviar a congestão em outras condições. A demanda determina quanto espaço de bloco os usuários disputam, e as configurações finais do protocolo determinam quais operações se tornam mais ou menos caras. Nem a pausa nem um teste bem-sucedido resolveriam essas variáveis de mercado por si só.

A coordenação pública tem custos, mas prosseguir com uma incerteza conhecida pode ter custos maiores. Os operadores prepararam software para a época antiga e agora precisam remover esse cronograma; os desenvolvedores de aplicações têm que continuar testando contra uma proposta cuja forma final pode mudar. O custo dessa reinicialização é visível. Uma regra de mainnet que fizesse um contrato amplamente utilizado falhar seria mais difícil de reverter, e as consequências poderiam envolver fundos ou aplicações dependentes. O aviso de 22 de outubro não quantifica tal risco, mas deixa claro que os desenvolvedores consideraram a interação importante o suficiente para interromper o ensaio na Hoodi.

Uma proposta revisada poderia preservar o objetivo de cobrar pelo estado enquanto altera a forma como o reservatório de gas funciona ou as regras de transição para contratos existentes. Poderia, em vez disso, manter a especificação e exigir correções direcionadas nas aplicações. Nenhuma decisão pública entre esses caminhos aparece no aviso de adiamento. Os leitores devem resistir a tratar uma investigação como uma escolha final de design. As emendas precisas, se houver, importarão mais do que quantos dias a Hoodi espera.

Por que os desenvolvedores escolheram esperar

O processo do Ethereum permite que as equipes de clientes ajustem um plano antes de uma ativação em testnet pública. A decisão de 22 de outubro na All Core Devs Execution call 248 segue avisos anteriores e contato com construtores afetados. O aviso público identifica a área sob investigação, mas não publica uma contagem final de contratos em risco, uma nova versão da EIP-8037 ou uma data em que a investigação terminará. Chamar o atraso de falha confirmada em todos os contratos implantados iria além do comunicado; chamá-lo de uma reorganização rotineira de calendário perderia sua causa declarada.

A configuração antiga precisa ser retirada em ambas as camadas. Os clientes de execução processam transações e estado, enquanto os clientes de consenso coordenam validadores e o cronograma do fork. Uma rede só pode testar a atualização se esses clientes concordarem com as regras e o momento. Os operadores da Hoodi que instalaram versões especificamente para 26 de outubro devem procurar as notas de versão revisadas. A Fundação diz que adicionará links para novas versões de clientes à medida que forem confirmadas, em vez de tratar sua tabela de compatibilidade original como atual.

Há também uma lição na ordem das evidências. Reproduzir o histórico revelou um pequeno grupo afetado; as testnets públicas revelam o comportamento de clientes e aplicações em um ambiente ao vivo; a mainnet expõe as regras finais ao uso econômico em escala. Cada etapa responde algo que a anterior não pode. Um pequeno atraso na Hoodi pode comprar tempo para o trabalho nos contratos, mas não prova por si só que as regras eventuais são seguras. A decisão de prosseguir deve seguir os resultados dos testes e instruções claras aos operadores.

Vale explicitar o escopo do aviso aos operadores. Um detentor comum de mainnet não precisa alterar uma carteira porque o cronograma da Hoodi foi retirado. Um operador de nó da Hoodi que se preparou para o fork precisa revisitar as notas de versão. Um engenheiro de protocolo investigando a EIP precisa determinar se o comportamento de contrato encontrado nas reproduções é aceitável, corrigível por ferramentas ou um motivo para alterar a proposta. Uma equipe de aplicação precisa testar suas próprias rotas de execução. Esses são públicos diferentes com prazos diferentes, e um único alerta de "atualização adiada" não dá a cada um deles a instrução correta.

O próximo post da Fundação também pode resolver como os desenvolvedores se comunicarão com as equipes afetadas. Seu guia de agosto dizia que o contato direto havia começado, mas uma contagem de contatos por si só não estabeleceria que um contrato foi reparado. A evidência testável é um contrato atualizado, uma configuração de gas revisada ou um fallback documentado para um produto específico. Alguns contratos imutáveis podem exigir uma migração de usuários, o que levanta uma preocupação separada de comunicação e segurança: os clientes devem saber onde vive uma substituição legítima e evitar endereços fraudulentos. Nenhuma migração em massa foi anunciada, então isso permanece como contingência para equipes cujo código não pode ser alterado no local.

O que vem antes de outra data

Um cronograma revisado deve indicar quais regras da EIP-8037 serão testadas, o que mudou caso a proposta seja alterada e quais versões de cliente concordam com a nova época Hoodi. Os mantenedores de aplicações precisam de tempo para executar buscas de contratos afetados, atualizar estimadores, elevar limites onde isso for suficiente e examinar permissões internas de chamadas codificadas onde não for. Se um contrato implantado potencialmente quebrado não tiver um caminho direto de atualização, sua equipe pode precisar explicar como os usuários chegarão a um substituto antes de qualquer fork da mainnet.

Evidências públicas incluiriam a metodologia de replay e descobertas atualizadas de contratos afetados, resultados de devnets com o cronograma final de gas, uma ativação Hoodi com diversos clientes em concordância e um anúncio separado da mainnet. Mesmo uma ativação Hoodi limpa seria um ensaio, não uma garantia de um preço específico de ETH ou de uma taxa final de transação. A história prática para os usuários é que nenhuma ação na mainnet em 26 de outubro foi anunciada. A ação imediata pertence aos operadores da Hoodi e às equipes cujas aplicações fazem suposições sobre gas.

O que observar

• Lançamentos de clientes: Atualizações de execução e consenso que removem explicitamente a antiga ativação da Hoodi em 26 de outubro.
• Descobertas da EIP-8037: Novos resultados de replay, mudanças nas regras de gas propostas e o tratamento de contratos com limites codificados ou lógica de gasleft().
• Uma época de substituição: Um plano datado para a Hoodi que restaure uma configuração testável após a investigação.
• Correções de aplicações: Relatos de builders afetados explicando se limites mais altos são suficientes ou se o código implantado precisa de outra rota.
• Aviso sobre a mainnet: Um cronograma de produção distinto da Fundação após a sequência da testnet e a coordenação dos clientes.

Perguntas frequentes