System Components and Interactions
💜 Support the DIG Network
Help build the future of decentralized storage! The DIG Network is an open-source project that needs community support to continue development.
💜 Support the Project → - Donate crypto, buy NFTs, or sponsor development
This section details the technical interactions between DIG Network components, providing implementation-level understanding of how data flows through the system.
Component Interaction Flows
Content Creation and Publishing
The publishing flow transforms raw content into cryptographically-secured, network-distributed data:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ Content Creation and Publishing │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. DATASTORE CREATION │
│ ┌──────────────────────────────────────── ─────────────────────────────────┐ │
│ │ Raw Content → Capsule Fragmentation → Merkle Tree Generation → NFT Minting │ │
│ │ • Fragment into ~16MB capsules • Generate content hash │ │
│ │ • Build Merkle tree structure • Create DataStore NFT │ │
│ │ • Embed metadata and proofs • Publish to Chia blockchain │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 2. ECONOMIC COMMITMENTS (Required for Network Propagation) │
│ ┌───────────────────────────────────────────────────────────────────────── ┐ │
│ │ A. HANDLE REGISTRATION → Value Signaling │ │
│ │ • Choose Handle → Calculate Cost → Pay DIG Tokens → Register On-Chain │ │
│ │ • 3-char: 5000 DIG • 4-char: 1000 DIG • 5-char: 200 DIG │ │
│ │ • 6-char: 40 DIG • 7-char: 8 DIG • 8+char: 1 DIG │ │
│ │ │ │
│ │ B. CAPSULESTAKECOIN CREATION → Per-Capsule Collateral │ │
│ │ • Lock DIG tokens proportional to capsule size │ │
│ │ • 256KB: 64 DIG • 1MB: 256 DIG • 10MB: 1024 DIG │ │
│ │ • 100MB: 4096 DIG • 1000MB: 16384 DIG │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 3. NETWORK DISCOVERY AND PROPAGATION │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Push to DIG Node → Plot Generation → PlotCoin Creation → P2P Broadcast │ │
│ │ • HTTP push to initial node • Node generates plot file │ │
│ │ • Create cryptographic proofs • Register PlotCoin on-chain │ │
│ │ • Announce via P2P protocol • Economic incentives drive spread │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
└────────── ───────────────────────────────────────────────────────────────────────┘
Technical Details
Capsule Fragmentation Algorithm:
- Content split into ~16MB chunks for optimal network distribution
- Each capsule receives unique identifier from content hash
- Merkle tree enables efficient integrity verification
- Capsule boundaries align with content structure when possible
Handle Registration Mechanics:
- Handle cost creates tiered reward system
- Registration transaction includes DataStore reference
- On-chain registry prevents duplicate handles
- Cost determines epoch reward multiplier
Storage Provider Operations
Storage providers execute a complex optimization loop to maximize rewards:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ Storage Provider Operations │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. CONTENT DISCOVERY LOOP │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Monitor Sources → Calculate Profitability → Select Content → Store │ │
│ │ │ │
│ │ Sources: Profitability Factors: │ │
│ │ • Handle registrations • Handle tier (3-char = 5x rewards) │ │
│ │ • CapsuleStakeCoin publications• Capsule size (1000MB = 3x rewards) │ │
│ │ • P2P announcements • CapsuleStakeCoin collateral amount │ │
│ │ • Direct content pushes • Current provider count │ │
│ │ • Storage cost vs reward │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 2. PLOT GENERATION PROCESS │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Capsule Collection → Plot Creation → Proof Generation → PlotCoin Minting│ │
│ │ │ │
│ │ Plot Creation: Proof Generation: │ │
│ │ • 7-table format structure • Plot ownership proof │ │
│ │ • Embed proof-of-work • Data inclusion proof │ │
│ │ • Optimize for read speed • Computational work proof │ │
│ │ • Physical access proof │ │
│ └─────────────────────────────────────────────────────────────────── ──────┘ │
│ │ │
│ ▼ │
│ 3. ECONOMIC PARTICIPATION │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Stake DIG Tokens → Register PlotCoin → Serve Content → Claim Rewards │ │
│ │ │ │
│ │ Staking Requirements: Reward Distribution: │ │
│ │ • Minimum stake per plot • Random capsule selection │ │
│ │ • Locked during participation • Proof verification │ │
│ │ • Slashable for misbehavior • Proportional to tier │ │
│ │ • Withdrawal cooldown period • Performance multipliers │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────┘
Optimization Strategies
Portfolio Management:
- Continuous profitability analysis
- Dynamic content rotation based on rewards
- Geographic distribution for performance
- Risk diversification across content tiers
Technical Optimizations:
- Parallel plot generation pipelines
- Efficient proof caching mechanisms
- P2P connection pooling
- Bandwidth allocation algorithms
Validation and Reward Flow
The validation process ensures network integrity while distributing rewards fairly:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ Validation and Reward Distribution │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. DETERMINISTIC SELECTION │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Block Hash → VRF → Capsule Selection → Provider Identification │ │
│ │ │ │
│ │ Selection Algorithm: Provider Discovery: │ │
│ │ • Latest Chia block hash • Query PlotCoin registry │ │
│ │ • Verifiable random function • Filter active providers │ │
│ │ • Deterministic capsule ID • Check stake status │ │
│ │ • Unpredictable selection • Verify network presence │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 2. CRYPTOGRAPHIC VERIFICATION │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Request Proofs → Verify Each Type → Test Liveness → Record Results │ │
│ │ │ │
│ │ Verification Steps: Liveness Testing: │ │
│ │ • Validate digital signatures • Request specific capsule │ │
│ │ • Check Merkle paths • Verify response time │ │
│ │ • Verify PoW binding • Check data integrity │ │
│ │ • Confirm data possession • Test bandwidth capacity │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 3. REWARD CALCULATION │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ Determine Tier → Count Providers → Calculate Share → Distribute Tokens │ │
│ │ │ │
│ │ Reward Formula: Distribution: │ │
│ │ • Base = tier_multiplier • Escrow release │ │
│ │ • Share = base / provider_count • Performance bonus │ │
│ │ • Bonus = uptime * speed • Automatic claiming │ │
│ │ • Total = share + bonus • Compound staking option │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────┘
Validation Parameters
Selection Frequency:
- Validators perform selections every N blocks
- Frequency tunable based on network load
- Higher-tier content validated more frequently
- Random timing prevents gaming
Verification Thresholds:
- Proof verification must complete within timeout
- Liveness test requires sub-second response
- Failed verifications trigger re-selection
- Persistent failures result in penalties
P2P Protocol
Capsule Announcement Message:
{
"type": "CAPSULE_ANNOUNCE",
"capsule_id": "0x...",
"datastore_id": "0x...",
"handle_tier": 3,
"timestamp": 1234567890,
"provider_count": 5
}
Content Request Protocol:
{
"type": "CONTENT_REQUEST",
"capsule_ids": ["0x...", "0x..."],
"max_providers": 10,
"geo_preference": "US-WEST"
}
Blockchain Interfaces
PlotCoin Structure:
{
"plot_id": "0x...",
"provider_address": "xch1...",
"stake_amount": 1000,
"capsule_filter": "0x...",
"proof_package": "0x...",
"timestamp": 1234567890
}
Handle Registration:
{
"handle": "myproject",
"datastore_id": "0x...",
"tier": 3,
"payment": 5000,
"owner": "xch1..."
}
Performance Considerations
Optimization Techniques
Caching Strategies:
- Proof caching reduces computation overhead
- Capsule index caching accelerates lookups
- P2P peer caching improves discovery
- Handle registry caching minimizes queries
Parallel Processing:
- Concurrent plot generation pipelines
- Parallel proof verification
- Asynchronous P2P operations
- Batch blockchain transactions
Scalability Measures
Horizontal Scaling:
- Multiple DIG Nodes per operator
- Geographic distribution of nodes
- Load balancing across providers
- Redundant validation infrastructure
Efficiency Improvements:
- Bloom filters for capsule discovery
- Compressed proof formats
- Delta synchronization protocols
- Optimized network routing
Component Dependencies
External Dependencies
- Chia Blockchain: Transaction processing and consensus
- IPFS (optional): Alternative capsule storage backend
- PostgreSQL: Local indexing and caching
- Redis: High-performance caching layer
Internal Dependencies
- Plot Generator: Creates cryptographic storage proofs
- Proof Verifier: Validates storage commitments
- P2P Network Stack: Enables peer communication
- Economic Calculator: Determines reward distributions
Related Documentation
- Network Participants - Detailed roles and responsibilities
- Content Propagation - Distribution mechanisms
- Technical Specifications - Low-level implementation details
- DIG Node API - Complete API documentation