Ontem, as pessoas não se focaram apenas na descida de preço da Ether, mas também na Beacon Chain. Decorreu uma designada “reorganização de blocos” de nada mais, nada menos, do que sete blocos profundos. Essas reorganizações ocorrem ocasionalmente nas cadeiras prova de trabalho, mas a esperança era que seriam uma coisa do passada na cadeira prova de participação da Ethereum. Devemos preocupar-nos?

A Beacon Chain da Ethereum é uma cadeira paralela na qual a Prova de Participação está a ser minuciosamente testada. Após a fusão (esperançosamente) na segunda metade de 2022, a Ethereum será então realmente executada naquela que é atualmente uma rede de teste de prova de participação. Assim sendo, ainda há tempo para detectar vulnerabilidades. A reorganização de blocos foi um desses momentos, em que os programadores trocaram mensagens uns com os outros: o que é que se passa aqui? Será que isto pode ser prejudicial? Parece que não.

As reorganizações não são anormais

Quando se concatena blocos de transação, é normal ocorrer um fork durante um curto período de tempo. Como é que isto acontece? Nas cadeias prova de trabalho como a Bitcoin, isto deve-se ao facto de dois mineiros terem concluído o seu “quebra-cabeças” praticamente ao mesmo tempo e de terem recebido permissão para minarem um bloco. Eles enviam este bloco para os nós. Se isto acontecer praticamente simultaneamente, alguns nós são mais prováveis de aprovar um bloco e outros nós outro. Um fork (divisão) irá, de seguida, ocorrer. Isto é habitualmente resolvido com o próximo bloco, após o qual a cadeia vencedora é a única restante. A probabilidade de que a criação praticamente simultânea do bloco aconteça novamente é muito pequena - quanto mais acontecer três ou quatro vezes seguidas. (Esta possibilidade de forking é o motivo pelo qual muitas bolsas e carteiras de criptomoedas aguardam por um determinado número de confirmações/blocos. Apenas quando uma transação é arrumada com quatro, cinco ou seis blocos sobre esta é que há probabilidade praticamente zero de que esta possa ser revertida).

Diferentes versões do software em circulação

Como é que poderia a Beacon Chain da Ethereum ter tido este conflito em até sete blocos (curiosamente, o tempo de bloco da Ethereum é, sensivelmente, de apenas 12 segundos)? Está tudo relacionado com os diferentes clientes Ethereum (versões do software Ethereum) que estavam em circulação. Alguns nós estavam a executar clientes nos quais já tinha sido realizada uma alteração do protocolo - outros ainda não tinham feito essa atualização.

A atualização do protocolo em questão teve a ver com a designada função boost. Esta assegura que os blocos rapidamente criados são distribuídos de forma extremamente rápida - precisamente para prevenir a circulação de versões em conflito da cadeia. Dado que nem todos os clientes tinham implementado este recurso boost, diferentes nós chegaram a diferentes conclusões quanto ao que era o bloco correto para servir de base ao restado da cadeia.

Ao que tudo indica foi isto que aconteceu. O post-mortem exato sem dúvida que se seguirá mais tarde. Conforme mencionámos, a ocorrência de forks temporários, e subsequentes reorganizações, não são por si só um problema. E não há qualquer dúvida de que todos os clientes começarão a implementar este recurso boost, sendo que após isso este tipo de reorganização do bloco deixará de ocorrer.

Conclusão: a transição da Ethereum para a prova de participação acarreta riscos

A reorganização do bloco não teve nada a ver com um ataque ao sistema, tentativa de gasto duplo - nem sequer um erro, realmente. Por conseguinte, não se passou nada de demasiado sério. No entanto, o facto de que este tipo de evento não foi antecipado pelos programadores da Ethereum diz algo sobre a complexidade da transição para a prova de participação. É um sistema de validação da transação que é muito, mas muito mais complexo do que a prova de trabalho. Os próximos meses, e anos - mesmo após a fusão - devem revelar as surpresas que ainda nos aguardam.