Ethereum suspende fork Hoodi do Glamsterdam: o que os auditores encontraram?

Os desenvolvedores do Ethereum colocaram em espera o fork da testnet Hoodi do Glamsterdam enquanto analisam as descobertas sobre como as aplicações se comportam quando uma transação fica com pouco gás. A atualização altera a forma como a rede cobra por algumas operações que tocam ou expandem seu estado, e os auditores descobriram que até mesmo contratos escritos antes da atualização podem se comportar de maneira diferente sob as regras propostas.

Os desenvolvedores do Ethereum deveriam fazer o fork da Hoodi em 26 de outubro. Eles adiaram esse teste, e em 6 de novembro o desenvolvedor da Ethereum Foundation Marius van der Wijden disse que ele permanecia em espera enquanto os desenvolvedores resolviam os problemas identificados na revisão de gás.

A preocupação concentra-se em um detalhe que a maioria das pessoas encontra apenas quando uma transação falha. Contratos podem chamar outros contratos e decidir o que fazer se essas chamadas retornarem sem sucesso. O código que toma essa decisão pode parecer exatamente o mesmo após uma atualização, mas seguir um caminho diferente porque a rede agora cobra por partes da operação de maneira diferente.

É por isso que uma atualização voltada para a forma como o Ethereum contabiliza o estado se tornou uma questão para os desenvolvedores de aplicações, bem como para as equipes que escrevem os clientes do Ethereum. Ambos precisam saber quais suposições antigas sobrevivem à mudança.

O que o Glamsterdam muda sobre o gás

EIP-8037 altera como o protocolo contabiliza as operações que criam estado. O estado do Ethereum inclui registros como o armazenamento de contratos. Uma mudança pode persistir entre transações, então seu custo tem implicações para os nós que mantêm a cadeia após a transação original terminar. A proposta separa a contabilização de alguma criação de estado do gás de execução comum, com um reservatório que pode ser utilizado para operações elegíveis.

EIP-8038 reprecifica as operações que acessam o estado. As duas propostas afetam partes diferentes de um caminho de execução. Um contrato pode ler um valor, fazer uma chamada externa e gravar um resultado. Revisar apenas o preço proposto da gravação final ignora o efeito das leituras e chamadas anteriores sobre o orçamento disponível quando a execução chega a ela.

Uma aplicação familiar pode, portanto, produzir um resultado diferente mesmo quando um usuário fornece as mesmas entradas de transação. A questão importante é quais diferenças refletem a reprecificação pretendida e quais expõem uma suposição da qual um cliente ou um contrato depende.

Como uma chamada falha pode mudar o resultado final

Considere um contrato que chama um segundo contrato para executar uma etapa em uma operação maior. Se o segundo contrato falhar, o chamador pode interromper tudo ou lidar com a falha e continuar. Um processador em lote pode registrar um item malsucedido e seguir adiante. Outra aplicação pode esperar que toda a operação seja revertida se a chamada falha consumir gas suficiente.

A análise da ChainSecurity descreve como a nova contabilização pode afetar essa distinção. O Ethereum já limita quanto gas um chamador pode repassar adiante sob a regra EIP-150. Aproximadamente um sessenta e quatro avos pode permanecer com o chamador no caso relevante. A questão é quanto o chamador realmente tem disponível quando a execução retorna, e quanto custa concluir as instruções nesse caminho.

Suponha que uma aplicação trate uma falha de chamada como um resultado de negócio comum. Se ela tiver gas suficiente para concluir o manipulador de falha, poderá registrar um resultado ou continuar o restante da transação. Se ficar sem gas ao fazer isso, a transação externa é revertida. Esses resultados deixam registros diferentes, embora a chamada interna tenha falhado em ambos os casos.

O auditor também examinou verificações baseadas em gasleft(). Um contrato pode usar a instrução para comparar seu orçamento de execução restante com um mínimo codificado. Um limite calibrado sob um cronograma pode se tornar um mau preditor sob outro, particularmente quando o contrato encontra operações de estado ou repassa gas para outro endereço. O contrato não tem maneira automática de revisar um número que seu desenvolvedor incorporou quando foi implantado.

O que os auditores precisam estabelecer

A atualização de novembro da Fundação descreve oito premissas em análise. Há pelo menos duas questões distintas para teste. Os clientes que implementam as novas regras devem chegar ao mesmo resultado para uma determinada transação. Os revisores de aplicações também devem identificar casos em que esse resultado compartilhado difere do que os contratos existentes esperam.

Um teste para a primeira questão pode executar a mesma transação em vários clientes e comparar resultados de estado e gas. Um teste para a segunda precisa seguir a lógica da própria aplicação. Importa se o contrato trata um callback falho como um sinal para prosseguir, se registra uma mudança de estado antes da chamada e se consegue distinguir uma rejeição de negócio de uma chamada que nunca teve gas suficiente.

Esses caminhos podem ser fáceis de perder em um teste de implantação convencional. Um orçamento de transação típico pode levar a chamada e seu manipulador através de ambos os cronogramas. Um orçamento deliberadamente apertado pode expor a diferença. Testes de limite, portanto, precisam incluir chamadas falhas e casos próximos da quantidade de gas necessária para entrar ou concluir o manipulador de falha.

O que o Hoodi pode mostrar

O Glamsterdam já havia chegado à testnet Sepolia do Ethereum, onde os desenvolvedores testaram um limite de 200 milhões de gas. O Hoodi daria aos desenvolvedores uma implantação compartilhada adicional na qual exercitar a atualização revisada.

Um fork de testnet pública dá às equipes de clientes e aos operadores de aplicações um ambiente comum no qual executar essas verificações. Os operadores podem atualizar clientes em um cronograma compartilhado, comparar seus resultados e testar ferramentas contra as regras do fork. As equipes de aplicações podem verificar se a simulação de transações e a estimativa de gas consideram as mesmas mudanças que estão vendo durante a execução.

Um fork Hoodi bem-sucedido daria aos desenvolvedores evidências sobre as versões e transações que testaram. A questão de longo prazo é o que aplicações representativas fazem nos limites de seus orçamentos de gas. Uma nova data de fork será mais fácil de avaliar ao lado de um registro de quais casos foram reproduzidos, o que mudou em resposta e como as equipes testaram isso.

O trabalho de gas ocorre em paralelo a outras correções. Os desenvolvedores do Ethereum revisaram separadamente a especificação de depósito do validador enquanto a revisão de gas do Hoodi estava em andamento. Essas correções precisam de seus próprios testes porque afetam uma parte diferente do fork.

Por enquanto, a mais recente atualização dos desenvolvedores sobre os riscos de gas dá uma razão para a suspensão e diz que o trabalho no Hegota continua. Ela deixa o momento do próximo teste do Glamsterdam para uma decisão subsequente.

Como os limites de gas e os custos de estado se encaixam

Um limite de gas de bloco mais alto dá ao Ethereum espaço para mais trabalho dentro do seu sistema de contabilização. O preço atribuído a uma operação individual determina quanto desse espaço a operação ocupa. Uma alteração no limite e uma alteração nos preços podem, portanto, afetar partes diferentes da mesma transação.

Parte do trabalho termina quando a transação termina. Criar estado é diferente porque os dados podem persistir, deixando os operadores de nós com algo para armazenar e processar depois. Um novo slot de armazenamento, conta ou contrato pode aumentar essa carga mesmo que o aplicativo que o criou receba pouco tráfego posteriormente.

A EIP-8037 altera como o custo de certa criação de estado é contabilizado. A EIP-8038 reprecifica o acesso ao estado, o que pode incluir operações envolvendo registros que já existem. Uma transação que lê um valor, chama outro contrato e cria uma entrada de armazenamento pode encontrar ambas as mudanças durante uma única execução.

Um limite de bloco mais alto por si só não diz se essa sequência custará mais ou menos. Ele descreve o espaço disponível para o bloco como um todo. O caminho da transação e o preço de cada operação determinam se ela pode caber dentro do gas fornecido pelo remetente.

Essa distinção já era relevante quando a Sepolia começou a testar a Glamsterdam com um limite de 200 milhões de gas. O teste mostrou o que os desenvolvedores estavam executando naquela rede. A suspensão na Hoodi trata de saber se as regras estão prontas para a próxima testnet, incluindo o comportamento de aplicativos que dependem de suposições anteriores sobre gas.

As oito suposições em análise

O repositório do auditor da Ethereum Foundation agrupa seus exemplos por mudanças nos preços das operações e mudanças na forma como o gas é rastreado. Os números no repositório vêm de uma versão fixada da especificação proposta e podem mudar se as propostas forem revisadas.

O primeiro grupo de preocupações envolve permissões fixas e o custo de concluir o trabalho após uma chamada. Os desenvolvedores podem ter definido um limite de gas para uma operação que agora custa mais. Uma reserva destinada a pagar por uma gravação final pode não ser mais suficiente. Em outro caso, a pequena fração retida por um chamador pode ser suficiente para concluir um caminho de falha que o aplicativo anteriormente esperava reverter.

As mudanças na contabilização introduzem outras possibilidades. Se um reservatório separado ainda puder financiar a criação de estado elegível, um chamador pode gravar um registro após uma chamada falha mesmo quando seu orçamento de execução comum estiver apertado. O resultado final do chamador pode então depender de quais operações usam esse orçamento separado.

Limpar um slot criado anteriormente na mesma transação pode devolver algum gas de estado imediatamente na especificação revisada. Uma chamada que reverte também pode devolver gas de estado. Código escrito com a suposição de que todo o gas consumido antes de uma reversão se perde pode, portanto, interpretar mal o que aconteceu.

Um par de medições de gasleft() pode igualmente dar uma visão incompleta do custo do trabalho. Um contrato que usa a diferença para cobrar alguém ou calcular um reembolso depende de suposições sobre como o gas muda entre as duas leituras. Cobranças retiradas de um pool separado e gas de estado devolvido durante a execução podem alterar essa relação.

O oitavo caso envolve a EIP-7702, que permite que uma conta autorize a delegação a código de contrato. Uma transação pode ser incluída mesmo quando uma autorização dentro dela não entrou em vigor porque ficou sem gas. Uma carteira ou serviço que usa apenas a inclusão da transação para inferir que a delegação funcionou pode tratar uma ação incompleta como concluída.

O repositório afirma que muitas descobertas recebidas por seus autores diziam respeito a valores fixos ou reservas. Ele pede que desenvolvedores e auditores testem seus aplicativos contra os exemplos e relatem problemas. O inventário identifica padrões que exigem revisão. Ele não implica que todo aplicativo que usa um desses padrões produzirá uma perda.

Como uma chamada falha ainda pode deixar uma transação bem-sucedida

Uma transação Ethereum pode conter várias chamadas. Um contrato pode solicitar que outro contrato execute uma etapa e então decidir como responder ao resultado. Uma chamada interna falha e uma transação falha são resultados distintos.

Um processador em lote fornece um exemplo útil. Se um item falhar, o processador pode registrar essa falha e passar para o próximo item. Se ficar sem gas antes de conseguir registrar o resultado, a transação externa pode reverter e desfazer alterações anteriores. A mesma falha interna, portanto, deixa um estado final diferente dependendo do que o chamador pode fazer depois.

Uma aplicação diferente pode tratar uma chamada falha como motivo para mudar quem pode enviar uma solicitação ou se ela pode ser tentada novamente. Se o chamador conseguir completar um caminho que a aplicação esperava reverter, o estado resultante pode persistir. A consequência de segurança depende do que o caminho completado realmente registra.

Um ator pode ser capaz de escolher quanto gas uma transação fornece. Se essa pessoa puder deixar gas suficiente para o contrato externo entrar em um caminho, mas pouco demais para a chamada interna terminar, a falha pode ser induzida pelo orçamento da transação. Um contrato que age com base na falha precisa distinguir esse caso de uma chamada que chegou ao destinatário e falhou legitimamente.

O limite de encaminhamento da EIP-150 é uma parte disso. Um chamador que encaminha tanto gas quanto permitido retém aproximadamente um sessenta e quatro avos sob a regra relevante. O valor retido ainda precisa pagar pelas instruções que se seguem. Se essas instruções são concluídas depende do cronograma e da contabilização aplicada a elas.

Um contrato pode ser vulnerável a uma faixa estreita de orçamentos. Dê à chamada interna gas suficiente e ela funciona normalmente. Dê à transação inteira pouco demais e o caminho externo reverte. O intervalo problemático é aquele em que a chamada interna falha enquanto o chamador ainda tem o suficiente para executar uma ação que o desenvolvedor não pretendia para aquela falha.

Por que alterar um número fixo de gas pode não resolver o problema

Um limite codificado em duro pode dar a um contrato uma maneira simples de verificar que tem gas suficiente antes de fazer uma chamada. O desenvolvedor pode ter testado o limite com transações comuns e deixado uma margem para o trabalho que se segue. O número torna-se uma dependência do cronograma sob o qual foi escolhido.

Uma operação também pode custar valores diferentes dependendo de a aplicação estar atualizando um registro existente ou criando um. Uma transferência para alguém que já tem um saldo pode encontrar um caminho de armazenamento diferente de uma transferência que cria um primeiro saldo. Um teste que cobre apenas destinatários recorrentes pode perder o caminho mais caro.

O ponto em que o contrato mede o gas importa. Uma leitura imediatamente antes da chamada é diferente de uma leitura após vários acessos de estado e da própria chamada. Um contrato que infere o motivo da falha a partir da última leitura assume que entende o que poderia ter sido cobrado ou retornado no meio.

Alterar um estipêndio pode ter consequências próprias. Pode permitir que um caminho que antes falhava seja concluído, e também pode dar ao destinatário gas suficiente para realizar trabalho que não poderia realizar sob a permissão antiga. O desenvolvedor precisa saber o que a permissão pretendia impedir antes de ajustá-la.

Alguns contratos podem ser alterados por meio de um processo de governança ou administrativo. Outros são imutáveis ou dependem de componentes que não podem ser alterados no local. Mesmo quando um contrato pode ser revisado, serviços que estimam, patrocinam ou retransmitem suas transações também podem precisar atualizar suas próprias suposições.

O que uma reprodução convincente precisa mostrar

Um teste pode começar com a mesma transação, estado e limite de gas sob as regras antigas e propostas. Uma comparação deve identificar qual chamada retorna uma falha, o que o chamador faz em seguida e se a transação registra quaisquer alterações que não persistiam antes.

Testar orçamentos logo acima e abaixo do limite ajuda a mostrar se o efeito ocupa uma faixa estreita. Também pode identificar onde a execução diverge. Uma verificação antecipada de saldo, o valor encaminhado ao destinatário e uma escrita no manipulador de falhas são pontos diferentes nos quais uma alteração pode surgir.

O revisor então precisa perguntar quem pode alcançar esse caminho. Uma alteração reproduzida em um contrato de teste estabelece uma diferença na execução. Uma aplicação real pode exigir uma autorização, verificar uma condição separada ou tornar a operação afetada passível de nova tentativa. Esses detalhes determinam se alguém pode forçar um resultado indesejado.

Há também um teste separado para equipes de clientes. Todos os clientes de execução devem chegar ao mesmo resultado para uma transação sob a mesma configuração de fork. Uma divergência entre clientes é um problema diferente de todos os clientes produzirem consistentemente um resultado que uma aplicação não previu.

Uma suíte de testes precisa de caminhos bem-sucedidos, assim como de falhas. Forçar toda chamada com falha a reverter pode impedir uma mudança de estado indesejada, mas também remover uma capacidade legítima de concluir o restante de um lote. O comportamento pretendido da aplicação determina o que uma correção precisa preservar.

Uma boa reprodução deve tornar o estado final fácil de inspecionar. Se um registro de falha permanece após uma execução e desaparece após outra, o teste pode mostrar a diferença exata em vez de depender de um relatório geral sobre uso de gas. Isso facilita avaliar tanto o risco quanto uma mudança proposta.

O que as testnets públicas acrescentam após uma reprodução local

Um desenvolvedor pode testar um caso extremo em um fork local ou em um ambiente de cliente controlado. Uma testnet pública então permite que vários operadores executem a mesma atualização e comparem seu comportamento em condições compartilhadas. Ela também dá às equipes de carteira e de infraestrutura um lugar para testar seu próprio software contra as regras ativas.

Sepolia e Hoodi servem a etapas diferentes nesse processo. A ativação na Sepolia mostrou que os desenvolvedores podiam executar o código planejado naquela rede e examinar sua operação sob o limite de gas configurado. Hoodi lhes dá uma implantação adicional após tratar das descobertas que se tornaram importantes durante a revisão.

As aplicações, o tráfego e o estado histórico em uma testnet diferem da mainnet. Um fork tranquilo pode fornecer evidências sobre a concordância dos clientes e transações rotineiras sem exercitar todos os padrões de contrato dos quais os usuários dependem. Uma reprodução direcionada fornece evidências sobre um caso extremo que pode estar ausente do tráfego comum da testnet.

As instruções de atualização são outra parte do teste. Um operador precisa de uma versão que implemente a configuração pretendida e um ponto de ativação preciso. Uma aplicação precisa saber quando suas simulações devem começar a usar as regras revisadas. Uma nova data é útil junto com esses detalhes.

O adiamento de outubro e o relatório de status de novembro descrevem a mesma suspensão em momentos diferentes. O primeiro removeu a data agendada para Hoodi. O segundo explicou que os problemas ainda precisavam ser resolvidos. O próximo aviso de implantação pode mostrar quais mudanças estão prontas para os operadores testarem.

Como as carteiras podem relatar sucesso enquanto uma ação falha

As carteiras comumente estimam o gas antes de pedir ao usuário para assinar. A estimativa depende do estado e das regras que o nó aplica em sua simulação. Um serviço que usa uma configuração de fork mais antiga pode fornecer uma estimativa que não é mais adequada para uma transação que a cadeia atual executa.

Uma transação que reverte ainda pode custar gas ao remetente. Uma transação externa que é concluída após capturar uma falha interna pode ser mais difícil de interpretar. A cadeia pode registrar a transação geral como bem-sucedida enquanto uma ação dentro dela não aconteceu. A carteira pode precisar dos eventos ou do estado da aplicação para explicar a diferença ao usuário.

Relayers e patrocinadores de transações enfrentam um problema relacionado. Eles podem escolher o orçamento ou pagar os custos de uma transação que outra pessoa solicita. Se o orçamento não cobrir mais o caminho pretendido, o patrocinador pode pagar por uma execução que não entrega a ação solicitada.

Indexadores podem ver o efeito após a execução. Um caminho de falha que agora é concluído pode produzir logs ou mudanças de estado que o sistema downstream não via anteriormente. O indexador ainda segue o estado real da cadeia. Uma aplicação que depende do indexador pode precisar mudar como interpreta o registro resultante.

Um teste de ponta a ponta pode comparar a estimativa de uma carteira, o orçamento submetido por um relayer, o resultado de execução do cliente e a explicação da interface. Cada etapa pode ser bem-sucedida por si só enquanto o usuário ainda recebe um relato enganoso sobre quais ações entraram em vigor. A distinção importa mais onde a aplicação trata um resultado como final.

O que resolveria a suspensão de Hoodi

A Fundação está pedindo às equipes de aplicação que identifiquem as suposições que usam e forneçam casos que os desenvolvedores possam reproduzir. Alguns problemas podem ser tratados por meio de mudanças nas regras de gas propostas. Outros podem exigir que um provedor de aplicação ou de infraestrutura revise como lida com o novo comportamento.

Se as especificações mudarem, o teste relevante é se um caso que antes divergia agora alcança o resultado pretendido. Se os desenvolvedores mantiverem uma mudança de comportamento, as equipes de aplicação precisam de detalhes suficientes para determinar se seu software depende do resultado anterior. Ambos os desfechos dependem de descrever a chamada afetada e o que persiste após ela.

Uma especificação revisada também precisa chegar aos builds de cliente que os operadores executam. Um build que suportava uma configuração anterior do Glamsterdam pode não conter alterações subsequentes. Os números de versão em um novo aviso do Hoodi identificariam quais versões podem ser testadas juntas.

A atualização de novembro da Fundação afirma que o trabalho no Hegota continua em paralelo. Isso significa que a suspensão do fork anterior não abrange todas as decisões de desenvolvimento sobre o próximo. Para o Glamsterdam, o próximo marco relevante é um cronograma revisado do Hoodi com uma configuração que os desenvolvedores estejam prontos para executar publicamente.

Um fork bem-sucedido daria às equipes um registro compartilhado para examinar antes de uma decisão sobre a mainnet. Os casos que motivaram o atraso continuam sendo os testes mais claros de se as regras revisadas estão prontas. Esses testes precisam mostrar o que acontece quando uma chamada falha perto de seu limite de gas e a transação externa ainda tem trabalho a fazer.

O que os números de gas propostos mostram sobre diferentes caminhos

O repositório da Fundação fornece um exemplo concreto da diferença entre criar estado e atualizá-lo. Sob sua especificação fixada do Glamsterdam, uma escrita fria que cria um novo slot é dividida entre custos de execução e uma cobrança de estado substancialmente maior. Uma escrita em um slot existente também é reprecificada, mas segue um cálculo diferente.

A diferença pode atingir dois usuários fazendo o que parece ser a mesma solicitação de aplicação. Um usuário pode ter usado o serviço antes, então o contrato atualiza uma entrada existente. Outro pode precisar de um registro novo. Uma permissão de gas que funciona para o primeiro usuário pode falhar para o segundo.

O repositório também afirma que um reservatório separado está disponível apenas acima de um limite de gas de transação especificado na configuração testada. Em transações menores, os custos de estado vêm do orçamento comum. Esse limiar torna importante testar vários orçamentos em vez de assumir que o reservatório se comporta da mesma forma para cada chamada.

Código que lê o gas restante pode, portanto, observar apenas parte dos recursos da transação em alguns casos. Os dados que ele lê ainda são significativos para o orçamento que a instrução expõe. O que muda é a inferência que a aplicação pode tirar sobre o total de recursos que foram consumidos ou permanecem disponíveis.

Os exemplos de gas estão vinculados à configuração proposta. Eles não fornecem um multiplicador único que possa ser aplicado às estimativas existentes de uma carteira. Uma escrita de armazenamento pela primeira vez, uma chamada usando um estipêndio fixo e uma delegação falha exigem cada uma uma verificação separada, porque encontram partes diferentes das regras.

É também por isso que uma data revisada do Hoodi seria mais útil com a revisão da especificação e a lista de casos cobertos pela versão. Esses detalhes permitiriam às equipes reexecutar testes que correspondem às suas aplicações antes de tirar conclusões da estabilidade geral da testnet.

O que observar

• Cronograma do Hoodi: Uma data de fork revisada deve identificar as versões de cliente e a configuração de fork que os operadores devem executar.
• Concordância entre clientes: Testes entre clientes podem mostrar se os clientes de execução alcançam o mesmo estado e os mesmos resultados de gas em torno dos novos limites.
• Comportamento do contrato: Reproduções devem mostrar quando uma chamada externa malsucedida deixa ao chamador gas suficiente para concluir e o que a transação externa registra.
• Revisões da proposta: Alterações na EIP-8037 ou na EIP-8038 ajudarão a mostrar quais achados de revisão exigiram uma mudança de protocolo.
• Ferramentas de aplicação: Resultados de simulação e estimativa de gas podem mostrar se carteiras e provedores de infraestrutura refletem corretamente as regras do fork.

Perguntas frequentes