Os desenvolvedores do Ethereum mesclaram uma correção para uma falha no tratamento de depósitos na próxima atualização Glamsterdam que poderia ter permitido que um construtor de blocos recebesse ETH destinado a um novo validador, após uma decisão inicial de rejeitar a mudança proposta.
Resumo
- O Ethereum mesclou uma correção no tratamento de depósitos do Glamsterdam em 26 de outubro.
- A falha poderia ter creditado depósitos de staking a construtores que compartilham a mesma chave pública.
- Os desenvolvedores inicialmente rejeitaram a correção antes de aprovar testes adicionais.
- Uma investigação separada de compatibilidade de contratos atrasou a ativação do Hoodi no Glamsterdam.
De acordo com as especificações de consenso do Ethereum, o mantenedor Justin Traglia mesclou a correção em 26 de outubro depois que o desenvolvedor avsetsin identificou um problema com a forma como os depósitos pendentes seriam processados durante o fork Gloas. A mudança separa os depósitos de construtores dos depósitos de validadores de acordo com suas credenciais de saque, evitando que fundos entrem na conta errada quando ambos usam a mesma chave pública.
A vulnerabilidade dizia respeito a regras em desenvolvimento, não a um roubo confirmado da mainnet do Ethereum. Os desenvolvedores incorporaram a correção às especificações, embora os clientes de consenso individuais ainda precisem implementar e testar o comportamento revisado.
Falha do Ethereum Glamsterdam expôs risco nos depósitos de validadores
O problema surgiu de mudanças planejadas sob a separação consagrada entre proponente e construtor do Glamsterdam, que atribui a construção de blocos e a proposta de blocos a funções diferentes. Os construtores montam os payloads de transações, enquanto os validadores participam da proposta e confirmação de blocos por meio do sistema de proof-of-stake do Ethereum.
O pesquisador avsetsin descreveu a falha em 12 de outubro, identificando um problema nas regras usadas para processar depósitos em espera quando a rede é atualizada. Se um construtor se registrasse usando uma chave pública antes de um depósito de validador chegar sob a mesma chave, a lógica proposta poderia creditar ambos os depósitos ao construtor.
O pesquisador delineou um cenário envolvendo um operador de staking recebendo fundos de um protocolo de staking líquido para estabelecer um novo validador. Ao se registrar primeiro como construtor, o operador poderia fazer com que o depósito de validador do protocolo entrasse no saldo do construtor, onde o endereço de saque poderia estar sob o controle do operador.
“O operador pode sacar os fundos do protocolo”, alertou avsetsin no relatório do GitHub.
Como o validador esperado não seria criado, o serviço de staking poderia ter dificuldade para obter a prova necessária para concluir seus procedimentos normais de depósito e recuperação.
O pesquisador examinou a exposição potencial envolvendo Lido, Origin e Rocket Pool por meio de pesquisa preliminar de código. Essas descobertas eram condicionais à forma como os protocolos individuais tratavam os depósitos, e o relatório não estabeleceu que os projetos haviam sofrido uma exploração.
Desenvolvedores revertem decisão após revisão adicional
A correção proposta inicialmente encontrou resistência dos desenvolvedores de clientes do Ethereum, apesar da descrição do pesquisador sobre o risco de roteamento de depósitos. Em 19 de outubro, Traglia fechou o pull request após discussões entre os desenvolvedores principais.
“Não houve apoio suficiente dos clientes para fazer essa mudança neste momento”, escreveu Traglia.
A decisão não permaneceu em vigor, com os desenvolvedores reabrindo a proposta em 23 de outubro após exame adicional.
Posteriormente, o revisor potuz aprovou a abordagem, mas solicitou mais testes para combinações específicas de depósitos. Avsetsin adicionou esses testes em 23 de outubro, cobrindo casos em que depósitos de construtor e de validador compartilham uma chave pública, mas exigem tratamento separado.
A mudança final foi mesclada nas especificações de consenso do Ethereum em 26 de outubro após revisão adicional dos clientes. Ela direciona depósitos válidos de validadores para a fila de validadores, ao mesmo tempo que permite que depósitos legítimos de construtores registrem ou adicionem fundos a um construtor existente.
As novas regras distinguem os depósitos por meio de credenciais de saque, que determinam os arranjos de saque permitidos. Elas preservam registros separados de construtor e validador mesmo quando a mesma chave pública aparece em ambas as funções.
O atraso do Hoodi dá aos desenvolvedores mais tempo para investigar
A atualização da especificação chegou enquanto os desenvolvedores do Ethereum revisavam um problema separado que afetava a ativação programada do Glamsterdam na testnet Hoodi. A Ethereum Foundation adiou a atualização de 26 de outubro depois que pesquisadores identificaram riscos de compatibilidade envolvendo a EIP-8037.
Como o crypto.news relatou anteriormente sobre o adiamento, a decisão removeu tanto as mudanças de execução do Amsterdam quanto as mudanças de consenso do Gloas da ativação planejada do Hoodi. O aumento proposto para um limite de 200 milhões de gas foi adiado junto com elas.
O pesquisador do Ethereum Toni Wahrstätter explicou que a EIP-8037 poderia interferir em contratos inteligentes que dependem de suposições sobre o gas restante durante a execução. Ele identificou casos em que a contabilização de gas poderia fazer com que uma transação fosse revertida inesperadamente ou permitisse um caminho de execução que os desenvolvedores presumiam ser inalcançável.
O problema de compatibilidade de contratos é distinto da falha de depósito do builder abordada na correção do GitHub. Ambos dizem respeito ao Glamsterdam, mas o adiamento da Foundation em 22 de outubro citou especificamente a investigação adicional da interação da EIP-8037 com contratos existentes.
Os clientes do Ethereum devem implementar as regras revisadas
O Glamsterdam já foi ativado na testnet Sepolia em 6 de outubro, onde os desenvolvedores examinaram mudanças na construção de blocos e maior capacidade de processamento de transações. O ensaio subsequente no Hoodi permanece sem data agendada, sem data confirmada para ativação na mainnet do Ethereum.
A correção de depósito mesclada contém testes de regressão que cobrem como os depósitos são classificados durante a transição do Gloas. As equipes de clientes devem incorporar a mudança de especificação em seu software e concluir testes adicionais antes que as regras atualizadas possam operar durante uma futura atualização de rede.
