Desenvolvedores do Ethereum propõem ativar o hard fork Constantinople no final de fevereiro

ATUALIZAR (18 de janeiro de 2019, 15:40 UTC):A ativação do hard fork Constantinople foi definida para o bloco número 7.280.000, programado para ser lançado em 27 de fevereiro, de acordo com o desenvolvedorPéter Szilágyi.

----------

Os desenvolvedores do CORE do Ethereum propuseram ativar o Constantinople – uma atualização planejada para todo o sistema que foi cancelada no início desta semana – no final de fevereiro.

Também chamado de hard fork, o Constantinople está previsto para entrar no ar em algum momento entre 26 e 28 de fevereiro, com um número de bloco a ser determinado em uma data futura.

A proposta foi feita durante uma ligação telefônica para desenvolvedores CORE em Sexta-feira manhã, e os participantes da chamada incluíram o criador do Ethereum Vitalik Buterin e outros desenvolvedores, incluindo Hudson Jameson, Lane Rettig, Afri Schoedon, Péter Szilágyi, Martin Holste Swende, Danny Ryan e Alexey Akhunov, entre outros.

A decisão foi tomada depois que a empresa de auditoria de contratos inteligentes ChainSecurity sinalizouTerça-feira uma vulnerabilidade de segurança em uma das cinco Propostas de Melhoria do Ethereum (EIPs) definidas para inclusão em Constantinopla relacionadas aos custos de armazenamento de dados no blockchain.

Como resultado da vulnerabilidade, o Constantinople, agora programado para ativação no mês que vem, não contará com a inclusão do EIP com bugs, que será testado e remodelado para inclusão em um hard fork subsequente.

Em vez disso, Constantinople será emitido em duas partes simultaneamente na rede principal. A primeira atualização incluirá todos os cinco EIPs originais e uma segunda atualização removerá especificamente o EIP 1283.

Esta estratégia – sugerida pela primeira vez por Szilágyi durante a chamada de hoje – visa garantir que as redes de teste e as redes privadas que já implementaram a atualização completa de Constantinopla possam implementar facilmente uma correção sem reverter nenhum bloqueio.

“Minha sugestão é definir dois hard forks, Constantinople como está atualmente e a correção de Constantinople que apenas desabilita esse recurso... Com dois forks, todos que realmente fizeram o upgrade podem ter um segundo fork para realmente fazer o downgrade, por assim dizer”, explicou Szilágyi.

A decisão foi tomada depois que a empresa de auditoria de contratos inteligentes ChainSecurity sinalizou na terça-feira uma vulnerabilidade de segurança em um dos cinco EIPs definidos para inclusão em Constantinopla, relacionada aos custos de armazenamento de dados no blockchain.

Falando comCoinDesk na terça-feira, Matthias Egli – COO da ChainSecurity – destacou que o problema provavelmente não foi detectado pelos CORE desenvolvedores ao executar testes no software, visto que o impacto está enraizado no desenvolvimento de contratos inteligentes, não necessariamente no desenvolvimento do “ CORE [da máquina virtual Ethereum ]”.

Uma decisão rápida para reativar Constantinopla o mais cedo possível foi necessária em parte devido à ativação prolongada da bomba de dificuldade do Ethereum – um pedaço de código incorporado ao blockchain que torna os tempos de bloqueio cada vez mais longos ao longo do tempo.

Pretende-se incentivar a transição para um novo algoritmo de consenso conhecido comoprova de participação (PoS), um atraso da bomba foi sugerido no EIP 1234 devido à pesquisa insuficiente no momento para uma transição para PoS.

Uma vez ativado na rede principal, Constantinople incluirá o EIP 1234 e atrasará a bomba de dificuldade por um período de 12 meses.

Nota do editor: O artigo foi atualizado com informações adicionais.

Código binárioimagemvia Shutterstock