Desenvolvedores do Ethereum CORE debatem benefícios de hard forks mais frequentes

Com que frequência é necessário alterar o consenso?

Um grupo de desenvolvedores veteranos de código aberto do Ethereum discutiu o assunto em uma reunião quinzenal na sexta-feira, na qual eles levantaram a possibilidade de que atualizações de todo o sistema, também chamadas de hard forks, no software poderiam ser implementadas a cada três meses.

Querendo "verificar a temperatura", o desenvolvedor que fez a pergunta explicou que certas propostas de melhoria do Ethereum (EIPs) futuras, como rendas estataisexigiria múltiplas atualizações espaçadas sequencialmente para efeito total.

Três meses, no entanto, aos olhos de Joseph Delong, engenheiro sênior de software no estúdio de capital de risco Consensys, é “muito QUICK para uma reviravolta”.

O líder da equipe da Fundação Ethereum , Péter Szilágyi, concordou, explicando:

“Como um desenvolvedor de cliente [de software], se seu único trabalho é implementar hard forks e fazê-los, então três meses é bom, mas geralmente os clientes exigem muita manutenção. Então, se você começar a fazer hard forks de três meses, isso essencialmente tirará todo o tempo da manutenção geral e das melhorias de desempenho.”

O líder de segurança da Ethereum Foundation, Martin Hoste Swende, embora concordasse que um hard fork a cada três meses "seria algo ruim", observou que casos específicos com mudanças simples acordadas por unanimidade poderiam ter tempos de execução mais curtos.

“A ideia não seria agendar um hard fork a cada três meses, mas ver se o recurso X está pronto e se existem casos de teste e se ele está implementado em todos os clientes. Se sim, então podemos fazer um hard fork em breve”, argumentou Swende durante a chamada.

Mas encorajando os desenvolvedores a levar seus planos “um passo” de cada vez, Fredrik Harryson, CTO da Parity Technologies, observou que mesmo um cronograma de seis meses para um hard fork planejado do Ethereum nunca foi alcançado.

“Há algumas coisas que provavelmente precisamos automatizar para fazer [hard forks mais curtos] realmente bem. Muito do tempo que vai para o hard fork não é apenas fazer o código. É tudo o que acontece”, disse Harryson.

Além disso, o consultor da Ethereum Foundation, Greg Colvin, observou que a maioria das equipes que criam clientes de software Ethereum não tem atualmente "a pessoa certa" para lidar com tarefas essenciais para a implementação do hard fork, como "configurar redes de teste, executar casos de teste, fazer testes", entre outras responsabilidades.

A isso, Harryson respondeu que o problema era não ter finanças suficientes para embarcar tais membros da equipe. “Para nós, é dinheiro. T temos dinheiro suficiente para isso”, brincou Harryson.

Atualizações em várias etapas

Mas não é apenas uma questão de haver ou não hard forks mais frequentes.

Os desenvolvedores durante a chamada de hoje também discutiram se havia necessidade de mudanças ambiciosas e de longo prazo no atual blockchain do Ethereum em vista de uma mudança iminente para o Ethereum 2.0 – uma nova rede Ethereum que, uma vez totalmente ativada, os usuários migrariam da rede principal atual.

Sugerindo que desenvolvedores como Alexey Akhunov e o fundador do Ethereum Vitalik Buterin alertaram contra “mudanças que T são para a sobrevivência da cadeia [atual do Ethereum]”, Harryson perguntou:

“Quanto oscilamos fora disso porque [EIP 615] leva a uma longa cadeia de melhorias que duram vários anos antes de vermos benefícios enormes com isso.”

EIP 615 é uma das cinco propostas consideradas para inclusão no próximo hard fork do Ethereum chamado Istanbul. Ele visa introduzir melhorias no próprio coração da base de código do Ethereum conhecida como Ethereum Virtual Machine (EVM), que é responsável por executar todas as linhas de código de autoimplantação – também chamadas de contratos inteligentes – na plataforma.

O EVM também é uma Tecnologia essencial que outras iniciativas de blockchain empresarial, como Hiperlivro-razãoforam relatados no passado para construir interoperabilidade com.

“O design do EVM dificulta a execução de baixo custo de gás e alto desempenho. Propomos seguir adiante com propostas para resolver esses problemas, reforçando as garantias de segurança e ampliando os limites de desempenho do EVM,”escreveos autores do EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic e Christina Reitwiessner.

No entanto, conforme observado por Swende durante a chamada de hoje, o EIP 615, conforme proposto, exigiria pelo menos dois hard forks para ser totalmente executado e “um efeito positivo de velocidade” nos cálculos de código reais no EVM não seria perceptível até que o último hard fork fosse executado.

“Essa é minha principal preocupação sobre esse EIP, é muito trabalho, mas T acho que levará a um EVM muito melhor. Pode ser melhor para as ferramentas externas, como se você estivesse fazendo uma análise reversa das propriedades de segurança de um contrato inteligente”, disse Swende.

Zelenka sugeriu que tais ferramentas são essenciais para garantir a “compatibilidade futura” contínua com as próximas atualizações do EVM, como o eWASM, e uma experiência de integração tranquila para desenvolvedores de contratos inteligentes em vista de “uma data de lançamento indeterminada do Ethereum 2.0”.

“Existem outras opções para desenvolvedores de contratos inteligentes por aí. Precisamos KEEP o Ethereum 1.x vivo e isso significa continuar a se mover”, argumentou Zelenka na chamada de hoje.

Concordando em continuar o debate e a discussão sobre o EIP nas próximas semanas, Swende concluiu que, no momento, ele continua cético sobre "implementar mudanças tão grandes no mecanismo antigo, que basicamente leva algumas bifurcações antes que ele finalmente se estabilize".

Mas concordando com o sentimento incerto em torno do futuro do Ethereum 2.0, Harryson, que levantou a questão inicial sobre atualizações ambiciosas de vários hard forks, disse:

“T devemos ajustar nosso roteiro ou pensamento com base no que o Ethereum 2.0 pode ou não ser.”

Imagem do garfo via Shutterstock