A última rodada do desenvolvimento da rede de teste Ethereum Shapella revela alguns bugs

Os testes na rede de teste Zhejiang da Ethereum antes da atualização Shanghai-Capella revelaram alguns bugs, mas nada que afete o cronograma para a introdução do staking na rede. 

Desenvolvedor Marius VanDerWijden documentado um bug de sincronização encontrado por outros clientes que os desenvolvedores estão confiantes de que pode ser corrigido, de acordo com um tópico de Tim Beiko da Ethereum Foundation. O bug não afetará nenhum cronograma estabelecido para a atualização proposta definida para o testnet Sepolia agendado para 28 de fevereiro, observou ele.

A última atualização do devnet de retirada detalhou um teste de estresse composto por 600,000 validadores, 360,000 dos quais realizaram atualizações de credenciais de retirada no momento da bifurcação. Ocorreram picos de clientes na RAM e na CPU e os desenvolvedores avaliarão o número de mensagens de atualização de credenciais perdidas versus registradas nos próximos dias, disse Beiko.

O teste de estresse também revelou um bug entre um cliente proof-of-stake, Prysm, e o cliente Besu, que é projetado para casos de uso permitido. Para sincronizar corretamente, o cliente Prysm espera um certo número de respostas; no entanto, Besu impõe limitações de resposta que o colocam abaixo do limite de sincronização necessário, disse Beiko. A equipe Besu está investigando o assunto.

Bloqueio banido

Depois de uma discussão sobre a melhor forma de otimizar a orientação inicial do cliente, os desenvolvedores finalmente decidido para banir completamente as transações 4844 sem bloqueio, o que mudaria as suposições do cliente sobre as transações e poderia complicar a configuração.

Os desenvolvedores também discutiram como prosseguir com a depreciação da palavra-chave SELFDESTRUCT, que encerra um contrato, remove o bytecode do contrato do blockchain e redireciona os fundos do contato para um endereço especificado.

Embora o caminho a seguir permaneça incerto, há três propostas atuais sobre o assunto em discussão, já que os desenvolvedores buscam encontrar “opções de desativação que não quebrem as coisas”, disse Beiko.

“O desafio aqui é abrir um vetor de ataque desagradável: implantar um contrato, preencher o armazenamento de uma certa maneira e, quando você reimplantar o contrato, o armazenamento antigo ainda está lá e pode ser acessado de maneiras maliciosas”, disse Beiko.