Clientes Ethereum lançam novo software após atraso no hard fork

Os principais clientes do Ethereum , incluindo Go-Ethereum (Geth) e Parity, lançaram atualizações de software após uma decisão anterior de adiar a atualização planejada para todo o sistema, chamada Constantinople.

A atualização foiadiado terça-feira durante uma chamada de desenvolvedores, um movimento que ocorreu após a empresa de auditoria de blockchain Chain Security descobrir uma vulnerabilidade de segurança na Proposta de Melhoria Ethereum (EIP) 1283, uma das mudanças planejadas incluídas em Constantinople. Se explorado, o bug teria permitido "ataques de reentrada", permitindo que atores maliciosos retirassem fundos da mesma fonte várias vezes.

Um novo bloco de ativação para a atualização será decidido durante outra chamada no final desta semana.

Para evitar que a bifurcação acontecesse – dado que alguns dos clientes de software na rede já haviam sido atualizados antes da bifurcação – os desenvolvedores das principais implementações do Ethereum começaram a publicar novas versões.

Geth lançou um hotfix de emergência (versão 1.8.21) projetado para atrasar a atualização, embora o desenvolvedor Péter Szilágyi tenha notado que os usuários que não desejam atualizar para a nova versão do cliente também podem fazer o downgrade de seus clientes existentes para a versão 1.8.19 ou continuar executando a versão atual (1.8.20) com uma substituição.

Os clientes do Parity também podem atualizar seus clientes existentes para a versão 2.2.7 (versão estável) ou 2.3.0 (versão beta) ou fazer o downgrade para a versão 2.2.4 (beta).

O chefe de segurança da Parity Technologies, Kirill Pimenov, falando em umbate-papo dos desenvolvedores do CORE Ethereumno Gitter, disse que recomendava que os usuários atualizassem para a nova versão, em vez de fazer o downgrade para uma versão mais antiga, explicando:

"Quero reafirmar — rebaixar o Parity para versões pré-Constantinopla é uma má ideia, T recomendamos isso a ninguém. Teoricamente, até deveria funcionar, mas T queremos lidar com essa bagunça."

Da mesma forma, o gerente de lançamento da Parity, Afri Schoedon, disse ao CoinDesk que ele recomenda a versão 2.2.7, embora as outras duas também devam funcionar.

Em uma postagem de blog, o desenvolvedor CORE Hudson Jameson escreveu que qualquer pessoa que não execute um nó ou participe da rede não precisa fazer nada.

Os proprietários de contratos inteligentes também não precisam fazer nada, embora "vocês possam escolher examinar a análise da vulnerabilidade potencial e verificar seus contratos", escreveu ele.

No entanto, ele ressaltou que a mudança que poderia introduzir o problema potencial não será habilitada.

No momento da publicação do post do blog, pesquisadores de segurança da ChainSecurity,quem descobriu o bug inicialmente, e TrailOfBits estão analisando o blockchain geral.

Ataques de reentrada

Até o momento, nenhuma instância da vulnerabilidade foi descoberta em contratos ativos. No entanto, Jameson observou que "ainda há um risco diferente de zero de que alguns contratos possam ser afetados".

Para que as transferências no Ethereum evitem ataques de reentrada, uma pequena quantidade de Ether, chamada GAS, é paga, o que impede que invasores redirecionem uma transferência para roubar fundos.

No entanto, conforme explicado ao CoinDesk por Hubert Ritzdorf – o indivíduo que encontrou a vulnerabilidade e CTO da Chain Security – um "efeito colateral" do EIP 1283 garante que os invasores possam aproveitar essa pequena quantidade de GAS para fins maliciosos.

"A diferença é que antes você T conseguia fazer algo malicioso com esse BIT de GAS, você conseguia fazer algo útil, mas não algo malicioso, e agora, como algumas operações ficaram mais baratas, você consegue fazer algo malicioso com esse BIT de GAS", disse Ritzdorf.

E embora a questão da reentrada esteja sempre na mente dos desenvolvedores de contratos inteligentes que codificam em Solidity no Ethereum, Matthias Egli – COO da Chain Security – explicou que os CORE desenvolvedores que observassem estritamente a mecânica da máquina virtual T conseguiriam identificar facilmente essa vulnerabilidade.

Ele disse ao CoinDesk:

"É uma coisa da Solidity, não é uma coisa do CORE [da máquina virtual Ethereum ] que na prática permitiu esse ataque. Isso foi parte dessa desconexão que, na prática, pequenas mudanças no custo do GAS permitirão novos tipos de ataques que T foram considerados antes."

Além disso, Ritzdorf acrescentou que a correção para esse problema T é tão fácil quanto atualizar os limites de custo de GAS do Ethereum, explicando que "se alterarmos esse valor para um número pequeno agora, corrigiremos a vulnerabilidade, mas também quebraremos muitos contratos [inteligentes] existentes".

Dessa forma, por enquanto, um adiamento para Constantinopla foi a decisão certa dos CORE desenvolvedores, de acordo com Egli.

"Foi a decisão certa porque pelo menos dá algum tempo para os pesquisadores avaliarem o impacto no mundo real. Com grande probabilidade, este [EIP] será retomado e não incluído no próximo hard fork que agora está atrasado por talvez um mês", ele argumentou.

Próximos passos

No momento em que este artigo foi escrito, os desenvolvedores estavam entrando em contato com exchanges, carteiras, pools de mineração e outros grupos que usam ou interagem com a rede Ethereum .

Os CORE desenvolvedores planejam discutir etapas de longo prazo – incluindo quando executar Constantinople e como corrigir o bug no EIP 1283 – durante outra chamada em 18 de janeiro.

Vários desenvolvedores sugeriram iniciar algum tipo de programa de recompensa por bugs focado na análise do código, a fim de garantir que bugs futuros sejam descobertos com bastante antecedência, em vez de "logo antes do dia [hard fork]."

Szilágyi observou que o PEI tinha sido disponível para revisãopor quase um ano,acrescentando que"talvez não seja uma má ideia fazer algumas bolsas para atrair olhares mais focados."

Imagem de códigovia Shutterstock