Ethereum corrige bug de Glamsterdam relativo a depósitos de staking
A correção impede que os depósitos de staking acabem por engano nas mãos de builders. A fixação já foi incorporada nas regras de consenso, mas os clientes ainda têm de a processar.
Pontos principais
- Os desenvolvedores da Ethereum corrigiram um erro de Glamsterdam que podia atribuir depósitos de staking a builders em vez de a validators.
- A alteração foi inicialmente rejeitada, mas, após revisão adicional e testes, acabou por ser aprovada na segunda-feira nas especificações de consenso.
- As equipas de clientes ainda têm de incorporar a fixação no seu software; uma nova data para Hoodi e o planeamento do mainnet ainda não são conhecidos.
Os desenvolvedores da Ethereum corrigiram um erro na próxima atualização Glamsterdam que poderia fazer com que ETH de serviços de staking acabasse nas mãos de builders em vez de novos validators. A alteração foi afinal implementada na segunda-feira, depois de a mesma correção ter sido rejeitada uma semana antes.
O que podia correr mal
Glamsterdam separa duas tarefas que, neste momento, ainda decorrem em conjunto. Os builders compõem blocos com transações, enquanto os validators fazem staking de ETH para proteger a rede e, em seguida, escolhem e confirmam esses blocos. Ambas as partes podem depositar ETH, mas esse dinheiro deve ser acompanhado em separado.
O problema estava na forma como a Ethereum processaria depósitos que ainda aguardavam crédito. Ao abrigo das antigas regras preliminares, um operador podia primeiro registar-se como builder com uma determinada chave pública. Se, depois disso, um serviço de staking depositasse ETH para iniciar um validator sob essa mesma chave, então ambos os depósitos podiam ser atribuídos ao builder.
O investigador avsetsin descreveu, nesse contexto, um cenário em que o operador poderia levantar os fundos do protocolo. O validator não seria então criado, o que faria com que o serviço de staking não tivesse prova para recuperar o dinheiro. Segundo avsetsin, tratava-se de constatações de código condicionais e não de exploits em produção confirmados. Não foram comunicadas perdas.
Porque é que a fixação regressou
A alteração proposta foi encerrada a 19 de outubro. Justin Traglia, que mantém as especificações de consenso da Ethereum, escreveu então que, nesse momento, não havia apoio suficiente dos clientes para avançar com a alteração. Os clientes são os programas de software separados que executam validators para participar na rede.
Após revisão adicional, a fixação foi reaberta. Avsetsin acrescentou testes a 23 de outubro e Traglia aprovou a alteração na segunda-feira. Nas novas regras, os depósitos pendentes são ordenados de acordo com as suas withdrawal credentials, a definição que determina para onde o dinheiro pode acabar por ir. Assim, os depósitos de validators permanecem com os validators, mesmo que um builder use a mesma chave.
Significado para a Ethereum
A alteração faz agora parte das especificações de consenso da Ethereum, mas as equipas de clientes ainda têm de incorporar a mudança no seu software. Isso torna a fixação relevante para todos os que acompanham a rede ao nível de testnet, sobretudo agora que Glamsterdam já estava a correr em Sepolia e o lançamento planeado em Hoodi foi adiado. Esse atraso em Hoodi mostra que os desenvolvedores ainda têm de ponderar vários componentes da atualização em paralelo. Ainda não há uma nova data para Hoodi e, sem esse passo, também não pode ser definida uma data para o mainnet.
