Network Foundations Slides Protocol Layer Analysis
Network Foundations
Mapping the P2P Architectures of Bitcoin and Ethereum
Blockchain Networking Series // L1
The Topology Shift
01/05
Client-Server
Centralized authority & trust.
Single point of failure.
Asymmetric resource distribution.
Unstructured P2P
Distributed authority & verification.
Resilient to node churn & outages.
Symmetric participant roles.
Network Taxonomy
Full Nodes
Stores the entire blockchain history. Validates every transaction and block against consensus rules.
Resource Heavy
Light Nodes (SPV)
Downloads only block headers. Relies on full nodes for transaction verification (Merkle proofs).
Resource Light
Mining Nodes
Full nodes that also participate in block production. Requires specialized hardware (ASICs).
Compute Heavy
Node Discovery
How does a new node join the network without a central registrar?
1
DNS Seeds: Hardcoded URLs that return a list of active node IP addresses.
2
Peer Exchange (PEX): Asking connected peers for their own lists of known nodes.
3
Hardcoded IPs: Fallback addresses included in the software client.
Inquiry: Trusting the Stranger
"If you receive a peer list from a DNS seed, how can you be sure the list isn't malicious? If you connect only to peers from that list, can you be 'shadow-banned' from the true mainnet?"
Discuss
What protocols prevent one entity from controlling all your incoming peer connections?
Research
Look up "Bitcoin Eclipse Attack" for tomorrow's prep.
Topology Mapping Worksheet Topology Mapping
CS 400: Blockchain Networking // Lesson 1
Student Name:
Date:
Learning Objective
Analyze and diagram the structural differences between traditional centralized networks and the decentralized P2P topology used in the Bitcoin network. Identify the resource requirements and roles for various node types.
Part 1: Network Structural Analysis
In the space below, contrast the two network models based on the criteria provided.
Criteria Client-Server Model Unstructured P2P Model Data Consistency Fault Tolerance Scalability Bottleneck
Part 2: Bitcoin Node Taxonomy
Match the role with the specific requirements and functions within the Bitcoin network.
A. Full Node
Primary Responsibility:
Required Resources (Storage/Bandwidth):
B. Simplified Payment Verification (SPV)
How it verifies transactions without a local DB:
Major Security Trade-off:
Part 3: The Bootstrapping Problem
Scenario: A new node joins the network for the first time. It has the Bitcoin software but no IP addresses of other nodes.
Briefly explain why relying only on DNS seeds might be a centralization risk. What happens if the DNS seeds are compromised?
Peer Exchange (PEX) vs DNS Seeds:
Which of these mechanisms is used for initial discovery vs sustained discovery? Why?
Topology Mapping Answer Key Topology Mapping [Answer Key]
Instructor Resource // Lesson 1
Part 1: Network Structural Analysis
Criteria Client-Server Model Unstructured P2P Model Data Consistency Centralized: Easy to maintain via a single "Source of Truth" server. All clients see what the server provides. Distributed: Difficult. Requires consensus algorithms to ensure all nodes eventually agree on a single history. Fault Tolerance Low: Single point of failure. If the server goes down, the entire network is offline. High: Resilient. Thousands of independent nodes; the network survives as long as a handful of nodes are active. Scalability Bottleneck Vertical: Limited by server hardware (CPU/RAM/Bandwidth). Requires upgrading the central node. Horizontal: Limited by network latency and bandwidth. More nodes don't necessarily increase speed; they can increase congestion.
Part 2: Bitcoin Node Taxonomy
A. Full Node
Primary Responsibility:
Enforcing consensus rules. Validating every block and transaction ever created. Serving data to other peers.
Required Resources:
High storage (~500GB+), consistent bandwidth, and 24/7 uptime recommended.
B. SPV (Light Node)
How it verifies transactions:
Uses Merkle Proofs. Downloads only headers and asks full nodes for proof that a transaction is in a block.
Major Security Trade-off:
Privacy: Full nodes can see which addresses the light node is interested in. Trust: Assumes the majority of hash power is honest.
Part 3: The Bootstrapping Problem
Centralization Risk of DNS Seeds:
If DNS seeds are the only gateway, the operators of those seeds (often core developers) could provide a filtered list of IP addresses. This could lead to an "Eclipse Attack" where a new node is only connected to malicious peers, blinding them to the real chain.
PEX vs DNS Seeds:
DNS Seeds are for initial discovery (cold start). Peer Exchange (PEX) is for sustained discovery. Once a node is connected to one honest peer, it can learn about thousands more through PEX, making the DNS seeds unnecessary for established nodes.
Propagation Physics Slides Information Propagation
Propagation Physics
Gossip Protocols, Rumors, and Global Consensus Latency
Blockchain Networking Series // L2
The Propagation Race
In a decentralized network, "truth" is only as fast as the network's slowest link. When a miner finds a block, they must tell the world before someone else finds a competing block.
The Goal
Minimize tprop (Time to reach 99% of nodes) to prevent chain forks.
The Enemy
Bandwidth constraints and geographic latency (speed of light in fiber).
Gossip Protocol Mechanics
Inspired by epidemic models (epidemiology), gossip protocols ensure information reaches every node with high probability.
Step 1: Node A receives a new TX.
Step 2: Node A picks f random peers (Fanout).
Step 3: Forward the TX to those peers.
Step 4: Recipients repeat the process.
O(log N)
Gossip protocols typically achieve exponential spread, reaching the entire network in logarithmic time.
Inventory (INV) Messages
Nodes don't just blast raw data. To save bandwidth, they use a 3-step handshake:
INV (Inventory): "I have hash 0xABC. Do you want it?"GETDATA: "Yes, send me 0xABC."TX/BLOCK: "Here is the full data."
Critical Thought:
Why not just send the data immediately? Consider the "Selfish Mining" implications of propagation speed.
Handshake Visual Placeholder
Latency & Orphans
If it takes 10 seconds to propagate a block, but a new block is found every 15 seconds, the network will constantly fork.
Stale Blocks
Blocks found on a valid chain that doesn't become the longest/heaviest due to propagation delay.
Centralization Risk
Miners with high-speed fiber have an unfair advantage over miners behind slow links.
Gossip Simulation Lab Gossip Simulation Lab
CS 400: Blockchain Networking // Lesson 2
Student Name:
Simulation Objective
Today, we will simulate a gossip protocol manually to observe how "Fanout" (the number of peers each node contacts) affects the speed of propagation across a network of 64 nodes.
Part 1: Protocol Parameters
Define the following variables for our simulation:
Total Nodes (N)
64
Fanout (f)
Number of peers informed by a node in each round.
Mathematical Prediction:
The theoretical number of rounds \( R \) to reach all nodes is approximately:
R ≈ logf(N)
Part 2: Propagation Rounds
Assume a starting point where 1 node has the transaction. Calculate the total number of unique nodes reached in each round. Do not count nodes already informed.
Round (t) Nodes Informed in This Round Cumulative Nodes Informed % of Network (N=64) 0 1 1 1.5% 1 2 3 4
Part 3: The Cost of Efficiency
1. If we increase the Fanout (f), propagation is faster. What is the downside regarding network bandwidth?
2. In a real-world gossip protocol, nodes often receive the same transaction multiple times from different peers. How does the "INV/GETDATA" handshake mitigate this waste?
Gossip Simulation Guide Gossip Protocol [Instructor Guide]
Teaching Notes & Simulation Solutions
Facilitation Strategy
The Hook: Start by asking students how long it takes for a "viral" tweet to reach the whole world. Is it linear (1 person tells 1 person) or exponential?
The Simulation: Use the table in the lab sheet. If students choose a Fanout (f) of 3, they will see that the network of 64 is saturated in just 4-5 rounds.
Simulation Sample Solution (Fanout f=3)
Round (t) Nodes Informed in This Round Cumulative Nodes Informed % of Network (N=64) 0 Initial state 1 1.5% 1 3 * 1 4 6.25% 2 3 * 3 13 20.3% 3 3 * 9 40 62.5% 4 3 * 27 (Max 24 left) 64 100%
Discussion Points
Downside of high Fanout:
Redundancy. If f=10, every node will receive the same transaction from multiple neighbors, wasting significant bandwidth. Higher fanout leads to more duplicate messages "colliding" at nodes.
Handshake Mitigation:
By sending an INV (hash) first, a node allows its neighbor to say "I already have that," preventing the transfer of the full (much larger) transaction or block data multiple times.
Chain Sync Slides Bootstrapping & Sync
Chain Sync
Verifying 500GB of History in a Trustless Environment
Blockchain Networking Series // L3
The IBD Process
When you turn on a new Bitcoin node, it is at Height 0 . It must download and verify every block since Jan 3, 2009.
Verification > Download
Downloading is fast; verifying signatures and Merkle roots is CPU intensive.
Parallel Sync
Nodes download different parts of the chain from different peers to maximize speed.
BITCOIN CORE SYNC RUNNING...
Block: 824,311
Verification: [##########----------] 52%
Peer 1: 172.16.0.1 (Headers)
Peer 2: 192.168.1.5 (Block Data)
Peer 3: 84.22.11.9 (Block Data)
Speeding it Up
Checkpoints
Hardcoded block hashes in the software. The node "knows" that block 500,000 must have a certain hash, preventing peers from feeding it a long fake chain.
Pruning
Nodes verify the history but delete old block data once verified, keeping only the UTXO set (current state). Reduces storage from 500GB to ~5GB.
Headers-First Sync
80 Bytes
A Block Header
1. Download all headers first (~50MB total). This is very fast.
2. Verify Proof of Work on headers. This ensures you are on the "heaviest" chain before downloading huge block data.
3. This prevents Disk Fill Attacks where a peer sends fake 1MB blocks that are invalid but take time to process.
Security of Sync
"If a node is given two valid chains of equal length by two different peers, how does it choose which one to follow during the initial sync?"
The Cumulative Work Rule
Nodes don't follow the "longest" chain, but the one with the most "Proof of Work" (difficulty).
Case Study Prep
What happens if you are synced but then lose connection for 1 hour? Let's analyze "re-orgs".
Bootstrapping Case Study Bootstrapping Challenges
CS 400: Case Study // Lesson 3
Student Name:
Case Study: The "Empty Chain" Attack
Imagine an attacker, Mallory, who wants to prevent a new node (Alice) from joining the real Bitcoin network. Mallory controls 100 high-speed nodes. When Alice joins, she happens to connect only to Mallory's nodes.
Mallory sends Alice a valid chain that is 500,000 blocks long, but it contains zero transactions (except for coinbase rewards). Because these blocks were mined with very low difficulty in a private environment, Mallory could generate them in seconds.
1. The Verification Gap
Alice's node checks the difficulty (PoW) of the blocks. Why does Alice realize Mallory's chain is fake even if it is "longer" than the real chain?
2. The Role of Checkpoints
Bitcoin Core hardcodes the hash of block #295,000. How does this specific feature stop Mallory's attack instantly?
The Disk-Fill Vulnerability
Early versions of Bitcoin synced "Blocks First" (downloading the full 1MB block before verifying it). A malicious peer could send 100GB of random, invalid data.
How does "Headers-First" sync act as a firewall against this resource exhaustion attack?
Reflect: If you were designing a new P2P protocol, would you include hardcoded checkpoints? Why or why not (consider decentralization)?
Reference: Bitcoin Core v0.10.0+ implementation notes on 'Headers First'
Sync Discussion Guide Sync Discussion Guide
Instructor Resource // Facilitation Notes
Case Study Solutions: The "Empty Chain"
1. Verification Gap (PoW):
Alice's node doesn't just check chain length; it checks cumulative work . Mallory's chain, mined with low difficulty, has almost zero total work compared to the real Bitcoin chain. Even if it's "longer" in block count, it will be rejected.
2. Checkpoints:
Checkpoints act as an "anchor." If Mallory's block #295,000 doesn't have the exact hash hardcoded in Alice's software, her node will immediately disconnect from Mallory and flag her as a bad peer.
3. Headers-First Defense:
A header is only 80 bytes. Alice can check the Proof of Work on the header before committing to download the 1MB block. If the PoW on the header is invalid or too low, she drops the connection without wasting storage or bandwidth on the fake block data.
Deep Dive Discussion Prompts
"Are checkpoints a form of centralization?"
Answer: Theoretically, yes. They require developers to update the software with new hashes. However, they are used sparingly and only for historical blocks that the community has already universally agreed upon.
"How do light nodes (SPV) handle the sync problem?"
Answer: SPV nodes only sync headers. They never verify the full transaction history, meaning they trust that the chain with the most PoW contains only valid transactions.
// Suggested Pacing
00-10: Hook (The 500GB Challenge)
10-25: Lecture (IBD & Headers First)
25-45: Case Study Activity (Group Work)
45-60: Debrief & Deep Dive Discussion
Eclipse Defense Slides Network Security
Eclipse Defense
Sybil Attacks, Network Partitioning, and Peer Scoring
Blockchain Networking Series // L4
Sybil Attacks
An entity creates thousands of fake identities (nodes) to gain a disproportionate influence over the network.
The Goal
Drown out honest nodes, manipulate consensus, or censor transactions.
The Countermeasure
Cost. Making identity expensive (PoW, PoS) prevents free node creation.
Eclipse Attacks
Strategic Blindness
Unlike a Sybil attack which targets the whole network, an Eclipse attack targets a single node .
The attacker monopolizes all incoming and outgoing connections of the victim, "eclipsing" them from the real network.
What can an attacker do?
Feed the victim a fake chain.
Hide the victim's transactions from the world.
Waste the victim's mining power on old blocks.
Defensive Architecture
Peer Scoring
Nodes track the "behavior" of peers. If a peer sends invalid blocks or keeps timing out, their score drops until they are banned.
Outbound Randomization
Nodes must always maintain a few random outbound connections to different IP subnets to ensure they aren't surrounded by one entity.
Fixed Slots
Limiting the number of connections from a single IP range prevents an attacker from filling all your slots using one data center.
Risk Assessment
"If you run your node in a cloud provider like AWS, is it easier or harder to Eclipse you compared to running a node at home?"
Network Partitioning
An attacker could cut the underwater fiber cables connecting two continents. What happens to the ledger state?
Sybil Resistance
Does Proof-of-Stake make Sybil attacks harder or easier than Proof-of-Work? Let's analyze the costs.
Sybil Security Activity Security Audit: Node Defense
CS 400: Blockchain Networking // Lesson 4
Auditor:
Part 1: Attack Diagnostics
Identify which attack is being described and explain the mechanism.
Scenario A: An exchange's node is suddenly receiving no new blocks, and all its 125 peer connections originate from a single AWS region.
Attack Type:
Scenario B: A governance proposal is being voted on. Thousands of new nodes appear overnight to signal support for the change, but they all share similar software versions and uptime patterns.
Attack Type:
Part 2: Defensive Strategy Design
1. Peer Scoring Algorithm
A node must decide when to ban a peer. List three "behavioral triggers" that should result in a negative peer score.
Trigger 1
Trigger 2
Trigger 3
2. IP Diversity Policy
Explain how enforcing a "one connection per /16 subnet" rule helps prevent a single attacker with multiple IP addresses from eclipsing a node.
Part 3: Risk Assessment
In a "Partition Attack," a nation-state cuts the fiber optic cables connecting their country to the rest of the world. Two separate Bitcoin networks now exist. What happens to the transactions made in the smaller partition when the cables are eventually repaired? Why?
Sybil Security Answer Key Security Audit [Answer Key]
Instructor Resource // Lesson 4
Part 1: Attack Diagnostics
Scenario A (Node isolation)
Type: Eclipse Attack
The attacker has monopolized the node's connections. By ensuring all peers are in one AWS region, the attacker controls the node's view of the network, potentially hiding the real chain and double-spending against the exchange.
Scenario B (Identity manipulation)
Type: Sybil Attack
One entity is spoofing many identities to create the illusion of consensus or popularity. While they don't have mining power (in PoW), they can influence "social consensus" or drown out minority voices in the P2P layer.
Part 2: Defensive Strategy Design
1. Peer Scoring Triggers
Sending a block with an invalid signature or invalid transaction.
Announcing an inventory item (INV) but failing to provide the data when requested.
Repeatedly sending "old" blocks that have already been superseded by the main chain.
2. IP Diversity Policy
This forces an attacker to possess IP addresses across many different physical networks and locations. It is much more expensive and difficult to acquire 100 IPs from 100 different ISPs/regions than to acquire 1,000 IPs from a single data center.
Part 3: Risk Assessment (Partition Attack)
When the networks reconnect, the "Longest Chain" (most cumulative PoW) rule applies. The smaller partition almost certainly has less mining power and thus less total work. Its entire history since the split will be orphaned . Transactions made on that side will disappear as if they never happened, unless they were also included on the larger chain.
Scaling Solutions Slides Network Throughput
Scaling Solutions
Sharding, SegWit, and the Block Size Debate
Blockchain Networking Series // L5
The Trilemma
Vitalik Buterin's concept: A blockchain can only maximize 2 of these 3 properties at once.
Scalability
Security
Decentralization
Scaling
Security
Decentral
Vertical: Bigger Blocks
The simplest approach: Increase the block limit from 1MB to 8MB or 32MB.
The Network Penalty:
Increased propagation latency.
Higher orphan rates for small miners.
Centralizes the network to data centers.
Bandwidth vs. Decentralization
Horizontal: Sharding
"Divide and Conquer"
The network is split into "Shards". Every node only processes a fraction of total transactions.
Complexity: Cross-Shard Comm
How does Shard A know that a user in Shard B hasn't already spent their money?
Shard 1
Shard 2
Shard 3
Shard 4
Protocol Optimization: SegWit
By moving signature data (witness) to a separate structure, we effectively increase capacity without a hard fork.
Fixed Capacity
Separating signatures allows more transactions per MB.
Fixes Malleability
Enables Layer 2 solutions like Lightning Network.
Soft Fork
Backward compatible with old nodes.
Scalability Debate Organizer The Scalability Debate
CS 400: Architectural Decision Matrix // Lesson 5
NODE OPERATOR REPORT
Scenario Analysis
You are the lead architect for a new global financial network. You must choose between three scaling strategies. Evaluate each based on the "Trilemma" constraints.
Decision Matrix
Strategy How it Scales Main Engineering Hurdle Decentralization Impact Big Blocks (8MB+) Rating (1-5): ____ Sharding Rating (1-5): ____ SegWit + L2 Rating (1-5): ____
The Orphan Problem
Why does increasing block size specifically disadvantage small miners in rural areas compared to large mining pools in data centers?
Shard Security
If a network has 64 shards, an attacker only needs to control 1/64th of the total network power to corrupt one shard. How might we solve this?
Final Recommendation
Which approach is most "future-proof" for a network aiming for billions of users while remaining decentralized? Justify your choice with one network-layer argument.
Scalability Rubric Teacher Guide Scaling Rubric & Key
Instructor Resource // Final Evaluation
Matrix Guide
Strategy Main Engineering Hurdle Decentralization Impact Big Blocks Bandwidth/Latency. Large blocks take longer to propagate, increasing "Stale" rates. LOW (1/5). Only data centers can keep up. Home users priced out. Sharding Cross-Shard Communication. Ensuring atomicity across different database partitions. MEDIUM (3/5). Complex, but allows home nodes to process part of the chain. SegWit/L2 Liquidity & Routing. Moving complexity to the second layer (Lightning, etc). HIGH (5/5). Keeps base layer light enough for Raspberry Pi nodes.
Grading Criteria
The Orphan Problem (Solution):
Small miners have less bandwidth. If a block is 32MB, the large mining pool across the street from the finder receives it 2 seconds faster than the rural miner. The large pool starts mining the next block immediately, while the rural miner wastes 2 seconds on a block they don't even know exists yet. This creates a "Rich get richer" feedback loop.
Shard Security (Solution):
The standard solution is "Validator Reshuffling." Validators are randomly assigned to shards by a central beacon chain. This prevents an attacker from targeting a single shard because they don't know which one they will be in until the very last second.
Sequence Capstone Discussion
"As we close this sequence, remind students that network engineering in blockchain is always a choice of trade-offs. There is no 'free lunch'. If you want speed, you sacrifice decentralization or increase complexity. The 'P2P Pioneer' is the one who finds the most elegant balance."
