Na semana passada, especificamente nos dias 11 e 12, a Ethereum começou a enfrentar um problema técnico na camada de consenso que, por um período temporário, resultou na ausência de finalização dos blocos de transações, preocupando a comunidade. Antes de prosseguir, vale destrincharmos alguns conceitos.
Quando dizemos que a “finalização” (“finality”) é alcançada, isso significa que as transações são consideradas permanentes e imutáveis, não podendo ser revertidas ou alteradas. Esse processo é crucial para que haja garantia de segurança e confiabilidade, uma vez que impede a possibilidade de manipulação ou fraude após a conclusão.
Dito de outra forma, quando essa finalização das transações não ocorre, há um nítido problema à vista que pode afetar a integridade e a funcionalidade da rede. Ou seja, a finalidade é a garantia de que alguém não possa modificar um bloco ou removê-lo da cadeia sem gastar pelo menos 33% do ETH total em stake.
Quando olhamos para o que aconteceu na Ethereum de forma mais técnica, os dados iniciais da quinta-feira (11), por meio da “Beaconcha.in”, indicavam que as “epochs” 200.552, 200.553 e 200.554 haviam tido uma queda acentuada no número de atestações recebidas dos validadores. Outro provedor de dados, a EthereumPools.info chegou a tuitar afirmando que por algumas epochs, quase todos os pools/operadores que eles monitoram, ficaram offline.
O problema voltou a se repetir no dia 12, e as “epochs” 200.750 a 200.758 também viram uma redução significativa nas atestações recebidas. A “paralisação” durou cerca de 1 hora e o motivo seguia nebuloso, com usuários debatendo sobre a possibilidade de haver algum bug nos clients ou em infraestruturas de MEV.
Na verdade, “paralisação” não é de fato o termo apropriado, uma vez que as transações seguiram acontecendo e “apenas” não foram finalizadas. No entanto, a exemplo de outros projetos, a plataforma de derivativos dYdX precisou pausar os depósitos enquanto aguardava a retomada dessa finalização.
Este foi o primeiro grande incidente enfrentado pela Beacon Chain, a camada de consenso Proof-of-Stake da Ethereum, que se fundiu com a camada de execução da mainnet em setembro do ano passado. Apesar de os motivos ainda não estarem totalmente claros e ninguém entender integralmente as origens do problema, há uma linha argumentativa interessante defendida pela Ethereum Foundation, que alega, em termos simples, que um “evento excepcional” teria causado uma sobrecarga para os clients de consenso Prysm e Teku.
Para quem não está familiarizado com o termo, um “client de consenso” é um software que implementa o protocolo de consenso de uma blockchain, sendo responsável por validar transações, processar blocos e, pasmem: atingir o consenso. É por meio deles que os validadores interagem com e participam da blockchain. E é exatamente por isso que é tão importante haver uma distribuição ampla entre diferentes clients.
De forma mais técnica, o que parece ter acontecido é que vimos atestações válidas, mas intempestivas, sendo transmitidas na rede, o que normalmente acontece quando um node está com dificuldades para sincronizar e fazer uma atestação com uma visão antiga da cadeia. Se este for o caso, é possível que, ao receber uma atestação para um “alvo” antigo, a rede tenha sido forçada a regenerar o nó validador para que ele conseguisse validar aquela atestação.
Agora, imagine simultaneamente essas várias regenerações em escala sobrecarregando os CPUs e consumindo muita memória. Isso, por consequência, acaba sobrecarregando os clients. Para termos uma ideia, o cliente Prysm (da Prysmatic Labs, que falamos), um dos vários existentes para a Ethereum, possui um cache somente para armazenar alvos de atestação.
Sendo assim, com o aumento dos validadores e com a grande quantidade de atestações fora de hora, é possível que esse cache tenha ficado cheio, forçando a reprodução repetida do mesmo estado da rede. Dada a situação, a Prysmatic Labs taggeou a versão 4.0.4-rc.0 para o Prysm com o intuito de melhorar o software para otimizar o desempenho em situações como essa. Outro client afetado foi o Teku, também atualizado.
Vale (BVMF:VALE3) lembrarmos que o número de validadores cresceu 2500% desde o lançamento da Beacon Chain em dezembro de 2020. Talvez tenha havido certa negligência na realização de testes de “estresse” em larga escala em testnets ao longo do tempo. Agora, desenvolvedores da Ethereum devem aprender com a experiência e implantar grandes redes de teste privadas com um número de validadores mais realista e melhor “escalonado”.
No domingo, Ben Edgington, da Ethereum Foundation, reforçou em uma live a tese anterior. Como uma finalização só ocorre quando pelo menos 2/3 dos validadores concordam com o estado da Ethereum, e como cerca de 60% dos validadores deixaram de fazer as atestações ao mesmo tempo, essa finalização teria sido impedida. Em outras palavras, é como se esses 60% tivessem ficado offline.
O fato é que, seja essa a causa ou não, com a atualização dos clients, a Ethereum voltou a finalizar suas transações!
Daqui em diante, não é alarmista afirmar que podemos esperar ver a Ethereum passando por problemas parecidos no futuro, o que não necessariamente invalida a tese, mas coloca a rede no centro do debate. Desta vez, o incidente teve um impacto mínimo nos validadores: cerca de quase 500 mil validadores perderam um total de 28 ETH durante o incidente. Aguardemos as cenas dos próximos capítulos.