Skip to content
Financial Context Wiki

Peer-to-peer network

A peer-to-peer network gives each node a limited, changing set of direct peers for discovery, gossip and request-response exchange; it does not create one global view or turn message acceptance into consensus.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A peer-to-peer network lets each node discover and maintain a limited set of direct peers, exchange authenticated protocol messages and build its own local view without routing everything through one central server. It is not a complete graph, a global mempool or a source of truth by itself. A peer receiving, validating or forwarding an object does not prove that every node saw it, that a block included it or that consensus finalized it.

Post-Merge Ethereum uses two distinct P2P networks. Execution clients use discovery plus RLPx and the versioned eth capability for synchronization and transaction exchange. Consensus clients use discv5 for discovery and libp2p gossip plus request-response protocols for beacon blocks, attestations and other consensus objects. The two clients coordinate locally through the authenticated Engine API; a wallet commonly submits through JSON-RPC and is not thereby a gossiping node.

How it works

  1. Pin the chain, network, genesis and fork configuration, execution and consensus client versions, node identities and observation time. Draw the execution client, consensus client, optional validator, local Engine API and user-facing RPC as separate components.
  2. Check each discovery path: built-in bootnodes, DNS lists, static or trusted peers, ENR or enode identity, advertised endpoint and sequence, network compatibility, NAT and inbound reachability. A signed ENR binds a record to a key; it does not prove honesty, synchronization or current reachability.
  3. Record connection and protocol negotiation separately. Execution peers establish RLPx sessions and negotiate capabilities such as eth; consensus peers negotiate libp2p transports, security and protocol IDs after discv5 discovery. Finding an endpoint is not application compatibility.
  4. Trace each object through its actual path. A transaction may go from RPC submission to local validation and the execution mempool, then through eth announcements and requests. Consensus objects use topic-specific gossip validation, while missing blocks can be fetched through request-response.
  5. Apply bounded decoding, deduplication, rate limits, signature, syntax and state checks before local admission or forwarding. Record invalid, ignored, unavailable and resource-limited outcomes; peer score and disconnect policy are local implementation decisions, not consensus reputation.
  6. Keep receipt, validation, forwarding, transaction inclusion, execution result, fork choice, justification and finality as separate states and clocks. Compare several peers or nodes when a local pool, head or history response is incomplete, conflicting or stale.
  7. Monitor inbound and outbound peer diversity, operator, IP prefix and ASN concentration, churn, latency, packet loss, bandwidth, queues, invalid traffic, clock health and RPC dependencies. Rehearse bootnode loss, NAT failure, partition, eclipse, overload and recovery without claiming absolute resistance.

Peer discovery, transport security and application validity solve different problems. Bootnodes introduce candidates but do not relay ordinary traffic or choose the canonical chain. Encryption protects session contents and authentication, but peers still learn network endpoints and timing; a remote RPC provider can additionally observe queries, addresses and submitted transactions.

Propagation is concurrent and topology-dependent. Fanout, duplicate paths, bandwidth serialization, validation CPU, queueing, packet loss, retransmission, peer scoring and object-specific rules determine the distribution and tail of arrival times. A formula such as delay = hops * perHopTime is only a stated serial teaching model, not a network guarantee.

Example

  • Serial path versus pipeline. On one teaching path of 4 hops, each hop has 80 ms network time and 20 ms validation time. Fully serial processing gives 4 * (80 + 20) = 400 ms. If validation overlaps the next transmission, a simplified lower bound is 4 * 80 + 20 = 340 ms. Neither value is whole-network propagation time.
  • Transaction announcement and retrieval. A node receives 20 transaction hashes and already has 6, so 20 - 6 = 14 bodies are missing. If a teaching request carries at most 8, it needs ceil(14 / 8) = 2 batches. At 120 ms round-trip plus 30 ms validation per batch, serial completion is 2 * (120 + 30) = 300 ms; ideal parallel completion is 150 ms. Actual limits depend on the negotiated eth version and client.
  • Simplified eclipse probability. If each of 8 outbound peers were independently sampled and malicious candidates were 25%, the probability that all were malicious would be 0.25^8 = 0.0000152587890625 = 0.00152587890625%. Discovery bias, Sybil identities, IP and ASN correlation and peer retention violate the independence assumption, so this is not a security guarantee.
  • Validation overload. Inbound gossip is 900 messages/s; 4 workers each validate 250 messages/s, giving capacity 1,000 messages/s, spare capacity 100 messages/s and utilization 90%. An attack at 1,400 messages/s creates 400 messages/s of backlog and 6,000 messages in 15 seconds. A 5,000-message queue fills in 5,000 / 400 = 12.5 seconds before drops or rate limiting, ignoring service-time variance.

Risks

  • Wrong chain, genesis or fork configuration
  • Execution client, consensus client or Engine API mismatch
  • Concentrated or hijacked bootnode and DNS discovery
  • Stale, forged or unreachable endpoint metadata
  • NAT, firewall or port configuration blocking expected reachability
  • Eclipse attack that filters a node’s local view
  • Sybil identities and IP, ASN, operator or cloud concentration
  • Excessive reliance on static or trusted peers
  • Transaction censorship or selective relay
  • Public and private order-flow divergence
  • Local mempool admission, replacement and eviction divergence
  • Invalid gossip exhausting validation CPU
  • Oversized requests, decompression, bandwidth, memory or disk exhaustion
  • Peer-scoring manipulation or false penalties
  • Queue backpressure dropping time-sensitive messages
  • Latency, loss or clock skew causing temporary head divergence
  • Protocol version or fork-digest incompatibility
  • Pruned history or resource-unavailable responses misread as nonexistence
  • IP, timing, query and transaction-origin privacy leakage
  • Centralized or exposed RPC causing tracking, stale views, censorship or compromise

Common misconceptions

  • Every node connects directly to every other node. Each node has a finite, changing local peer set, and different nodes can see different messages and heads temporarily.
  • A bootnode is a trusted block source or consensus participant. Its normal role is initial peer introduction; chain validity and fork choice are verified elsewhere.
  • A transaction accepted by one peer is globally broadcast and guaranteed inclusion. Admission and relay are local, and builders or proposers can omit it.
  • Gossip validation means consensus and finality. It is an early local networking gate; fork choice, justification and finality are separate state machines.
  • More peers or encrypted transport automatically provide anonymity and eclipse resistance. Diversity and selection matter, while peers and RPC providers can still correlate endpoints, timing and activity.

Sources

Navigation

Search the wiki...