Chamada ACDE do Ethereum 205: Grandes atualizações Ethereum chegando em 24 de fevereiro, 5 de março e 8 de abril

Os desenvolvedores Ethereum finalizaram o cronograma para as próximas atualizações da rede. Grandes mudanças estão programadas para ocorrer em 24 de fevereiro, 5 de março e 8 de abril. As principais decisões foram finalizadas durante a recente Chamada de Execução de Todos os Desenvolvedores Principais (ACDE, na sigla em inglês), a 205ª, realizada em 13 de fevereiro de 2025.

As discussões das reuniões quinzenais via Zoom foram lideradas por Ethereum (EF). Os desenvolvedores confirmaram que a atualização Pectra será ativada na testnet Holesky em 24 de fevereiro. Posteriormente, a testnet Sepolia entrará em operação em 5 de março. Tim Beiko, Líder de Suporte ao Protocolo da Fundação

Se ambas as implementações ocorrerem sem problemas, a rede principal do Ethereumreceberá a atualização por volta de 8 de abril. 

Beiko disse que coordenaria com as equipes para encontrar um voluntário para implantar ostracdo sistema Pectra em ambas as redes de teste.

Debates sobre futuros forks Ethereum e velocidade de atualização

Além disso, a equipe de desenvolvedores discutiu a próxima atualização planejada após Pectra e Fusaka. Beiko propôs congelar o escopo de Fusaka até o lançamento de Pectra na rede principal.

O cronograma permite que os desenvolvedores comecem a trabalhar em Fusaka enquanto também planejam o hard fork subsequente, Glamsterdam. 

A equipe de desenvolvimento do Geth não quer trabalhar com esse cronograma. Eles argumentam que foi prematuro definir o escopo do Fusaka. A inclusão do EOF ( Ethereum Improvement Proposal) no Fusaka gerou um debate considerável. Uma facção de desenvolvedores defende sua exclusão da próxima atualização.

EOF (Ethereum Object Format) é uma atualização que visa aprimorar a forma como os contratos inteligentestracestruturados e executados na Ethereum blockchain

O desenvolvedor Lightclient, do Geth, se opôs à aceleração do congelamento do escopo de Fusaka. Ele argumenta que Ethereumpodem mudar nos próximos dois anos. Lightclient apontou que, embora os desenvolvedores visem ciclos de atualização de seis meses, atrasos reais podem estendê-los para oito meses ou mais. Isso significa que melhorias importantes podem não ser implementadas por anos. 

A Lightclient levantou preocupações em relação à incorporação do EOF, destacando o rápido progresso da tecnologia de rollup de conhecimento zero do Ethereum(zkEVMs). Os desenvolvedores ainda desconhecem a interação dessas mudanças com a máquina virtual.

Durante a discussão, o desenvolvedor do Geth, Marius van der Wijden, listou seu escopo preferido para o Fusaka, que incluía PeerDAS, FOCIL, EOF e limites superiores para modexp. O engenheiro de operações de desenvolvimento da EF, Parithosh Jayanthi, contestou, afirmando que o FOCIL não estava tão pronto para implementação quanto o PeerDAS e o EOF.

Atualizações da rede de testes do software Pectra e feedback da comunidade

Os desenvolvedores superaram suas divergências sobre Fusaka e expressaram confiança na implementação em andamento do Pectra. O engenheiro de desenvolvimento e operações da EF, Parithosh Jayanthi, relatou que o Pectra Devnet 6 estava apresentando um bom desempenho, com taxas de participação de validadores quase perfeitas. 

Além disso, a rede de testes Ephemery do Ethereumativou a atualização Pectra algumas horas após a chamada da ACDE, permitindo que os desenvolvedores realizassem mais testes.

Beiko pediu aos autores do Pectra EIP que movessem suas propostas para a fase de "última chamada" no GitHub. Isso sinaliza as etapas finais antes da implementação na rede principal. Ele também analisou o feedback da Ethereum . Nesse sentido, observou que a solicitação mais comum era a de acelerar os ciclos de atualização. 

Em resposta, ele sugeriu que os desenvolvedores Ethereum deveriam procurar finalizar o escopo de cada atualização assim que a anterior fosse lançada na rede principal.

O cronograma proposto pela Beiko para a finalização do escopo do Fusaka estabelece que, até 13 de março, os desenvolvedores devem propor EIPs (Propriedades de Integração de Engenharia) para inclusão na atualização. Duas semanas depois, em 27 de março, as equipes dos clientes compartilharão suas preferências sobre quais EIPs devem ser consideradas para o Fusaka. Finalmente, até 10 de abril, o escopo da atualização será finalizado. 

No entanto, o pesquisador da EF, Ansgar Dietrichs, acrescentou uma exceção ao cronograma. Ele observou que as melhorias no código do PeerDAS, um componente crítico da atualização Pectra, deveriam ser enviadas para a rede principal Ethereum assim que estivessem concluídas. Ninguém se opôs a essa exigência.

Preocupações com os padrões de teste EELS e EIP

Outro ponto de preocupação durante a reunião da ACDE foi uma proposta do Engenheiro de Testes da EF, Mario Vega. Essa proposta dizia respeito à estrutura de testes da camada de execução Ethereum . Vega sugeriu tornar as EELS (Especificações da Camada de ExecuçãoEthereum ) e os EEST (Casos de Teste de Especificação de ExecuçãoEthereum ) obrigatórios para qualquer EIP incluída em um hard fork. 

Ele sugeriu que isso melhoraria o fluxo de trabalho de testes e padronizaria a forma como os EIPs são avaliados antes da adoção.

No entanto, vários desenvolvedores se opuseram à proposta. O motivo? A exigência poderia atrasar o processo de atualização. Van der Wijden argumentou que os mantenedores do EELS poderiam se tornar os guardiões de fato da inclusão de EIPs. Por quê? Nem todos os desenvolvedores são capazes de escrever implementações em Python para suas propostas. 

Wijden sugeriu uma abordagem alternativa. A ETH deveria ter implementações do EELS que pudessem ser submetidas como solicitações de pull request não mescladas. Isso impediria que a equipe do EELS tivesse o poder de aprovação final sobre as atualizações.

Justin Florentine, do Ethereum Besu, aconselhou a comunidade a considerar a criação de uma linguagem de script adicional. Isso esclareceria se um EIP pode ser incluído sem casos de teste EELS ou EEST.