---
title: "Rede peer-to-peer"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Rede peer-to-peer
> 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
- [Nó completo](/pt-br/crypto/full-node/)
- [Mempool](/pt-br/crypto/mempool/)
- [Resistência à censura](/pt-br/crypto/censorship-resistance/)
## Fontes
- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (acessado em 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (acessado em 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (acessado em 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (acessado em 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (acessado em 2026-08-13)
- [gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) - libp2p (acessado em 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (acessado em 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (acessado em 2026-08-13)
Source: https://wiki.fcontext.com/pt-br/crypto/peer-to-peer-network/index.mdx