StereumLabs, em colaboração com MigaLabs liderou o desenvolvimento de um conjunto abrangente de painéis Grafana projetados para monitorar métricas em vários clientes de Consenso e Execução. Mais de 70 combinações de clientes (incluindo supernós) são continuamente operadas e observadas, proporcionando uma visão ampla e representativa do comportamento do cliente em condições de rede ativa.
Compreender o significado e o impacto operacional das métricas do cliente pode muitas vezes ser um desafio, especialmente ao distinguir entre a variação normal e o mau funcionamento real. Neste artigo, examinamos como um bug que afeta o cliente de consenso Nimbus foi identificado de forma clara e rápida por meio desses painéis, ilustrando seu valor prático em cenários de monitoramento do mundo real.
O objetivo desta análise não é destacar um cliente específico, mas demonstrar como ferramentas de observabilidade eficazes tornam o comportamento anormal imediatamente visível. A situação voltou ao normal em poucas horas e o incidente teve impacto geral limitado. Ao mesmo tempo, serve como um lembrete da importância de manter a diversidade de clientes dentro do ecossistema Ethereum.
Uma descoberta secundária — a perda despercebida de suporte métrico em uma versão subsequente do Nimbus — surgiu durante uma reunião de revisão colaborativa com a equipe do Nimbus, destacando ainda mais o valor da observabilidade contínua e da comunicação entre equipes.
Além disso, este documento apresenta uma análise comparativa entre um nó regular Nimbus e um supernó, aproveitando os recursos lado a lado dos painéis para ilustrar as diferenças operacionais introduzidas pela especificação PeerDAS.
Interrupção do cliente do consenso Nimbus – 8 de fevereiro de 2026
Em 8 de fevereiro de 2026, entre 01h00 e 02h00 UTC, o cliente de consenso Nimbus experimentou um bug importante que interrompeu temporariamente sua participação na rede principal Ethereum.
De acordo com a autópsia oficial:
“Os clientes Nimbus rejeitaram falsamente como inválido um bloco da rede principal e foram bifurcados. A corrupção do cache na implementação do hashing da árvore Merkle do Nimbus, causando isso, surgiu de certas alterações de tamanho dos objetos da lista SSZ que apareceram na rede principal que ignoraram a invalidação correta do cache… Como os descendentes do bloco determinado incorretamente como inválido não puderam ser processados sem violar o protocolo, o Nimbus não poderia continuar a seguir a cadeia canônica da rede principal até que o nó fosse reiniciado”
Impacto observável no nível do nó
Embora a participação na rede tenha voltado ao normal algumas horas depois, o impacto operacional foi imediatamente visível nos sistemas de monitoramento que exportam métricas Nimbus. Embora a visualização da métrica por si só não seja suficiente para determinar a causa raiz, ela fornece uma indicação rápida e inequívoca de que está ocorrendo um comportamento anormal, mesmo para operadores sem profundo conhecimento de protocolo.
Um dos indicadores mais proeminentes foi a métrica “Slots Behind”. Aproximadamente às 02:00 UTC, observou-se que o nó afetado neste exemplo (Nimbus/Nethermind) estava atrasado 171 slots em relação ao slot de clock, indicando claramente uma perda de sincronização com a cadeia canônica.
Embora muitos stakers profissionais executem seu próprio conjunto de painéis, eles não conseguem ver o que não conseguem executar. Em outras palavras, eles veem apenas dados sobre os nós que executam, mas não podem compará-los com outros clientes que não estão executando. Este é um principal diferença.
Como o StereumLabs executa um grande número de combinações de nós, é muito fácil verificar rapidamente se outros nós também foram afetados e quais. Na verdade, o painel da tabela de estado de sincronização de visão geral revelou imediatamente um padrão claro: todas as instâncias que executavam o cliente de consenso Nimbus estavam ficando atrasadas, enquanto outras combinações de cliente Consensus-Execution continuavam a operar normalmente. Essa comparação lado a lado tornou a anomalia visível e atribuível à primeira vista, sem exigir inspeção profunda de registros ou correlação manual entre nós.
Esta observação foi ainda corroborada pelos painéis dedicados dos outros clientes de consenso, cuja sincronização, processamento de blocos e métricas de rede permaneceram estáveis durante a mesma janela de tempo.
Simultaneamente, o processamento de blocos foi efetivamente interrompido. A ausência de blocos recém-processados refletiu-se diretamente nas métricas de importação de blocos, tornando o problema inequívoco do ponto de vista operacional.
Degradação da conectividade de rede e peer
A instabilidade também se manifestou na camada de rede. À medida que o cliente divergia da cadeia canônica, ele tentava repetidamente estabelecer conexões produtivas entre pares. Este comportamento foi claramente observável através de:
Pares conectados
Utilização de largura de banda
Métricas libp2p
Tanto o uso da rede no nível do sistema quanto as métricas específicas do protocolo exibiram padrões anormais consistentes com um nó incapaz de validar e propagar blocos canônicos com sucesso.
Estagnação da atividade do banco de dados
As métricas relacionadas ao banco de dados destacaram ainda mais o problema. As operações de gravação e as atualizações de estado caíram significativamente, refletindo o fato de que o cliente não estava mais processando novos dados canônicos com êxito. Isso forneceu uma camada adicional de confirmação de que o nó estava efetivamente paralisado, em vez de simplesmente experimentar latência transitória da rede.
No geral, a interrupção desse bug foi muito limitada e foi resolvida simplesmente reiniciando o nó. A Nimbus continua sendo um dos clientes CL mais robustos do setor, sem nenhum incidente grave desde a gênese da cadeia Beacon. A correção do bug foi lançada poucos dias depois e nenhum problema foi observado desde então.
Perda despercebida de suporte da métrica
A detecção de anomalias é um dos casos de uso importantes para a compilação de painéis, mas não é o único. Durante uma breve troca técnica com a equipe da Nimbus sobre a cobertura do painel e a exposição da métrica, identificamos uma regressão afetando uma métrica específica.
A distribuição de peers conectados por cliente — métrica disponível em versões anteriores — não estava mais sendo exportada adequadamente. Através da comparação de versões e dos dados históricos do painel, esta mudança pode ser correlacionada com uma versão implementada no final de 2025, indicando uma provável regressão acidental introduzida durante esse ciclo de atualização. Embora todos os clientes Ethereum executem uma grande bateria de testes antes de qualquer lançamento, esses testes geralmente cobrem problemas complexos, como consenso, finalidade, validação, desempenho, entre outros, mas nem sempre cobrem métricas, visto que não são críticas para as operações.
Essa descoberta ilustra ainda mais o valor da observabilidade contínua e entre versões: além de detectar incidentes em tempo de execução, painéis abrangentes também ajudam a revelar inconsistências sutis em nível de métrica que, de outra forma, poderiam passar despercebidas.
Comparando um nó regular do Nimbus com um supernó
Os painéis do Stereumlabs fornecem recursos de comparação lado a lado para nós e supernós regulares, permitindo que os operadores observem e quantifiquem as diferenças operacionais entre essas duas configurações
A distinção entre um nó regular e um supernó no Nimbus está enraizada na especificação PeerDAS, introduzida como parte da atualização do Fusaka (EIP-7594). A principal diferença arquitetônica está no número de colunas de dados de blob que cada nó custodia e propaga através da rede peer-to-peer: um nó regular assina um subconjunto atribuído aleatoriamente de 8 sub-redes de colunas, enquanto um supernó assina todas as 128 sub-redes de colunas, custodiando o conjunto de dados completo.
Dado o volume substancialmente maior de dados gerenciados por um supernó, a diferença observável mais pronunciada e imediata se manifesta no consumo geral de largura de banda da rede. Isso é visível nos painéis de E/S de rede de nível superior do painel
e é ainda corroborado pelas métricas de largura de banda libp2p, que refletem a participação do nó na camada de fofoca.
A taxa de transferência de entrada e saída é significativamente elevada em um supernó, com picos ocorrendo em torno dos limites dos slots à medida que os dados da coluna são recebidos e repropagados. Embora se possa esperar intuitivamente que a largura de banda de um supernó seja aproximadamente 16 vezes maior do que a de um nó normal – dada a sua assinatura em todas as 128 sub-redes de colunas versus 8 – o multiplicador observado é consideravelmente menor na prática. Isto se deve ao fato de que uma parcela significativa da largura de banda é consumida pela sobrecarga da rede fixa (gerenciamento de pares, atestados, propagação de blocos) que permanece constante independentemente da contagem de assinaturas da sub-rede, combinada com a topologia de malha GossipSub que limita o número de pares dos quais um nó recebe qualquer coluna. A proporção teórica de ×16 só seria válida se a largura de banda fosse puramente uma função do volume de dados da coluna sem sobrecarga fixa, o que não é o caso em uma rede p2p ativa.
Durante a janela de observação de 7 dias no momento em que este artigo foi escrito, a largura de banda média de entrada e saída mostra uma diferença de aproximadamente 40% entre um supernó e um nó normal.
| MB/s | Mínimo normal | Máximo normal | Média regular | Supernó mínimo | Supernó máximo | Média do supernó | Delta mínimo | Delta Máx. | Média Delta |
|---|---|---|---|---|---|---|---|---|---|
| Recebido | 5.7 | 10.1 | 7,65 | 10.8 | 81,4 | 18,9 | 52,78% | 12,41% | 40,48% |
| Transmitido | 5.52 | 9h33 | 7.21 | 11.1 | 48,2 | 16,7 | 49,73% | 19,36% | 43,17% |
Devido ao maior número de operações de verificação de células KZG e processamento de fofocas realizadas em todas as 128 sub-redes de colunas, espera-se que um supernó exiba uma utilização de CPU maior do que um nó normal. Dito isto, esta métrica por si só não constitui um diferenciador confiável entre as duas configurações.
Regular:
Supernó:
Durante a janela de observação de 7 dias no momento em que este artigo foi escrito, a diferença absoluta na utilização média da CPU entre um supernó e um nó regular é inferior a 1 ponto percentual (1,92% vs. 2,74%) para esta combinação específica de Nimbus/Nethermind. Embora o delta relativo de aproximadamente 70% possa parecer significativo, deve ser interpretado no contexto dos valores absolutos muito baixos envolvidos — um aumento de 1,92% para 2,74% permanece operacionalmente insignificante. A utilização ligeiramente maior da CPU em um supernó é real, mas não deve ser motivo de preocupação na prática.
| Regular | Supernó | Delta | |
|---|---|---|---|
| CPU não ociosa | 1,92% | 2,74% | 70,07% |
O aumento da custódia da coluna se traduz diretamente em maior rendimento de gravação em disco e maior consumo geral de armazenamento na camada de consenso. Um supernó retém dados de todas as colunas durante o período de custódia, enquanto o espaço ocupado no disco de um nó regular é proporcionalmente menor, refletindo a custódia apenas de seu subconjunto atribuído.
A participação mais ampla da sub-rede em um supernó exige o envolvimento com um conjunto maior e mais diversificado de pares, resultando em uma contagem maior de pares conectados em comparação com um nó normal. Durante a janela de observação de 7 dias, a contagem de pares conectados em um nó regular variou de 23 a 90, com média de 35, enquanto o supernó variou de 50 a 161, com média de 112 pares conectados.
Os supernós assinam todas as 128 sub-redes de colunas, resultando em um número significativamente maior de assinaturas ativas de tópicos de fofoca. Nós regulares, participando de apenas 8 sub-redes atribuídas, apresentarão valores substancialmente mais baixos nas métricas de assinatura de fofoca.
Conclusão
Este incidente demonstra o valor operacional da observabilidade abrangente para clientes de consenso. Embora os painéis não substituam a depuração formal ou a análise post-mortem, eles fornecem visibilidade imediata e prática sobre a saúde do cliente e a participação na rede
O incidente apresentado foi claramente detectável por meio de múltiplas dimensões métricas independentes — atraso de sincronização, processamento de blocos, conectividade entre pares, utilização de rede e atividade de banco de dados. Essa visibilidade em várias camadas permite que os operadores identifiquem anomalias rapidamente, avaliem a gravidade e tomem medidas corretivas em minutos, em vez de horas.
Além disso, a identificação de uma métrica de distribuição de pares conectados ausente após um lançamento no final de 2025 ilustra ainda outro benefício importante do rastreamento de métricas de longo prazo. O monitoramento contínuo entre versões não ajuda apenas a detectar falhas de tempo de execução; também expõe regressões, inconsistências métricas e mudanças não intencionais na própria observabilidade. Sem painéis estruturados e comparações históricas, tais questões podem facilmente passar despercebidas.
Resumindo, painéis bem projetados e mantidos de forma consistente não são apenas camadas de visualização. Eles formam uma interface operacional essencial para o ecossistema Ethereum – permitindo que equipes de validação, operadores de infraestrutura e pesquisadores detectem incidentes, validem correções, comparem o comportamento do cliente e melhorem continuamente a confiabilidade.
Fontesethresear
