Peer-to-Peer Network Architecture

Introduction

A blockchain is not only a data structure or a consensus algorithm. It is also a communication system in which independently operated computers exchange transactions, blocks, status information, and control messages. This communication system is commonly based on a peer-to-peer (P2P) architecture. Unlike a conventional client–server network, a P2P blockchain network has no permanently authoritative communication server. Nodes communicate directly or indirectly with other nodes, and network services emerge from cooperation among participants.

The quality of this architecture strongly influences blockchain security and performance. If valid transactions are propagated slowly, users may experience delays and miners or validators may work on different views of the ledger. If a malicious actor controls many network connections, the actor may isolate a node or delay information. If the network is excessively dense, communication overhead may become uneconomical. Blockchain networking therefore requires a balance among reachability, redundancy, bandwidth, latency, privacy, and resistance to attack.

This chapter examines node discovery, peer communication, transaction and block propagation, gossip protocols, network topology, and decentralized fault tolerance. The discussion applies broadly to permissionless networks such as Bitcoin and Ethereum, while recognizing that permissioned blockchain platforms may use membership services and more controlled network designs.

Learning Objectives

After studying this chapter, you should be able to:

1. Explain the purpose and operation of a blockchain P2P network.
2. Describe how nodes discover, authenticate, select, and maintain peer connections.
3. Distinguish transaction propagation from block broadcasting.
4. Explain gossip protocols and their principal performance and security trade-offs.
5. Analyse common network topologies and their effect on resilience and decentralization.
6. Explain how redundancy, timeouts, peer diversity, and protocol recovery support decentralized fault tolerance.
7. Apply these concepts to the design and diagnosis of a blockchain network.

1. The P2P Network Model

A blockchain node is a computer running software that participates in the network. Depending on its role, a node may validate transactions and blocks, store ledger data, relay messages, produce blocks, or provide services to applications. The terms are related but not identical:

• A full node independently verifies protocol rules and normally stores enough ledger information to validate new data.
• A pruned node validates the chain but discards some older block data after validation.
• A light client obtains selected information from other nodes and performs less local validation.
• A miner or validator participates in block production under the applicable consensus mechanism.
• A relay node is optimized for forwarding information and may serve other nodes without producing blocks.

In a network graph, each node is a vertex and each active communication relationship is an edge. An edge may represent a TCP connection, an encrypted session, or an authenticated channel. The graph is usually dynamic: nodes join and leave, connections fail, and peers change their neighbor sets.

A well-designed blockchain network seeks several properties:

A P2P network does not imply that all nodes are identical. Nodes may have different bandwidth, storage, uptime, software versions, and roles. Decentralization concerns the distribution of control and verification, not perfect equality among nodes.

2. Node Discovery and Peer Admission

A new node must learn how to find other nodes. This process is called node discovery. Discovery normally combines several mechanisms rather than depending on a single directory.

2.1 Initial discovery

Common discovery sources include:

1. Configured seed addresses: Software may include domain names, IP addresses, or public keys for bootstrap services.
2. DNS-based discovery: A domain can return a changing set of node addresses. This is convenient but introduces dependence on DNS operators and should not be treated as a complete trust anchor.
3. Address databases: A node stores addresses learned from earlier sessions and attempts to reconnect to them.
4. Peer exchange: Connected peers provide addresses of additional nodes.
5. Distributed hash tables or rendezvous mechanisms: Some systems use structured lookup services to locate peers.
6. Manual configuration: Private or consortium networks often specify authorized peers directly.

Bootstrap information helps a node enter the network, but it should not determine the node’s entire communication structure. After joining, the node should learn multiple peers through independent paths.

2.2 Peer selection

A node normally maintains a limited number of outbound and inbound connections. Outbound connections are initiated by the node; inbound connections are accepted from other nodes. Connection limits protect operating-system resources and bandwidth, while multiple peers provide redundancy.

Useful selection criteria include:

• successful previous communication;
• protocol and software compatibility;
• geographic and network-provider diversity;
• observed reliability and responsiveness;
• support for required services;
• avoidance of excessive connections from the same address range;
• sufficient bandwidth and connection stability.

Peer selection must be treated carefully. A highly responsive peer is not automatically trustworthy, and geographic diversity alone does not guarantee independence if several nodes share one cloud provider or autonomous system.

2.3 Handshakes and authentication

After establishing a transport connection, nodes exchange protocol information. A handshake may communicate network identity, software version, supported services, chain or protocol identifiers, and a recent synchronization point. The node must reject incompatible or suspicious peers.

Permissionless networks may use cryptographic identities for particular services, but an IP address is not a reliable identity: it can change, be shared, or be hidden behind network address translation. Permissioned networks commonly add certificates, membership authorities, or access-control lists. Authentication confirms who is allowed to connect; it does not by itself prove that all messages received from the peer are correct. Each transaction and block must still be validated according to protocol rules.

2.4 Connection maintenance

A mature node continuously manages its peer set. It may use keep-alive messages, application-level pings, inactivity timers, and reconnection procedures. A peer can be removed for repeated protocol violations, invalid data, excessive resource consumption, or failure to respond.

The node should avoid replacing every failed peer with a random address from the same source. Otherwise, an attacker may repeatedly refill the peer table. Good practice includes address bucketing, source diversity, randomized replacement, and limits on connection attempts.

3. Peer Communication and Message Validation

Blockchain communication consists of structured messages. Typical message classes include:

• transaction announcements and transaction data;
• block announcements and block data;
• requests for missing transactions, blocks, or headers;
• synchronization status messages;
• peer-discovery and liveness messages;
• control messages for protocol negotiation.

A message generally passes through several checks:

1. Transport check: Can the message be decoded and is its size within limits?
2. Protocol check: Is the message type supported and properly formed?
3. Cryptographic check: Are signatures, hashes, or proofs valid?
4. Contextual check: Does the message obey current ledger rules, such as input availability or parent-block relationships?
5. Resource check: Should the node allocate further processing, storage, or bandwidth?

Validation at every receiving node is essential. A relay is not a trusted authority merely because it forwarded information. This principle allows a node to benefit from network communication while preserving independent verification.

A node should also separate announcement from delivery. A peer may first announce a transaction identifier or block hash. The receiving node then requests the full object only if it does not already have it and if the object is relevant. This reduces duplicate transmission.

4. Transaction Propagation

A transaction is usually created and signed by a wallet or application, submitted to a node, and then relayed through the network. A receiving node typically checks the transaction before forwarding it. Checks may include signature validity, transaction format, fee policy, replay protection, and whether the transaction conflicts with known transactions.

Most blockchain systems maintain a temporary transaction pool, often called a mempool. The mempool is not the ledger. It contains transactions that a node considers potentially valid but that have not yet been included in a confirmed block. Different nodes may have different mempool contents because messages arrive at different times, local policies differ, and capacity limits cause eviction.

A simple propagation sequence is:

1. A client submits transaction T to node A.
2. Node A validates T and stores it in its mempool.
3. Node A announces T to selected peers.
4. Peers that do not know T request or receive its contents.
5. Each peer validates T and forwards it according to its policy.
6. A block producer selects T for a candidate block.
7. The resulting block is propagated and independently validated.

Transactions should not be forwarded indefinitely. Nodes use identifiers, such as transaction hashes, to suppress duplicates. They may also use rate limits and relay policies to control spam. Fee markets can provide economic filtering, but fees do not replace protocol validation or anti-abuse measures.

Transaction propagation is vulnerable to privacy leakage. If a node is the first visible source of a transaction, an observer may infer the originator’s network location. Techniques such as randomized delays, stem-and-fluff relay, privacy-preserving overlays, and careful peer selection may reduce this risk, although they can increase latency or complexity.

5. Block Broadcasting and Synchronization

Blocks differ from ordinary transactions because they establish an ordered extension of the ledger. A block normally contains a reference to a parent block, a set of transactions, and consensus-related data such as a proof, signature, or validator information.

When a node receives a block announcement, it may request the complete block or missing parts. The node then checks:

• the parent reference and chain position;
• the block structure and size;
• the consensus proof or producer authorization;
• all included transactions;
• state-transition rules;
• timestamp and protocol constraints;
• whether the block creates an invalid or conflicting chain.

If a block arrives before its parent, the node may store it temporarily as an orphan or future block. It can then request the missing ancestor. If the block is invalid, it must not be relayed as valid information.

Block propagation methods

Two broad approaches are common:

• Inventory-first propagation: A node announces a block identifier, and peers request the block if needed. This saves bandwidth when many peers already have the block.
• Direct or optimized relay: A node sends block data quickly to selected peers, sometimes using compact representations or specialized relay networks. This reduces latency but may favor well-connected infrastructure.

Compact block techniques transmit transaction identifiers and allow a peer to reconstruct much of the block from its mempool. Missing transactions are requested separately. Such methods reduce bandwidth but depend on mempool similarity; when similarity is low, recovery requests can offset the savings.

Block propagation matters particularly in proof-of-work networks. If a miner finds a block but other miners learn about it slowly, some may continue mining on the previous tip. This can increase temporary forks and reduce effective security. In proof-of-stake systems, delayed block and vote messages can similarly affect finality and fork choice.

6. Gossip Protocols

A gossip protocol, also called an epidemic protocol, spreads information through repeated peer-to-peer forwarding. A node learns an object, selects some neighbors, and announces or sends the object. Those neighbors repeat the process. Duplicate suppression prevents endless retransmission.

A conceptual gossip cycle is:

Figure: Simplified multi-hop gossip propagation. Real networks use dynamic, often asymmetric peer relationships.

Gossip is attractive because it does not require a central broadcaster and can tolerate individual node failures. However, naive flooding creates duplicate traffic. Important design parameters include:

• fan-out: number of peers selected for forwarding;
• push: sending an object to a peer;
• pull: asking a peer whether it has new objects;
• push–pull: combining announcements and requests;
• time-to-live: maximum forwarding scope or lifetime;
• deduplication: recording identifiers already seen;
• anti-entropy: periodically comparing inventories to repair omissions.

Suppose a node forwards an object to a fan-out of f peers in an ideal tree with no overlap. After r rounds, the number of reached nodes could be approximated by f^r, but real networks do not behave as ideal trees. Peers overlap, some are offline, and duplicate suppression limits new recipients. Thus this expression is only an intuition about rapid growth, not a reliable prediction of network coverage.

Gossip protocols provide probabilistic rather than absolute delivery guarantees unless combined with explicit requests, synchronization, or application-level confirmation. A node that misses a transaction announcement may later recover it through anti-entropy or block synchronization.

7. Network Topology and Performance

Topology describes how connections are arranged. Common forms include:

Public blockchains usually use an overlay network rather than connecting every node directly. If N nodes each maintained a connection to every other node, the number of undirected links would be:

Here, L is the number of links and N is the number of nodes. This formula assumes a complete undirected graph in which every pair has one direct relationship. For large N, L grows approximately with N², making a full mesh impractical. Limited-degree overlays reduce connection cost while preserving multiple paths.

Latency is also important. If one hop takes an average time τ and a message traverses h sequential hops, the communication component of delay is approximately:

D is the propagation delay, h is the number of sequential hops, and τ is average per-hop delay. This is a simplified model that excludes processing, queuing, retransmission, and serialization time. It is useful for intuition, not precise capacity planning.

A network should not optimize latency by concentrating all nodes around a small group of relays. Low latency obtained through dependence on a few operators may reduce independence and censorship resistance. Professional network design evaluates both performance and control distribution.

8. Decentralized Fault Tolerance

Fault tolerance is the ability to continue useful operation despite failures or adversarial behavior. In a blockchain P2P network, faults may include crashed nodes, unavailable networks, software defects, malformed messages, bandwidth exhaustion, censorship, eclipse attacks, and partitions.

8.1 Failure models

• Crash failure: A node stops responding.
• Omission failure: A node fails to send or forward some messages.
• Timing failure: A node responds too slowly or outside protocol limits.
• Byzantine failure: A node behaves arbitrarily, including sending contradictory or malicious messages.
• Network partition: Groups of honest nodes cannot communicate temporarily.

Consensus protocols define what agreement is possible under particular assumptions, but networking mechanisms support those protocols by delivering information. Consensus cannot correct every networking weakness. For example, a node that is completely isolated may be unable to learn the current chain, even if the rest of the network remains honest.

8.2 Resilience mechanisms

Important mechanisms include:

1. Redundant peers: Multiple connections reduce dependence on any one node.
2. Independent paths: Diversity of providers, locations, and operators limits correlated failure.
3. Timeouts and retries: Failed requests are retried through alternative peers.
4. Checkpoint or header synchronization: A node can recover from gaps without receiving every historical message in real time.
5. Duplicate suppression: Prevents one message from consuming unlimited resources.
6. Rate limits and quotas: Reduce denial-of-service impact.
7. Peer scoring: Persistent misbehavior lowers the likelihood of future connection.
8. Local validation: Invalid data is rejected regardless of its source.
9. Randomized peer rotation: Makes long-term isolation harder.
10. Monitoring and alerts: Operators can detect unusual peer concentration, latency, or message loss.

8.3 Eclipse and Sybil attacks

In an eclipse attack, an adversary controls or influences most of a victim’s apparent peers and presents a restricted view of the network. The attacker may delay transactions, hide blocks, or manipulate the victim’s observations. Peer diversity, outbound connections, address-table protection, and periodic rotation reduce the risk.

A Sybil attack creates many apparently separate identities. In a permissionless network, identities are inexpensive unless the protocol imposes a cost or uses resource-based defenses. Network-layer Sybil resistance may involve connection limits, address diversity, proof-of-work puzzles for certain actions, reputation, or coordination with the consensus mechanism. No single technique eliminates all Sybil risk.

8.4 Partition recovery

During a partition, different groups may temporarily receive different transactions or blocks. When connectivity returns, nodes exchange missing data and apply the protocol’s fork-choice and finality rules. Applications should distinguish:

• propagation: a message has reached a node or a portion of the network;
• inclusion: a transaction appears in a block;
• confirmation: additional blocks or votes support that block;
• finality: the protocol makes reversal impossible or economically/procedurally prohibitive under its assumptions.

A transaction broadcast is therefore not equivalent to a confirmed payment.

9. Applied Case: Diagnosing Slow Block Propagation

The following is an illustrative case.

Background

A consortium operates a permissioned blockchain across six organizations and three geographic regions. Each organization runs validator and observer nodes. Users report that blocks appear quickly in one region but arrive 8–12 seconds later in another. Occasional competing blocks are also observed.

Problem

An initial investigation shows that all organizations use a small set of centrally managed relay servers. Several validator nodes maintain connections only to relays in their own region. The relays are overloaded during peak transaction periods, and two organizations share the same cloud provider.

Analysis

The architecture has a hierarchical, partially star-like topology. It provides convenient administration but creates bottlenecks and correlated failure. Local relays reduce regional latency, yet cross-region traffic depends on a small number of links. The network also has insufficient peer diversity and no clear automatic recovery path when a relay is unavailable.

Approach and solution

The operator takes the following steps:

1. Each validator receives at least two cross-region outbound connections.
2. Relay servers remain available but no longer serve as mandatory intermediaries.
3. Nodes use authenticated encrypted sessions and verify every block independently.
4. Block announcements are separated from full-block transfer, with requests routed through alternative peers.
5. Maximum message sizes, rate limits, and request timeouts are standardized.
6. Operators monitor propagation delay, peer concentration, failed requests, and orphaned blocks.
7. A scheduled peer-rotation policy reduces long-term dependence on a fixed neighbor set.

Outcome

Cross-region propagation becomes more consistent, and relay overload no longer isolates validators. The network still experiences occasional delay during provider outages, but alternative paths allow synchronization to recover automatically. The solution does not eliminate latency; it improves resilience by distributing communication paths and operational responsibility.

Learning points

The case demonstrates that performance and decentralization are related but distinct. Central relays may improve average latency while weakening fault tolerance. A professional design therefore measures not only speed, but also path diversity, operator concentration, recovery time, and the ability of nodes to validate data independently.

10. Operational Metrics and Best Practices

Network operators should measure the system rather than rely on assumptions. Useful metrics include:

• number and diversity of inbound and outbound peers;
• median and tail transaction propagation delay;
• block propagation delay and missing-data request rate;
• peer connection churn and failed handshakes;
• bandwidth consumed by duplicate messages;
• frequency and duration of partitions;
• invalid-message rates and peer bans;
• concentration by country, autonomous system, cloud provider, or organization;
• synchronization lag and recovery time.

Best practices include:

1. Maintain independent outbound peers rather than relying only on inbound connections.
2. Combine announcements with explicit retrieval and periodic synchronization.
3. Validate all transactions and blocks locally.
4. Use authenticated encryption where appropriate, while recognizing that encryption does not establish data validity.
5. Apply resource limits to prevent memory, CPU, and bandwidth exhaustion.
6. Protect peer databases from rapid poisoning or address replacement.
7. Design for provider, geographic, software, and organizational diversity.
8. Keep clocks reasonably synchronized, but do not treat timestamps as proof of truth.
9. Test partition, relay failure, packet loss, and high-load scenarios.
10. Document governance for software upgrades, emergency responses, and changes to discovery infrastructure.

11. Governance, Privacy, and Contemporary Developments

Network architecture has governance consequences. If a small number of companies operate most relays, cloud infrastructure, or discovery services, formal protocol decentralization may coexist with practical centralization. Governance teams should disclose infrastructure concentration and define how emergency changes are authorized.

Privacy also requires careful treatment. Network metadata can reveal transaction timing, probable origin, organizational relationships, and geographic information. Operators should collect only necessary logs, protect them appropriately, and comply with applicable privacy and data-protection requirements. Permissioned networks must define who may discover peers and who may inspect transaction content.

Contemporary systems increasingly use authenticated transport encryption, efficient serialization, compact block relay, erasure coding, and specialized high-bandwidth relay paths. These techniques can improve performance, but they may introduce new dependencies. Artificial intelligence may assist with anomaly detection, traffic forecasting, and operational alerting; it should not be allowed to replace deterministic transaction and block validation. A machine-learning classifier can identify suspicious behavior, but protocol rules must decide whether data is valid.

Challenges and Limitations

P2P architecture involves unavoidable trade-offs:

• More peers increase redundancy but consume resources.
• Aggressive gossip reduces delay but creates duplicate traffic.
• Compact relay saves bandwidth but depends on shared transaction knowledge.
• Random peer selection improves unpredictability but may reduce performance.
• Central relays improve manageability but can create bottlenecks and governance risk.
• Encryption protects message content in transit but does not hide all metadata.
• Local validation protects integrity but requires computational and storage capacity.
• Rapid peer rotation may resist eclipse attacks but can increase connection churn.

Network-level guarantees are also probabilistic or assumption-dependent. A blockchain cannot guarantee instant delivery, universal availability, or perfect resistance to censorship. Sound design makes assumptions explicit, monitors violations, and provides recovery mechanisms.

Chapter Summary

Blockchain networks use dynamic peer-to-peer overlays to distribute transactions, blocks, and synchronization information without requiring a permanent central communication server. Nodes discover peers through seeds, address databases, peer exchange, configured membership, or structured mechanisms. They negotiate sessions, maintain diverse connections, and validate all received data independently.

Transactions are usually announced, requested, validated, stored temporarily in mempools, and forwarded through controlled gossip. Blocks require additional checks involving parent relationships, consensus proofs, transactions, and fork-choice rules. Gossip protocols provide scalable multi-hop dissemination, but they require duplicate suppression, rate controls, and recovery procedures such as anti-entropy and synchronization.

Network topology affects both performance and decentralization. Complete meshes are expensive, while limited-degree random or hybrid overlays offer scalability and redundancy. Decentralized fault tolerance depends on multiple peers, independent paths, timeouts, retries, local validation, peer diversity, and resistance to Sybil and eclipse attacks. Finally, practical network engineering must consider privacy, governance, provider concentration, monitoring, and failure recovery—not merely message speed.

Key Terms

Peer-to-peer network: A network in which participating nodes communicate directly or through other peers without a permanently authoritative central server.

Node: A computer running blockchain software and participating in network functions.

Full node: A node that independently verifies protocol rules and ledger data.

Light client: A node that relies on other nodes for selected information and performs reduced local processing.

Node discovery: The process by which a node finds potential communication peers.

Peer exchange: Sharing known node addresses with connected peers.

Handshake: Initial protocol exchange used to negotiate identity, capabilities, and network compatibility.

Mempool: A temporary collection of transactions considered potentially valid but not yet included in a confirmed block.

Transaction propagation: Distribution of a transaction across participating nodes.

Block propagation: Distribution and validation of a newly produced block.

Gossip protocol: A repeated peer-to-peer dissemination method using announcements, forwarding, and duplicate suppression.

Fan-out: The number of peers to which a node forwards information during a propagation step.

Anti-entropy: Periodic comparison or synchronization used to repair missed information.

Overlay network: A logical network built over underlying Internet connections.

Network topology: The pattern of relationships among nodes and communication links.

Eclipse attack: An attack that surrounds a victim with adversarial or colluding peers.

Sybil attack: An attack involving many apparently independent identities controlled by one actor.

Fault tolerance: The capacity to continue operating despite failures or adversarial behavior.

Finality: The condition in which a protocol treats a transaction or block as irreversible under stated assumptions.

Review Questions

Short Answer Questions

1. What is the purpose of node discovery in a blockchain network?
2. Why is a mempool not equivalent to the blockchain ledger?
3. Define a gossip protocol and state one advantage of using it.
4. What is an eclipse attack?
5. Why should a node validate a block even when it receives the block from a trusted peer?

Long Answer Questions

1. Explain the complete lifecycle of a transaction from submission through propagation and block inclusion.
2. Compare mesh, random-overlay, hierarchical, and star-like topologies in terms of scalability and resilience.
3. Describe how block propagation differs from transaction propagation.
4. Explain the roles of timeouts, retries, peer rotation, and diversity in decentralized fault tolerance.
5. Discuss the trade-offs between centralized relay infrastructure and a more distributed peer network.

Analytical / Application Questions

1. A blockchain node has ten peers, but eight are hosted by the same cloud provider. Analyse the risks and recommend improvements.
2. During a regional network partition, two groups produce different chain tips. Explain how propagation, synchronization, fork choice, and finality should be analysed after connectivity returns.
3. Design a peer-maintenance policy for a permissioned blockchain spanning four organizations and two countries. Identify discovery, authentication, diversity, monitoring, and failure-recovery requirements.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the role of a full node?

A. It only forwards messages and never validates them.

B. It independently verifies protocol rules and ledger data.

C. It creates a permanent central directory for all peers.

D. It stores only wallet passwords.

Correct Answer: B. It independently verifies protocol rules and ledger data.

Question 2

What is the main purpose of a handshake between blockchain peers?

A. To negotiate compatibility and exchange protocol information.

B. To finalize every transaction immediately.

C. To replace cryptographic validation.

D. To guarantee that the peer is honest.

Correct Answer: A. To negotiate compatibility and exchange protocol information.

Question 3

Which item normally belongs in a mempool?

A. A transaction that is potentially valid but not yet included in a block.

B. Only transactions that have achieved finality.

C. All historical blocks.

D. Peer passwords and private keys.

Correct Answer: A. A transaction that is potentially valid but not yet included in a block.

Question 4

In a gossip protocol, what does duplicate suppression accomplish?

A. It prevents nodes from independently validating blocks.

B. It reduces repeated forwarding of information already seen.

C. It guarantees that every node receives a message instantly.

D. It converts a permissionless network into a permissioned one.

Correct Answer: B. It reduces repeated forwarding of information already seen.

Question 5

Why is a complete mesh usually impractical for a large blockchain network?

A. It prevents any direct communication.

B. The number of links grows approximately with the square of the number of nodes.

C. It permits only one node to validate transactions.

D. It cannot support encrypted communication.

Correct Answer: B. The number of links grows approximately with the square of the number of nodes.

Question 6

Which practice most directly reduces eclipse-attack risk?

A. Using only one long-lived peer.

B. Accepting all addresses from one bootstrap service.

C. Maintaining diverse peers and periodically rotating connections.

D. Disabling local block validation.

Correct Answer: C. Maintaining diverse peers and periodically rotating connections.

Question 7

What is the most accurate distinction between transaction propagation and transaction confirmation?

A. Propagation means a transaction is relayed; confirmation means it has received ledger support under the protocol.

B. They are always exactly the same event.

C. Propagation occurs only after finality.

D. Confirmation means the transaction is stored only in a mempool.

Correct Answer: A. Propagation means a transaction is relayed; confirmation means it has received ledger support under the protocol.

Question 8

If an idealized gossip process has fan-out f = 3 and operates for two non-overlapping rounds, how many recipients could be reached in the second round from the origin under the simplified tree assumption?

A. 3

B. 5

C. 6

D. 9

Correct Answer: D. 9

Question 9

Which is an example of Byzantine failure?

A. A node loses power and stops responding.

B. A node deliberately sends conflicting or invalid messages.

C. A cable introduces a fixed transmission delay.

D. A node closes normally after synchronization.

Correct Answer: B. A node deliberately sends conflicting or invalid messages.

Question 10

Why can central relay servers create governance and resilience concerns?

A. They make cryptographic signatures mathematically impossible.

B. They may become bottlenecks, single points of failure, or concentrations of control.

C. They prevent all nodes from communicating over the Internet.

D. They eliminate the need for peer discovery in every network.

Correct Answer: B. They may become bottlenecks, single points of failure, or concentrations of control.