Consensus Mechanism

Cloud Service uses a Proof of Work (PoW) consensus mechanism with the ZelHash algorithm (Modified Equihash 125,4), designed to be ASIC-resistant and GPU-friendly.

What is Consensus?

Consensus is the process by which all nodes in the network agree on the state of the blockchain. It ensures:

• All transactions are valid
• No double-spending occurs
• The blockchain is immutable
• New blocks are added securely

Proof of Work

How PoW Works

┌─────────────────────────────────────────────────────────────┐
│                    Proof of Work Process                     │
│                                                              │
│  1. Collect pending transactions from mempool               │
│         ↓                                                    │
│  2. Create block template with transactions                 │
│         ↓                                                    │
│  3. Add previous block hash and merkle root                 │
│         ↓                                                    │
│  4. Search for nonce that produces valid hash               │
│         ↓                                                    │
│  5. Found valid block → broadcast to network                │
│         ↓                                                    │
│  6. Other nodes validate and accept block                   │
│         ↓                                                    │
│  7. Miner receives reward                                   │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Mining Difficulty

The network adjusts difficulty to maintain a consistent 2-minute block time.

Difficulty Adjustment (LWMA3):

• Every block (Linear Weighted Moving Average v3)
• Based on the last 60 blocks
• Smoothly adapts to sudden hash rate changes

LWMA3 adjusts difficulty every block using a 60-block weighted average,
giving more weight to recent blocks to respond quickly to hash rate changes.

ZelHash Algorithm

Why ZelHash?

ZelHash (Modified Equihash 125,4) is designed to:

• Utilize GPU memory bandwidth
• Resist ASIC development via memory-hard computation
• Promote decentralized mining
• Be fair and accessible to GPU miners

Algorithm Details

Parameter	Value
Algorithm	ZelHash (Equihash 125,4)
Hash Function	Blake2b with "ZelProof" personalization
Equihash Parameters	n=125, k=4
Memory Required	~1.3 GB VRAM
Difficulty Adjustment	LWMA3 (every block, 60-block window)

How ZelHash Works

┌─────────────────────────────────────────────────────────────┐
│                    ZelHash Algorithm                         │
│                                                              │
│  Input: Block Header + Nonce                                │
│         ↓                                                    │
│  1. Initialize Blake2b with "ZelProof" personalization      │
│         ↓                                                    │
│  2. Generate Equihash puzzle (n=125, k=4)                   │
│         ↓                                                    │
│  3. GPU solves birthday problem in memory                   │
│         ↓                                                    │
│  4. Verify solution satisfies XOR constraint                │
│         ↓                                                    │
│  5. If hash meets target → Valid block found!               │
│     If not → Try next nonce                                 │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Consensus Rules

Block Validation

For a block to be valid, it must satisfy:

1. Block size ≤ Maximum block size
2. Transaction count > 0
3. First transaction is coinbase (mining reward)
4. All transactions are valid
5. Merkle root matches transactions
6. Timestamp > median of previous 11 blocks
7. Timestamp < 2 hours in the future
8. Proof of Work meets difficulty target
9. Block height is correct

Transaction Validation

For a transaction to be valid:

1. Syntax is correct
2. Inputs exist and are unspent
3. Signatures are valid
4. Output values ≤ Input values
5. No double-spending
6. Lock time conditions met

Chain Selection

Longest Chain Rule

When multiple valid chains exist, nodes follow the chain with the most cumulative work:

Chain A: 100 blocks (less work)
Chain B: 100 blocks (more work) ← Nodes follow this chain

Fork Handling

Temporary Forks:

Time T:    Block 100
              /    \
Time T+1: Block 101a  Block 101b
              |
Time T+2:  Block 102a  ← Longer chain wins

Resolution:

• Nodes switch to chain with most work
• Orphaned blocks are discarded
• Transactions return to mempool

Security Model

Economic Security

Mining secures the network through economic incentives:

• Cost: Electricity + Hardware
• Reward: Block reward + Transaction fees
• Attack Cost: Must exceed honest mining rewards

51% Attack

An attacker with >50% hash rate could:

• Reverse their own transactions
• Prevent transaction confirmation
• Prevent other miners from finding blocks

But cannot:

• Create coins out of thin air
• Steal others' coins
• Change block rewards

Attack Cost Estimation

Attack Cost per Hour = (Network Hash Rate × 0.51) × Electricity Cost

Example:
- Network Hash Rate: 10 TH/s
- Electricity: $0.10/kWh
- GPU Efficiency: 50 Sol/s/W

Attack requires ~102,000 GPUs
Hourly cost: ~$20,000+

Network Upgrades

Soft Fork

A backward-compatible change to consensus rules:

• Old nodes still validate new blocks
• New rules are stricter than old rules
• Example: New transaction types

Hard Fork

A non-backward-compatible change:

• All nodes must upgrade
• New rules are different from old rules
• Can result in chain split if not unanimous

Upgrade Activation

1. BIP9/Version Bits — Miner signaling
2. Threshold — 95% of blocks signal support
3. Lock-in — 2016 block period
4. Activation — New rules enforced

---

Next Steps

• Tokenomics — Token economics
• Security — Network security
• Network Architecture — Back to overview