Ir para o conteúdo
Financial Context Wiki

Rede peer-to-peer

Uma rede peer-to-peer oferece a cada nó um conjunto limitado e variável de pares diretos para descoberta, gossip e troca de solicitação-resposta; ela não cria uma visão global nem transforma aceitação de mensagens em consenso.

Atualizado

Apenas para fins educacionais; não constitui aconselhamento nem recomendação de investimento. Investimentos podem resultar em perdas.

Resposta direta

Uma rede peer-to-peer permite que cada nó descubra e mantenha um conjunto limitado de pares diretos, troque mensagens autenticadas do protocolo e construa sua visão local sem encaminhar tudo por um servidor central. Ela não é um grafo completo, um mempool global nem uma fonte de verdade por si só. Um par receber, validar ou retransmitir um objeto não prova que todos os nós o viram, que um bloco o incluiu ou que o consenso o finalizou.

Após The Merge, o Ethereum usa duas redes P2P distintas. Clientes de execução usam descoberta, RLPx e a capacidade versionada eth para sincronização e troca de transações. Clientes de consenso usam discv5 para descoberta e gossip libp2p mais protocolos de solicitação-resposta para blocos beacon, attestations e outros objetos de consenso. Os clientes se coordenam localmente pela Engine API autenticada; uma wallet geralmente envia por JSON-RPC e nem por isso se torna nó de gossip.

Como funciona

  1. Fixe cadeia, rede, gênese e configuração de forks, versões dos clientes de execução e consenso, identidades dos nós e horário da observação. Represente separadamente cliente de execução, cliente de consenso, validator opcional, Engine API local e RPC voltado ao usuário.
  2. Verifique cada caminho de descoberta: bootnodes embutidos, listas DNS, pares estáticos ou confiáveis, identidade ENR ou enode, endpoint e sequência anunciados, compatibilidade de rede, NAT e acessibilidade de entrada. Um ENR assinado vincula o registro a uma chave; não prova honestidade, sincronização nem acessibilidade atual.
  3. Registre conexão e negociação de protocolo separadamente. Pares de execução estabelecem sessões RLPx e negociam capacidades como eth; pares de consenso negociam transportes libp2p, segurança e IDs de protocolo após descoberta discv5. Encontrar um endpoint não implica compatibilidade da aplicação.
  4. Acompanhe cada objeto por seu caminho real. Uma transação pode ir do envio RPC à validação local e ao mempool de execução, e depois a anúncios e solicitações eth. Objetos de consenso usam validação gossip específica do tópico; blocos ausentes podem ser obtidos por solicitação-resposta.
  5. Aplique decodificação limitada, deduplicação, limites de taxa e verificações de assinatura, sintaxe e estado antes da admissão ou retransmissão local. Registre resultados inválidos, ignorados, indisponíveis e limitados por recursos; pontuação e desconexão de pares são decisões locais da implementação, não reputação de consenso.
  6. Mantenha recepção, validação, retransmissão, inclusão da transação, resultado da execução, fork choice, justificação e finalidade como estados e relógios separados. Compare vários pares ou nós quando pool, head ou histórico local estiver incompleto, conflitante ou desatualizado.
  7. Monitore diversidade de pares de entrada e saída, operador, concentração por prefixo IP e ASN, rotatividade, latência, perda, largura de banda, filas, tráfego inválido, relógio e dependências RPC. Ensaie perda de bootnodes, falha de NAT, partição, eclipse, sobrecarga e recuperação sem alegar resistência absoluta.

Descoberta de pares, segurança de transporte e validade da aplicação resolvem problemas diferentes. Bootnodes apresentam candidatos, mas não retransmitem tráfego comum nem escolhem a cadeia canônica. A criptografia protege conteúdo e autenticação da sessão, mas os pares ainda conhecem endpoints e horários; um provedor RPC remoto também pode observar consultas, endereços e transações enviadas.

A propagação é concorrente e depende da topologia. Fanout, caminhos duplicados, serialização por largura de banda, CPU de validação, filas, perda, retransmissão, pontuação e regras do objeto determinam a distribuição e a cauda dos tempos de chegada. Uma fórmula como delay = hops * perHopTime é apenas um modelo didático serial declarado, não uma garantia da rede.

Exemplos

  • Caminho serial versus pipeline. Em um caminho didático de 4 hops, cada salto tem 80 ms de rede e 20 ms de validação. O processamento totalmente serial resulta em 4 * (80 + 20) = 400 ms. Se a validação se sobrepuser à próxima transmissão, um limite inferior simplificado é 4 * 80 + 20 = 340 ms. Nenhum valor é o tempo de propagação da rede inteira.
  • Anúncio e obtenção de transações. Um nó recebe 20 hashes e já tem 6, então faltam 20 - 6 = 14 corpos. Se uma solicitação didática comporta no máximo 8, são necessários ceil(14 / 8) = 2 batches. Com 120 ms de ida e volta e 30 ms de validação por lote, a conclusão serial é 2 * (120 + 30) = 300 ms; a paralela ideal, 150 ms. Limites reais dependem da versão eth negociada e do cliente.
  • Probabilidade simplificada de eclipse. Se cada um dos 8 pares de saída fosse amostrado de forma independente e candidatos maliciosos fossem 25%, a probabilidade de todos serem maliciosos seria 0.25^8 = 0.0000152587890625 = 0.00152587890625%. Viés de descoberta, identidades Sybil, correlação IP/ASN e retenção violam a independência; não é garantia de segurança.
  • Sobrecarga de validação. O gossip de entrada é 900 messages/s; 4 workers validam 250 messages/s cada, dando capacidade de 1,000 messages/s, sobra de 100 messages/s e utilização de 90%. Um ataque de 1,400 messages/s acumula 400 messages/s e 6,000 messages em 15 seconds. Uma fila de 5,000-message enche em 5,000 / 400 = 12.5 seconds antes de descartes ou limitação, ignorando variação do serviço.

Riscos

  • Cadeia, gênese ou configuração de fork incorretas.
  • Incompatibilidade de cliente de execução, consenso ou Engine API.
  • Descoberta por bootnode ou DNS concentrada ou sequestrada.
  • Metadados de endpoint obsoletos, falsos ou inacessíveis.
  • NAT, firewall ou portas bloqueiam a acessibilidade esperada.
  • Ataque de eclipse filtra a visão local do nó.
  • Identidades Sybil e concentração de IP, ASN, operador ou nuvem.
  • Dependência excessiva de pares estáticos ou confiáveis.
  • Censura de transações ou retransmissão seletiva.
  • Divergência entre fluxo de ordens público e privado.
  • Divergência local de admissão, substituição e expulsão do mempool.
  • Gossip inválido esgota CPU de validação.
  • Solicitações excessivas, descompressão ou esgotamento de banda, memória ou disco.
  • Manipulação da pontuação ou penalidades falsas.
  • Contrapressão das filas descarta mensagens sensíveis ao tempo.
  • Latência, perda ou desvio de relógio causam divergência temporária do head.
  • Incompatibilidade de versão de protocolo ou fork digest.
  • Histórico podado ou resposta sem recursos é interpretado como inexistência.
  • Vazamento de IP, horário, consultas e origem de transações.
  • RPC centralizado ou exposto permite rastreamento, visão desatualizada, censura ou comprometimento.

Equívocos comuns

  • Todo nó se conecta diretamente a todos os demais. Cada nó tem um conjunto local finito e variável; nós distintos podem ver mensagens e heads diferentes temporariamente.
  • Um bootnode é fonte confiável de blocos ou participante do consenso. Sua função normal é apresentar pares; validade e fork choice são verificados em outro lugar.
  • Uma transação aceita por um par é transmitida globalmente e tem inclusão garantida. Admissão e retransmissão são locais, e builders ou proposers podem omiti-la.
  • Validação gossip significa consenso e finalidade. É uma barreira local inicial; fork choice, justificação e finalidade são máquinas de estado separadas.
  • Mais pares ou transporte criptografado dão anonimato e resistência a eclipse automaticamente. Diversidade e seleção importam; pares e RPCs ainda podem correlacionar endpoints, horários e atividade.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...