Variações na composição de pares EL em uma linha de base de software fixa: comparação de duas semanas em uma frota de 36 nós – Rede

DR

Em uma análise recente da frota (docs.stereumlabs.com/blog/ec-p2p-peering-behavior-análise) observamos que a composição de pares DevP2P em um nó Besu era de aproximadamente 75% de Reth, apesar da participação de rede agregada de aproximadamente 12% de Reth. Executar novamente a mesma medição duas semanas depois, em versões EC e CC idênticas no mesmo hardware, fornece concentração de Reth de aproximadamente 96% nas mesmas instâncias Besu. A contagem de pares conectados de Reth em nossa frota caiu de ~123 para ~69, e sua tabela de pares rastreados de ~7.400 para ~2.506, no mesmo Reth v2.1.0. Não temos uma explicação clara. O desvio é importante para qualquer análise em cascata construída em um instantâneo de gráfico de pares estático.

O que permaneceu o mesmo

Cinco das seis contagens de pares da CE são estáveis. A tendência está concentrada em Reth e na composição dos pares.

O que mudou

A pegada de pares de Reth diminuiu.

Mesma versão Reth (v2.1.0). A mesma configuração do processo Reth do nosso lado. A redução da tabela de pares de Reth em dois terços e a contagem de conexões reduzida quase pela metade sugerem que algo mudou nos padrões de conexão da rede mais ampla em direção a Reth, e não na configuração do lado de Reth.

A concentração Reth de Besu se intensificou.

besu_peers_peer_count_by_clientmédia móvel de 7 dias, em todas as seis instâncias Besu emparelhadas com CC na mesma frota:

Com 25 pares configurados, Besu agora vê cerca de 24 pares Reth e aproximadamente um de todo o resto combinado. O fator de amplificação versus a participação agregada de Reth é agora de aproximadamente 8x, acima dos ~6x.

As duas mudanças não são consistentes em direção. A presença absoluta de Reth na rede caiu (menos pares Reth conectados, menor tabela de descoberta). A concentração relativa de Besu em Reth aumentou. O que quer que restem dos pares de Reth é uma fração ainda maior da visão de Besu do que antes.

Descoberta lateral: o emparelhamento CC perturba a composição

Mesma versão do EC, mesmo hardware, mesmo datacenter, diferenciado apenas por qual CC o EC foi inicializado ao lado:

Besu Reth compartilha por CC emparelhado (12 de maio, 7d em média):

Uma variação de 10 pontos percentuais na concentração de peers de cliente único em software EC idêntico. A pilha DevP2P não interage com o CC, portanto, o mecanismo deve ser indireto: tempo de inicialização diferente, padrões de chamada da API do mecanismo e pressão de CPU/memória do host compartilhado durante a janela de descoberta inicial, onde a tabela de roteamento de descoberta está sendo propagada. Depois que as entradas da tabela de roteamento se estabilizam, elas criam uma dependência de caminho na qual novos pares são descobertos.

Duas operadoras executando versões EC idênticas em hardware idêntico podem acabar com composições de peers materialmente diferentes simplesmente por causa da escolha do CC. Não há nenhum sinal óbvio das métricas do lado da CE para detectar que isto aconteceu.

Implicações para modelagem em cascata

O enquadramento padrão da diversidade de clientes EL trata a parcela de falhas de cada cliente como contida proporcionalmente. Se Reth falhar, a rede perde 12%. Em um nó Besu com 96% de pares Reth e 25 slots de pares configurados, uma falha de Reth reduz a contagem de pares locais para ~1, bem abaixo de qualquer limite razoável para propagação confiável de fofocas.

Uma probabilidade em cascata calculada em relação ao instantâneo de abril (concentração de 75%, teto de 25 pares) prevê que o nó Besu retém aproximadamente 6 pares após uma interrupção do Reth. Recalculada em relação ao instantâneo de maio, a contagem pós-interrupção prevista é de aproximadamente 1. O mesmo software, a mesma frota, com duas semanas de intervalo. A modelagem de tolerância em cascata que usa uma medição de ponto único no tempo não é robusta à deriva natural no gráfico de pares em linhas de base de software estáveis.

Qual é a agregação temporal correta para dados de composição de pares usados ​​na análise de segurança de rede? Uma média mensal suaviza a tendência, mas mascara a concentração estrutural em qualquer ponto. Um instantâneo captura a estrutura, mas prevê erroneamente os resultados da cascata semanas depois.

O que queremos saber

Três coisas ajudariam a confirmar ou descartar que este seja um artefato específico da frota:

1. Outras frotas. Alguém com frotas multirregionais ou não bare metal observou uma queda semelhante na contagem de pares de Reth e um aumento de concentração paralelo em Besu-Reth ou pares análogos (por exemplo, Ethrex-Geth, que em nossa frota mostra concentração de ~69% de Geth)?

2. Mecanismo. O desvio é impulsionado pelo comportamento de descoberta do lado Reth (agitando ENRs obsoletos mais rápido do que os novos são vinculados) ou pela rotatividade de pares em toda a rede que afeta desproporcionalmente os nós Reth (por exemplo, degradação da acessibilidade da porta de entrada em implantações Reth hospedadas na nuvem)? A perspectiva da equipe cliente Reth é particularmente bem-vinda.

3. Variância de emparelhamento CC. A oscilação da participação Reth de 10pp nos pares CC de Besu é reproduzível em outro lugar ou está dentro da variação natural de frota para frota que uma medição de DC único não consegue separar?

Proposta paralela

Independentemente de como a deriva é explicada: a medição acima só é possível atualmente em dois dos seis principais CE. besu_peers_peer_count_by_client e ethrex_p2p_peer_clients expor nativamente o detalhamento por ponto-cliente. Geth, Reth, Erigon e Nethermind não. Nethermind registra o detalhamento no stdout a cada cinco minutos; os outros três não expõem nada.

Obrigando um _peer_count_by_client A métrica do Prometheus em todos os principais ECs é uma mudança de baixo custo do lado do cliente que desbloquearia significativamente a medição externa das propriedades do gráfico de pares. Atualmente, qualquer análise em cascata da rede EL é cega à composição dos pares em aproximadamente 88% da rede agregada (ações Geth + Reth + Erigon + Nethermind combinadas).

Nota metodológica

36 nós bare-metal em Viena, Áustria, cobrindo todas as combinações {EC × CC} de: Besu 26.4.0, Erigon v3.3.10, Ethrex 10.0.0, Geth v1.17.2, Nethermind 1.36.2, Reth v2.1.0 × Grandine 2.0.4, Lighthouse v8.1.3, Lodestar v1.42.0, Nimbus multiarch-v26.3.1, Prysm v7.1.3, Teku 26.4.0.

Todas as métricas são médias contínuas de 7 dias via avg_over_time(metric(7d:1h)) consultas instantâneas. O instantâneo 1 termina em 29 de abril de 2026; O Snapshot 2 termina em 12 de maio de 2026. As versões EC e CC permaneceram constantes em ambas as janelas. Nomes de métricas de pares por EC: ethereum_peer_count (Besu, Nethermind), p2p_peers (Geth, Erigon), reth_network_connected_peers (Reth), ethrex_p2p_peer_count (Etrex).

Inventário de frota (versões EC e CC por VM, hardware, localização) em docs.stereumlabs.com/docs/scope/list-of-vms. Raw Prometheus em grafana.stereumlabs.com (fonte de dados prometheus-cold) para verificação.