TL;DR
- Desenvolvedores do ethereum integraram uma correção Glamsterdam após identificar uma lógica de transição de fork que poderia redirecionar depósitos de validadores para construtores que compartilham a mesma chave pública.
- O bug afetou a onboarding da Gloas, onde depósitos pendentes poderiam ser mal classificados durante a criação dos registros de construtores e validadores, mas não foi uma exploração em mainnet ativa.
- O pull request #5736 agora separa o roteamento de depósitos por credenciais de retirada, mantém os depósitos de validador em sua fila e adiciona testes de regressão antes da implantação.
Desenvolvedores do ethereum incorporaram uma correção na especificação de consenso para o Glamsterdam após identificar um bug de integração de fork no Gloas, que poderia redirecionar depósitos de validadores para construtores de blocos que compartilham a mesma chave pública. Pull request #5736 foi incorporado ao master em 26 de outubro e altera a forma como os depósitos pendentes são classificados durante o fork. A falha afetou a lógica de transição para a futura atualização do ethereum, não o protocolo atual do mainnet, mantendo o problema dentro do caminho de desenvolvimento e teste para Ethereum.
Gloas Fix separa os caminhos de depósito do validador e do construtor
O problema subjacente envolveu o momento em que o Gloas inicializa seu registry de builder. Sob a regra de roteamento anterior, uma vez que um depósito pendente registrava um builder, depósitos posteriores usando a mesma chave pública poderiam aumentar o saldo desse builder, independentemente de suas credenciais de retirada. Um depósito de validador poderia, portanto, sair da fila de validadores e ser creditado a um builder em vez disso. O bug criou um caminho condicional onde os fundos fornecidos para staking poderiam chegar a uma conta controlada por outra parte.
A descrição do problema ilustra o risco com um protocolo de staking financiando um validador operado por outra parte. Se o operador primeiro enfileirou um depósito válido do construtor usando a mesma chave e ambos os depósitos permaneceram pendentes no fork, o depósito do validador financiado pelo protocolo também poderia ser direcionado ao construtor. Nenhum validador seria criado a partir desse depósito, potencialmente interrompendo procedimentos de contabilidade baseada em prova ou recuperação. O cenário documentado era um caso limite ao nível do protocolo, não evidência de que depósitos na mainnet do ethereum haviam sido desviados.
A correção combinada separa os depósitos de acordo com as credenciais de retirada durante a integração do Gloas. Os depósitos de validadores permanecem na fila de validadores mesmo quando um construtor usa a mesma chave, enquanto os depósitos válidos de construtores podem se registrar ou aumentar os construtores independentemente. Os depósitos existentes de construtores também podem receber aumentos sob as regras revisadas. A alteração alinha a integração aos registros independentes de validadores e construtores descritos pelo EIP-8282 e adiciona testes de regressão cobrindo a ordem e o comportamento de roteamento dos depósitos.
O cronograma é importante porque o Glamsterdam combina alterações da camada de execução de Amsterdam com alterações da camada de consenso de Gloas, incluindo a separação consagrada entre proponente e construtor. A atualização mais ampla já passou pelo teste público, enquanto sua implantação Hoodi foi adiada para revisão adicional e a ativação no mainnet permanece não confirmada. A correção do roteamento de depósitos, portanto, fortalece as especificações para um futuro fork, em vez de corrigir uma exploração ativa no ethereum. Também reforça por que a lógica de transição em torno da staking e da infraestrutura de construção de blocos exige testes antes que as alterações propostas no protocolo alcancem a produção com segurança.