Desenvolvedores principais do Ethereum discutem sobre o processo e o cronograma do Fusaka

A última reunião All Core Devs do Ethereum concentrou-se no processo, e não apenas no código: se deveria ser mantida a janela previamente estabelecida de 30 dias entre os lançamentos dos clientes e o primeiro fork na testnet, à medida que o upgrade Fusaka avança. Alguns participantes defenderam reafirmar o compromisso para que as equipes de infraestrutura e aplicativos tenham tempo para se adaptar; outros argumentaram por mais flexibilidade para evitar atrasos mais amplos no roadmap.

O debate ocorreu em meio a resultados mistos nas devnets. Na Devnet-3, um exercício planejado de não-finalidade se estendeu além do previsto, segundo Barnabas Busa, da equipe de Dev Ops. “Queríamos fazer aproximadamente dois dias primeiro, e agora já estamos no quinto dia”, disse ele, observando que a participação caiu e depois voltou a ultrapassar 50%. A finalização exige que mais de dois terços do total de stake efetivo concordem.

Em contraste, uma testnet separada se recuperou rapidamente após um reinício coordenado: “A chain se recuperou em, acho que duas horas”, disse Busa. O exercício testa como as variáveis interagem em um incidente real, o que pode ajudar o Ethereum a se recuperar em uma crise.

Leia mais: O upgrade Fusaka do Ethereum pode enfrentar atraso

Com correções previstas para os próximos dias, o plano de curto prazo é restaurar a Devnet-3 à plena saúde, refazer o teste e então iniciar a Devnet-5.

No entanto, o ponto mais sensível foi a disciplina de agendamento para redes públicas. Lightclient destacou a promessa vigente: “Está escrito 30 dias antes da primeira testnet.” Ele alertou contra a mudança de metas por conveniência, com base na avaliação dos core devs sobre o tempo necessário para outras equipes que não estavam presentes na chamada.

A preocupação prática é como melhorar o ritmo dos hard forks. Comprimir os intervalos entre os testes pode acelerar os forks, mas aumenta o risco de que as equipes downstream lancem atualizações apressadas. O argumento contrário é que pipelines prolongados atrasam tudo o que está na fila, o que pode desagradar a comunidade mais ampla do Ethereum.

“Não acho que devemos escolher cronogramas com base no que a comunidade necessariamente quer”, disse Lightclient. “As pessoas que estão entregando o software disseram que querem 30 dias para fornecer um software de alta qualidade que a comunidade vai usar.”

Ainda assim, a troca um pouco tensa caminhou para a manutenção do processo escrito, a menos que as partes interessadas peçam explicitamente uma mudança.

Também houve frustração com a recorrência da mesma questão a cada ciclo. “Acho que é um precedente muito ruim continuar deixando as decisões mudarem”, disse Lightclient, observando que desenvolvedores de aplicativos e L2s normalmente não participam das chamadas principais e dependem de janelas previsíveis para agendar seus próprios lançamentos.

Por enquanto, o consenso é prosseguir como se o buffer de 30 dias permanecesse em vigor, enquanto se busca ativamente novas opiniões, disse o coordenador Tim Beiko. “Devemos preparar o cronograma com o que está no documento [de processo] e, em paralelo, verificar com as partes interessadas que são afetadas.” Se um caminho mais rápido realmente tiver amplo apoio, o grupo formalizaria isso por escrito.