Peer Eviction

Node software has finite resources like memory, bandwidth, and connection slots. Peer eviction prevents resource exhaustion by removing peers that are:

• Unresponsive or have high latency.
• Non-contributing (e.g., not relaying valid blocks or transactions).
• Consuming disproportionate bandwidth without providing useful data. This ensures stable operation for the remaining, high-quality connections.

Eviction policies defend against Sybil attacks, where an attacker creates many fake node identities. Mechanisms include:

• Behavioral scoring: Penalizing peers for sending invalid data or violating protocol rules.
• Connection age preference: Favoring longer-lived connections over new, potentially malicious ones.
• Diversity rules: Ensuring a mix of peers from different network subnets to prevent isolation attacks.

Eviction algorithms actively shape the P2P graph to improve information propagation. They prioritize peers that:

• Provide fresh, valid blocks and transactions quickly (low propagation delay).
• Offer unique data, reducing redundancy.
• Are geographically or topologically diverse, enhancing the network's resilience and reducing latency for global participants.

Bitcoin Core's eviction logic is a canonical example. It uses a tried/ new table structure and a complex scoring system. Key criteria for eviction include:

• Last successful interaction time.
• Peer's network services (e.g., serving blocks).
• Connection uptime and penalty score. The process is non-deterministic to make attacks harder, but systematically favors valuable, well-behaved peers.

Eviction is triggered by specific conditions, not run continuously. Common triggers include:

• Connection limit reached: A new peer connects, forcing the eviction of an existing one.
• Resource thresholds exceeded (e.g., memory usage). Policies are often tiered, attempting to evict the "worst" peer first based on a composite score of latency, age, and contribution.

Peer eviction works in tandem with peer discovery (finding new peers via DNS seeds, hardcoded addresses, or peer exchange). The cycle is:

1. Discover new peer candidates.
2. Attempt connections and evaluate performance.
3. Use eviction to prune the connection set, maintaining a healthy, rotating pool of peers. This dynamic process is essential for decentralization and censorship resistance.

Nodes evict peers that consume excessive resources or violate protocol rules. Common triggers include:

• Bandwidth abuse: Peers sending spam transactions or overwhelming the node with data.
• Memory exhaustion: Peers causing memory leaks or holding onto excessive state data.
• Protocol violations: Sending invalid blocks, transactions, or malformed messages.
• Stale connections: Peers that are unresponsive or fail to handshake properly.

Eviction targets peers that degrade a node's sync performance or network quality. Key metrics include:

• High latency: Peers with consistently slow response times (e.g., >2 sec ping).
• Low throughput: Peers that fail to deliver requested data (blocks, states) within expected timeframes.
• Propagation delay: Peers that are consistently behind the network tip, providing stale data.
• Failed requests: Repeated timeouts or failures when querying for chain data.

Eviction defends against network-level attacks by identifying suspicious peer behavior patterns.

• Sybil attacks: Multiple connection attempts from IPs in the same subnet, suggesting a single malicious actor.
• Eclipse attacks: A peer (or coordinated group) attempting to monopolize all outbound connection slots to isolate the node.
• Invalid data propagation: Peers repeatedly advertising blocks or transactions that fail validation.
• Banned subnet eviction: Automatic disconnection from peers originating from networks on a denylist (e.g., known hostile ASNs).

Different clients (Geth, Erigon, Lighthouse) implement unique eviction logic based on their architecture.

• Geth's eth/66 penalty system: Accumulates scores for bad behavior; evicts when a threshold is exceeded.
• Erigon's snapshot stall detection: Evicts peers that cause state sync to stall during snapshot retrieval.
• Lighthouse's peer scoring: Uses a reputation-based system where peers with negative scores are disconnected.
• Besu's fork choice violations: Evicts peers that persistently send blocks conflicting with the local fork choice rule.

Many nodes use a scoring system to quantitatively assess peers, where eviction is the final penalty. Scores are adjusted for:

• Good behavior: Successfully delivering useful blocks (+points).
• Bad behavior: Sending invalid data or being unresponsive (-points).
• Eviction threshold: A peer is evicted when its score falls below a minimum (e.g., -100).
• Decay over time: Scores slowly recover, allowing temporarily poor peers to reconnect later.

Not all eviction is automatic. Node operators can manually trigger eviction for administrative reasons.

• Manual ban via RPC: Using admin_removePeer or similar management API calls.
• Peer denylist updates: Adding a peer's ID or IP to a static ban list, causing immediate eviction.
• Client restart with clean tables: Some clients evict all peers on restart to rebuild a fresh peer set.
• Resource management: Manually disconnecting peers during node maintenance or scaling events.

Solana's Turbine block propagation protocol incorporates Quality of Service (QoS) based on stake. Validators prioritize connections to and from peers with higher voting stake. During network congestion or when pruning peer lists, low-stake peers are more likely to be evicted. This creates a stake-weighted network topology that naturally defends against spam and Sybil attacks, as attackers would need substantial economic stake to maintain network presence.

• Mechanism: Peer selection and retention probability is proportional to stake.
• Outcome: Incentivizes alignment with network security.

Avalanche's platform, with its subnet architecture, requires sophisticated peer management. Validators in a Primary Network or a custom subnet must maintain connections to other validators in that specific subnet. Eviction logic must respect subnet membership. A peer might be evicted from one subnet's connection pool but retained for another. This ensures subnet isolation and that consensus messaging remains within the designated validator set.

• Key differentiator: Multi-network peer sets managed concurrently.
• Challenge: Balancing global and subnet-specific connection limits.

The primary purpose of peer eviction is to prevent resource exhaustion attacks, where an attacker floods a node with many connection requests to consume its memory, bandwidth, and CPU. Eviction algorithms monitor peer behavior and disconnect those that:

• Consume disproportionate bandwidth without contributing useful data.
• Send invalid or malformed messages.
• Fail to respond to ping/pong messages, indicating a stale connection.
• Attempt to monopolize connection slots, preventing legitimate peers from joining.

Nodes use deterministic algorithms to decide which peers to evict when connection limits are reached. Common criteria include:

• Connection Age: Newer connections are often evicted before long-lived, stable peers.
• Peer Score: A reputation score based on past behavior; low-scoring peers are evicted first.
• Network Utility: Peers that provide unique data (e.g., from a rare network subnet) may be protected.
• Protocol Compliance: Peers violating the wire protocol (e.g., Bitcoin's P2P protocol) are prime candidates for eviction. Implementations like Bitcoin Core use a combination of these factors in a protected peer model.

Peer eviction is a first line of defense against eclipse attacks, where an attacker isolates a target node by surrounding it with malicious peers they control. A robust eviction policy prevents this by:

• Ensuring a diverse set of peer connections from different network subnets and autonomous systems (AS).
• Evicting peers that are too geographically or topologically similar.
• Maintaining connections to anchor peers or hardcoded seed nodes that are resistant to eviction, providing a trusted connection to the real network.

Bitcoin Core uses a sophisticated eviction logic that protects peers based on several traits, prioritizing the eviction of peers that are young, have low minimum ping times, and offer the least network diversity. Geth (Ethereum) employs a peer scoring system where malicious actions (like sending invalid blocks) lower a peer's score, making them eligible for disconnection. Lighthouse (Ethereum consensus client) evicts peers based on sync status and failure to provide requested attestations or blocks.

Eviction policies must work in tandem with Sybil resistance. Since attackers can create many fake identities (Sybils), eviction cannot rely on IP addresses alone. Solutions include:

• Using a persistent peer identity, like a public key in libp2p, to track behavior across sessions.
• Peer scoring that persists across connection attempts, penalizing bad actors even if they reconnect.
• Requiring proof-of-work in initial handshakes (as in Ethereum's devp2p) to increase the cost of creating Sybil identities.

Node operators must balance security with network health. Aggressive eviction can lead to network fragmentation, while lax policies expose nodes to attacks. Key configuration parameters include:

• Max Peers: The total number of inbound/outbound connections allowed.
• Eviction Threshold: The point at which the eviction process is triggered.
• Protected Criteria: Defining which peer traits (e.g., being a block relayer) grant immunity from eviction. Misconfiguration can inadvertently evict honest peers, reducing a node's ability to receive blocks and transactions promptly.