Network Architecture
Cloud Service operates on a decentralized peer-to-peer network that enables secure, trustless transactions and distributed computing.
Network Overview
┌─────────────────────────────────────────────────────────────────────┐
│ Cloud Service Network │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Node 1 │◄───────►│ Node 2 │◄───────►│ Node 3 │ │
│ │ (Full) │ │ (Mining) │ │ (Full) │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ │ ┌─────▼─────┐ │ │
│ └─────────────►│ Node 4 │◄─────────────┘ │
│ │ (Light) │ │
│ └─────┬─────┘ │
│ │ │
│ ┌──────────┐ ┌────▼─────┐ ┌──────────┐ │
│ │ Node 5 │◄───────►│ Node 6 │◄───────►│ Node 7 │ │
│ │ (API) │ │ (Full) │ │ (Mining) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘Network Layers
1. Peer-to-Peer Layer
The foundation of the Cloud Service network is the P2P layer where nodes discover and communicate with each other.
Node Discovery:
- DNS seed nodes provide initial peer lists
- Nodes exchange peer addresses
- Automatic reconnection on disconnect
Message Types:
| Message | Purpose |
|---|---|
version | Handshake and capabilities |
verack | Version acknowledgment |
addr | Address broadcast |
inv | Inventory announcement |
getdata | Data request |
tx | Transaction broadcast |
block | Block broadcast |
getblocks | Block request |
ping/pong | Keep-alive |
2. Consensus Layer
The consensus layer ensures all nodes agree on the state of the blockchain.
Consensus Rules:
- Proof of Work (ZelHash)
- Longest chain rule
- Block validation
- Transaction validation
3. Application Layer
The application layer provides services built on top of the blockchain.
Services:
- Wallet operations
- Smart contracts (future)
- Decentralized computing
- Storage services
Node Communication
Connection Process
Node A Node B
│ │
│────── TCP Connection ────────────►│
│ │
│────── version message ──────────►│
│ (protocol version, │
│ services, timestamp) │
│ │
│◄───── version message ───────────│
│ │
│────── verack ───────────────────►│
│◄───── verack ────────────────────│
│ │
│────── getaddr ──────────────────►│
│◄───── addr (peer list) ─────────│
│ │
│ Connection Established │Message Format
┌─────────────────────────────────────────────────────────┐
│ Network Message │
├─────────────────────────────────────────────────────────┤
│ Magic (4 bytes) │ Network identifier (mainnet) │
├─────────────────────────────────────────────────────────┤
│ Command (12 bytes) │ ASCII command name │
├─────────────────────────────────────────────────────────┤
│ Length (4 bytes) │ Payload length │
├─────────────────────────────────────────────────────────┤
│ Checksum (4 bytes) │ First 4 bytes of double SHA256 │
├─────────────────────────────────────────────────────────┤
│ Payload (variable) │ Message data │
└─────────────────────────────────────────────────────────┘Network Topology
Gossip Protocol
Cloud Service uses a gossip protocol for efficient message propagation:
┌─────────────────────────────────────────────────────────────┐
│ Message Propagation │
│ │
│ ┌──────┐ │
│ │Source│ │
│ └──┬───┘ │
│ │ │
│ ┌─────┼─────┐ │
│ ▼ ▼ ▼ │
│ ┌───┐ ┌───┐ ┌───┐ │
│ │ A │ │ B │ │ C │ ← First wave (3 peers) │
│ └─┬─┘ └─┬─┘ └─┬─┘ │
│ │ │ │ │
│ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌───┐ ┌───┐ │
│ │ D │ │ E │ │ F │ │ G │ │ H │ ← Second wave │
│ └───┘ └───┘ └───┘ └───┘ └───┘ │
│ │
│ Each node forwards to random peers not yet seen │
└─────────────────────────────────────────────────────────────┘Peer Selection
Nodes maintain connections to different types of peers:
| Peer Type | Count | Purpose |
|---|---|---|
| Outbound | 8 | Default connections |
| Inbound | 117 | Accept incoming |
| Feeler | 1 | Discover new peers |
| AddrFetch | 1 | Address fetching |
Network Security
Sybil Resistance
- Proof of Work makes creating many identities expensive
- IP-based connection limits
- Ban score for misbehaving nodes
Eclipse Attack Prevention
- Connect to diverse peer groups
- DNS seed diversity
- Manual peer addition
DDoS Mitigation
| Mechanism | Description |
|---|---|
| Rate limiting | Limits messages per peer |
| Ban score | Penalizes misbehavior |
| Connection limits | Max connections per IP |
| Memory limits | Mempool and orphan limits |
Network Parameters
Mainnet
| Parameter | Value |
|---|---|
| Port | 26125 |
| Magic | 0xCSC0IN |
| DNS Seeds | seed.cscloudservice.com, seed2.cscloudservice.com |
| Genesis Block | 2026-01-01 00:00:00 |
| Protocol Version | 70015 |
Testnet
| Parameter | Value |
|---|---|
| Port | 26128 |
| Magic | 0xCSC0TST |
| DNS Seeds | seed-testnet.cscloudservice.com |
| Genesis Block | 2026-01-01 00:00:00 |
Bandwidth Requirements
| Node Type | Daily Upload | Daily Download |
|---|---|---|
| Full Node | 5-10 GB | 5-10 GB |
| Mining Node | 10-20 GB | 10-20 GB |
| Light Node | 100-500 MB | 100-500 MB |
Network Upgrades
Upgrade Process
- BIP Proposal — Technical specification
- Community Discussion — Feedback and refinement
- Implementation — Code development
- Testing — Testnet deployment
- Signaling — Miner signaling
- Activation — Mainnet activation
Soft Forks vs Hard Forks
| Type | Compatibility | Example |
|---|---|---|
| Soft Fork | Backward compatible | New consensus rules |
| Hard Fork | Not compatible | New chain rules |
Next Steps
- Consensus Mechanism — How consensus works
- Tokenomics — Token economics
- Security — Network security