Novas medições mostram que a Robinhood Chain não parou de gerar blocos durante falha de setembro

Longe de ter parado, a Robinhood Chain continuou produzindo blocos durante toda a instabilidade registrada em 4 de setembro, segundo novas medições que cobrem o dia inteiro. O episódio, que afetou aplicativos construídos sobre essa rede de segunda camada do Ethereum, durou cerca de 40 minutos de tráfego bastante reduzido, mas não teve a interrupção na geração de blocos relatada inicialmente.

O próprio CryptoSlate publicou, em 5 de setembro, que a produção de blocos havia sido interrompida por pelo menos 14 minutos. A informação estava errada. O que houve, conforme a correção, foram duas pausas distintas no envio dos dados de transações da Robinhood Chain para o Ethereum: a primeira das 12h29min47s às 12h38min23s em UTC, por 8 minutos e 36 segundos, e a segunda das 12h42min47s às 12h48min11s, por 5 minutos e 24 segundos. Somadas, elas chegam aos 14 minutos citados.

A revisão se apoia numa análise da Glass Hull, divulgada em 29 de setembro. A empresa contou 854.255 blocos ao longo de todos os 1.440 minutos de 4 de setembro, em horário UTC. O maior intervalo entre os carimbos de tempo de dois blocos consecutivos foi de dois segundos. No minuto iniciado às 12h57 UTC, quando a interrupção supostamente ocorria, a rede produziu 592 blocos.

O problema que os usuários sentiram foi outro. Um estudo da Walnut, publicado em 23 de setembro, mostrou que o tráfego bem-sucedido dos aplicativos despencou entre aproximadamente 12h37 e 13h20 UTC. Durante a queda, o aplicativo mediano entre os mais movimentados concluiu cerca de um quinto das transações bem-sucedidas que costuma registrar. A Walnut levantou a hipótese de que tentativas de envio se perderam antes de chegar aos blocos e citou como possível causa uma taxa baixa oferecida pelo responsável por publicar os lotes, superada por outras ofertas durante um pico de tarifas no Ethereum.

A QuickNode, provedora de infraestrutura, começou a investigar um aumento de latência às 13h10 UTC e, mais tarde, às 16h20 UTC, alertou para desempenho degradado e transações que não chegavam a ser incluídas, atribuídos a problemas de conexão com o fluxo do sequenciador. Os registros da empresa tratam apenas do impacto sobre o próprio serviço.

O L2BEAT, que monitora redes de segunda camada, mostrou em seu histórico de funcionamento lacunas comparáveis no envio de dados ao Ethereum, em linha com o que a Glass Hull identificou. Já a Arbitrum, em comunicado no próprio dia 4, afirmou que a rede não teve tempo fora do ar e que transações enviadas diretamente pelos usuários não sofreram atrasos, embora tenha reconhecido um breve impacto de desempenho para alguns provedores que dependem do fluxo de dados da rede.

Algumas perguntas continuam sem resposta. Ainda não se sabe com precisão em que ponto fora da blockchain ocorreu a falha, se numa fila do sequenciador ou numa camada de RPC, nem qual a relação exata entre esse problema e os atrasos no envio de dados ao Ethereum.