Ethereum mesclar testnet Kintsugi dividido por bug, eis o porquê

O evento de fusão na rede Ethereum é a transição para o modelo de consenso Proof-of-Stake do modelo Proof-of-Work atualmente empregado. Essa fusão significa que o atual sistema de rede principal Ethereum e a nova cadeia Beacon, muitas vezes chamada de Ethereum 2.0, se fundirão em um blockchain.

Para testar a mesclagem, o testnet Kintsugi foi implantado em dezembro. O objetivo do testnet é executar diferentes casos de borda e observar como o sistema se comporta. Um dos desenvolvedores envolvidos na execução de testes no Kintsugi é Marius van der Wijden, desenvolvedor principal do Ethereum trabalhando com a equipe do cliente Geth (Go-Ethereum).

“O testnet funcionou perfeitamente por algumas semanas. Na semana passada eu criei um fuzzer que enviaria blocos inválidos. Um bloco contém muitas informações, como as transações, o hash do bloco anterior, o limite de gás, etc”, diz Marius van der Wijden.

Algumas implementações não executaram e verificaram o bloco

Um fuzzer é um tipo comum de ferramenta de teste usada entre desenvolvedores para gerar entradas aleatórias para funções ou outros pedaços de código e tentar fazê-los quebrar de uma forma ou de outra. Trata-se de gerar entradas malformadas e inesperadas e observar o que acontece com o sistema.

O fuzzer criado por van der Wijden produz um bloco válido e altera um elemento dele para torná-lo inválido. Uma técnica que ele usa é mudar um elemento para outro. Nesse caso, o fuzzer alterou o blockhash para o hash pai.

“Os nós devem rejeitar esse bloco alterado. No entanto, como o hash pai apontou para um bloco válido, algumas implementações não executaram e verificaram o bloco, mas o procuraram em um cache. Como o bloco anterior era válido e estava no cache, eles assumiram que o novo bloco também era válido”, explica van der Wijden.

Rede dividida duas vezes

O resultado foi que metade da rede, os clientes Geth, rejeitou o bloco, enquanto a outra metade, os clientes Nethermind- e Besu, o aceitaram, fazendo com que a cadeia se dividisse, pois agora tínhamos duas visões diferentes do estado correto. Para piorar as coisas, havia outro problema no topo.

De acordo com van der Wijden, os nós da cadeia Geth, por sua vez, que consiste em Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth e Teku-Geth, também se dividem entre eles.

“Essa divisão ainda está sendo investigada, mas parece que o Teku também pode ter algum mecanismo de cache que falhou”, diz van der Wijden.

Como existem vários forks diferentes da rede de teste Kintsugi no momento da escrita, e todos os nós pensam que estão em um fork correto, a rede não está mais finalizando.

“Vamos descobrir algo para reunir a rede novamente. Já atualizamos o cliente Nethermind e esses nós estão na cadeia correta agora. Ainda precisamos da correção para o Teku, já que mais de 33% dos nós são Teku, caso contrário a cadeia não será finalizada”, diz van der Wijden.

Incidente traz algo bom

De acordo com van der Wijden, este incidente não proíbe ou atrasa mais testes da fusão Ethereum, nem atrasa a própria fusão. Na verdade, van der Wijden diz que o incidente realmente ajuda a testar casos de ponta que seriam difíceis de testar se a rede estivesse funcionando corretamente.

“Longos períodos de não finalização são desafiadores para os nós e é muito importante para nós ver como eles se comportam agora. Achamos que a testnet acabará por se reunir novamente, mas não acho que tentaremos corrigi-la manualmente, pois nos dá a oportunidade de testar casos de borda interessantes.”

“Não acho que isso atrase a fusão, já que a fusão ainda não está agendada. Mas mostra o quão importante é o teste. Eu acho que a fusão está progredindo muito bem. Precisamos de mais algumas semanas para deixar o software em um estado aceitável e, em seguida, precisamos de alguns meses para testá-lo”, diz van der Wijden.

E se isso acontecer na rede principal?

Uma questão interessante é o que teria acontecido se um bug como esse tivesse ocorrido na cadeia principal.

“Começamos a testar bem cedo, então esperávamos alguns bugs como esse. Esse bug na rede principal seria muito desagradável, já que precisaríamos encontrar e corrigir o bug, no qual somos muito bons, liberar o código e informar a todos os interessados ​​que devem atualizar seus nós. A última parte é a parte mais difícil na minha opinião, já que alguns usuários não estão acompanhando o desenvolvimento muito de perto”, diz van der Wijden.

Para mais detalhes, o leitor interessado é encorajado a ler o livro de Marius van der Wijden os tweets sobre o incidente.