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

Os desenvolvedores do Ethereum finalizaram o cronograma para as próximas atualizações da rede. Mudanças importantes estão previstas para acontecer em 24 de fevereiro, 5 de março e 8 de abril. Decisões-chave foram finalizadas durante a recente chamada ACDE (All Core Developers Execution) 205, realizada em 13 de fevereiro de 2025.

A reunião semanal via Zoom discussões foram lideradas pelo Líder de Suporte de Protocolo da Ethereum Foundation (EF), Tim Beiko. Os desenvolvedores confirmaram que a atualização Pectra seria ativada na testnet Holesky em 24 de fevereiro. Depois, a testnet Sepolia será ativada em 5 de março.

Se ambas as implantações prosseguirem sem problemas, a mainnet do Ethereum receberá a atualização por volta de 8 de abril. 

Beiko disse que coordenaria com as equipes para encontrar um voluntário para implantar os contratos do sistema Pectra em ambas as testnets.

Debates sobre futuras bifurcações do Ethereum e velocidade de atualização

Além disso, a equipe de desenvolvedores discutiu a próxima atualização planejada após a Pectra e a Fusaka. Beiko acordo de trust congelando o escopo da Fusaka para quando a Pectra for lançada na mainnet.

O cronograma permite que os desenvolvedores comecem a trabalhar na Fusaka enquanto também planejam a próxima hardfork seguinte, Glamsterdam. 

A equipe de desenvolvimento do Geth não quer trabalhar com este cronograma. Eles argumentam que foi prematuro consolidar o escopo da Fusaka. A inclusão da Proposta de Melhoria do Ethereum (EIP) EOF na Fusaka provocou um debate considerável. Uma facção de desenvolvedores defende sua exclusão da próxima atualização.

EOF (Ethereum Object Format) é um atualização projetado para melhorar a maneira como os smart contracts são estruturados e executados na blockchain do Ethereum.

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

Lightclient levantou preocupações sobre a incorporação do EOF, destacando o rápido progresso da tecnologia de rollups de zero-knowledge (zkEVMs) do Ethereum. Os desenvolvedores permanecem no escuro quanto à 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 testnet de software Pectra e feedback da comunidade

Os desenvolvedores superaram suas divergências sobre o Fusaka para expressar confiança na contínua implantação do Pectra. O engenheiro de Desenvolvimento e Operações da EF, Parithosh Jayanthi, relatou que a Pectra Devnet 6 estava performando bem, com taxas de participação dos validadores quase perfeitas. 

Além disso, a testnet Ephemery do Ethereum ativou a atualização Pectra algumas horas após a chamada ACDE, permitindo que os desenvolvedores realizassem testes adicionais.

Beiko pediu aos autores dos EIPs do Pectra que movessem suas propostas para a fase de "última chamada" em GitHub. Isso sinaliza os passos finais antes da implementação na mainnet. Ele também analisou o feedback da comunidade Ethereum. Para esse fim, ele observou que o pedido mais comum era acelerar os ciclos de atualização. 

Em resposta, ele sugeriu que os desenvolvedores do Ethereum deveriam visar finalizar o escopo de cada atualização assim que a anterior for ao vivo na mainnet.

O cronograma proposto por Beiko para finalizar o escopo da Fusaka afirma que, até 13 de março, os desenvolvedores devem propor EIPs para inclusão na atualização. Duas semanas depois, em 27 de março, as equipes de clientes compartilharão suas preferências sobre quais EIPs devem ser consideradas para a Fusaka. Finalmente, até 10 de abril, o escopo da atualização será finalizado.

No entanto, o pesquisador da EF, Ansgar Dietrichs, adicionou uma exceção ao cronograma. Ele observou que as melhorias de código do PeerDAS, um componente crítico da atualização Pectra, deveriam ser carregadas na mainnet do Ethereum assim que estivessem concluídas. Ninguém se opôs a esse requisito.

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

Outro ponto de preocupação durante a chamada ACDE foi uma proposta do engenheiro de testes da EF, Mario Vega. Isso veio em relação ao framework de teste da camada de execução do Ethereum. Vega sugeriu tornar o EELS (Ethereum Execution Layer Specifications) e o EEST (Ethereum Execution Specification Test cases) obrigatórios para qualquer EIP incluído em um hard fork. 

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

No entanto, vários desenvolvedores eram contra a proposta. O motivo? O requisito poderia desacelerar o processo de atualização. Van der Wijden argumentou que os mantenedores do EELS poderiam se tornar os gatekeepers de fato da inclusão de EIPs. Por quê? Nem todos os devs são capazes de escrever implementações baseadas em Python de suas propostas. 

Wijden sugeriu uma abordagem alternativa. A ETH deveria ter implementações EELS que poderiam ser submetidas como pull requests não mesclados. Isso impede que a equipe EELS tenha poder de aprovação final sobre as atualizações.

Justin Florentine com blockchain o cliente 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.