Introduction
So far, our prototype has incorporated all the essential blockchain characteristics:
- Anonymous, secure addresses
- Immutable data storage
- Proof-of-work system
- Verified transaction storage
However, these features alone aren't sufficient. What truly brings them to life—enabling cryptocurrency to exist—is the network.
Imagine a blockchain running on a single node with just one user. What purpose would cryptographic features serve in such a scenario? The network is what makes the entire mechanism operational and impactful.
Think of blockchain features as rules—similar to societal arrangements humans establish to coexist. A blockchain network is a community of programs adhering to the same rules, ensuring longevity through consensus.
Key insight: Without a network or if most nodes don't follow the same rules, those rules become meaningless!
Note: This implementation simplifies network architecture due to complexity constraints. The scenario focuses on distinct node types as a foundation for P2P expansion.
Blockchain Network Architecture
Blockchain networks are decentralized—no central server exists. Instead:
- Nodes act as both clients and servers
- P2P topology enables direct node connections
- Flat hierarchy eliminates centralized control
Implementing such nodes is challenging because they must:
- Interact with multiple peers
- Compare and synchronize states
- Handle dynamic network changes
Node Roles
Nodes can specialize in different functions:
| Role | Functionality |
|---|---|
| Miners | Use dedicated hardware to solve PoW puzzles and create new blocks |
| Full Nodes | Validate blocks/transactions, store complete blockchain copies, route traffic |
| SPV Nodes | Perform lightweight verification by connecting to full nodes (e.g., wallets) |
Simplified Implementation
To simulate a multi-node network on a single machine:
- Port-based identification: Nodes are differentiated by ports (e.g.,
127.0.0.1:3000) - Unique data files: Separate blockchain and wallet files per node (
blockchain_3000.db,wallet_3001.db)
Three node types will operate:
- Central Node: Routes data between other nodes
- Miner Node: Stores transactions and mines new blocks
- Wallet Node: Manages transactions while maintaining a full blockchain copy
Network Communication
Nodes exchange messages via these commands:
| Command | Purpose |
|---|---|
version | Initiates handshake and compares blockchain heights |
getblocks | Requests block hashes rather than full data |
inv | Announces available blocks/transactions |
getdata | Requests specific blocks/transactions |
block/tx | Transfers actual data |
👉 View full message flow diagram
Example: version Handshake
type version struct {
Version int
BestHeight int
AddrFrom string
}When a node receives a version message:
- Responds with its own
version - Requests missing blocks if its chain is shorter
Transaction Lifecycle
- Wallet creates transaction
- Miner receives and stores it in mempool
- When mempool reaches threshold, miner creates new block
- Block propagates to central node
- Wallet nodes synchronize and verify payment
FAQ
Q: Why do SPV nodes need full nodes?
A: They rely on full nodes for transaction verification data while maintaining only partial chain copies.
Q: How do nodes discover each other initially?
A: In Bitcoin, DNS seeds provide initial node addresses. Our implementation hardcodes a central node.
Q: What prevents conflicting transactions?
A: Miners validate transactions before including them in blocks, and the longest valid chain prevails.
Q: Why reindex UTXO after mining?
A: It ensures accurate balance calculations by updating the unspent transaction output set.
Conclusion
This implementation demonstrates core networking concepts despite simplifications. Key improvements would include:
- Real P2P node discovery
- Dynamic block synchronization
- Enhanced security protocols
Blockchain networks transform cryptographic rules into functional ecosystems through distributed consensus—the true innovation behind cryptocurrencies.