Cortensor
  • Home
  • Abstract
    • Value Proposition
    • Whitepaper
      • Page 1: Introduction and Vision
      • Page 2: Architecture and Technical Overview
      • Page 3: Incentive Structure and Tokenomics
      • Page4: Development Roadmap and Phases
      • Page5: Summary
  • Introduction
    • What is Cortensor?
    • Key Features & Benefits
    • Vision & Mission
    • Team
  • Getting Started
    • Quick Start Guide
    • System Requirements
    • Installation & Setup
      • Getting Test ETH
      • Setup Own RPC Endpoint
      • Router Node Setup
        • Router API Reference
  • Core Concepts
    • Decentralized AI Inference
      • Community-Powered Network
      • Gamification and Quality Control
      • Incentive Structure
    • Universal AI Accessibility
    • Multi-layer Blockchain Architecture
  • Technical Architecture
    • Design Principles
    • Node Roles
    • Node Lifecycle
      • Ephemeral Node State
    • Node Reputation
    • Network & Flow
    • Type of Services
    • Coordination & Orchestration
      • Multi-Oracle Node Reliability & Leadership Rotation
    • AI Inference
      • Open Source Models
        • Centralized vs Decentralized Models
      • Quantization
      • Performance and Scalability
    • Consensus & Validation
      • Proof of Inference (PoI) & Proof of Useful Work (PoUW
      • aka Mining
      • Proof of Useful Work (PoUW)
      • Proof of Useful Work (PoUW) State Machine
        • Miner & Oracle Nodes in PoUW State Machine
      • Sampling in Large Distributed Systems
      • Parallel Processing
      • Embedding Vector Distance
    • Multi-Layered Blockchain Architecture
    • Modular Architecture and Smart Contract Interactions
      • Session Queue
      • Node Pool
      • Session Payment
    • Mining Overview
    • User Interaction & Node Communication
      • Session, Session Queue, Router, and Miner in Cortensor
    • Data Management
      • IPFS Integration
    • Security & Privacy
    • Dashboard
    • Development Previews
      • Multiple Miners Collaboration with Oracle Node
      • Web3 SDK Client & Session/Session Queue Interaction
    • Technical Threads
      • AI Agents and Cortensor's Decentralized AI Inference
    • Infographic Archive
  • Community & Ecosystem
    • Tokenomics
      • Network Incentive Allocation
      • Token Allocations & Safe Wallet Management
    • Staking Pool Overview
    • Contributing to Cortensor
    • Incentives & Reward System
    • Governance & Compliance
    • Safety Measures and Restricted Addresses
    • Buyback Program
    • Liquidity Additions
    • Partnerships
      • Partnership Offering for Demand-Side Partnerships
    • Community Testing
      • Closed Alpha Testing Phase #1
        • Closed Alpha Testing Phase #1 Contest: Closing & Winners Announcement
      • Closed Alpha Testing Phase #2
      • Closed Alpha Testing Phase #3
      • Discord Roles & Mainnet Privileges
      • DevNet Mapping
      • DevNet Modules & Parameters
    • Jobs
      • Technical Writer
      • Communication & Social Media Manager
      • Web3 Frontend Developer
      • Distributed Systems Engineer
  • Integration Guide
    • Web2
      • REST API
      • WebSocket
      • Client SDK
    • Web3
      • Web3 SDK
  • Use Cases
  • Roadmap
    • Technical Roadmap: Launch to Next 365 Days Breakdown
    • Long-term Vision: Beyond Inference
  • Glossary
  • Legal
    • Terms of Use
    • Privacy Policy
    • Disclaimer
    • Agreement for Sale of Tokens
Powered by GitBook
On this page
  • Factors to Consider
  • Example Calculation
  • Practical Considerations
  • Implementation Strategy
  • Conclusion
  1. Technical Architecture
  2. Consensus & Validation

Sampling in Large Distributed Systems

PreviousMiner & Oracle Nodes in PoUW State MachineNextParallel Processing

Last updated 9 months ago

As we scale Cortensor’s decentralized AI inference network, ensuring the health and quality of the system becomes paramount. A critical aspect of this is the sampling process for Proof of Work (PoW), Proof of Inference (PoI), and Proof of Useful Work (PoUW). To maintain scalability and quality of supply across a large distributed network, it’s essential to determine an effective sample rate. Here’s how we are thinking about this process:

Factors to Consider

  • Total Number of Nodes: The total number of active nodes (miners) in the system.

  • Desired Confidence Level: The statistical confidence level needed to ensure network health and reliability.

  • Node Variability: The expected variability in node behavior and performance, which can impact the network's overall health.

  • Operational Constraints: Network and computational limitations for sampling, processing, and reporting results.

Example Calculation

Let’s assume the following for our sampling approach:

  • Total number of nodes: 1,000,000

  • Desired confidence level: 95%

  • Confidence interval (margin of error): ±1%

  • Expected variability: 50% (most conservative estimate)

Using these assumptions, we apply the sample size formula for a proportion:

n=Z2⋅p⋅(1−p)e2n = \frac{Z^2 \cdot p \cdot (1 - p)}{e^2} n=e2Z2⋅p⋅(1−p)​

Where:

  • ( n ) = required sample size

  • ( Z ) = Z-value (1.96 for 95% confidence level)

  • ( p ) = estimated proportion (0.5 for maximum variability)

  • ( e ) = margin of error (0.01 for ±1%)

Substituting the values:

So, approximately 9,604 nodes need to be sampled daily to achieve a 95% confidence level with a ±1% margin of error.

Practical Considerations

  • Sampling Rate: Given the need to sample 9,604 nodes per day from a pool of 1,000,000, the daily sampling rate would be approximately 0.96% of the total nodes.

  • Sampling Interval: To evenly distribute the sampling load over 24 hours, we would sample approximately 400 nodes per hour (9,604 nodes / 24 hours).

  • Batch Processing: For operational efficiency, hourly sampling can be broken down into smaller batches (e.g., 100 nodes every 15 minutes), distributing the computational load.

Implementation Strategy

  • Dynamic Sampling: Implement a dynamic sampling approach where the sample size adjusts based on real-time data and system conditions. This allows for more flexible and responsive monitoring of network health.

  • Round-Robin Selection: Use a round-robin selection mechanism to ensure that all nodes are sampled over time, promoting fairness and comprehensive coverage.

  • Health Metrics: Establish clear health metrics and thresholds for nodes based on the sampled data to ensure that only healthy and reliable nodes continue participating in the network.

  • Automated Alerts: Set up automated alerts for nodes that fall below the health thresholds, triggering immediate remedial actions to maintain network integrity.

Conclusion

This structured approach to sampling in Cortensor’s PoW - PoI, and PoUW processes is designed to balance scalability with the quality of supply in a large distributed system. By carefully selecting a sample size and implementing dynamic, real-time adjustments, we can ensure that the network remains healthy and reliable as it scales. The ongoing monitoring and adaptive strategies will play a crucial role in maintaining the high standards of performance and security expected in Cortensor’s decentralized AI network.

n=1.962⋅0.5⋅(1−0.5)0.012n = \frac{1.96^2 \cdot 0.5 \cdot (1 - 0.5)}{0.01^2} n=0.0121.962⋅0.5⋅(1−0.5)​
n=3.8416⋅0.250.0001=0.96040.0001=9604n = \frac{3.8416 \cdot 0.25}{0.0001} = \frac{0.9604}{0.0001} = 9604n=0.00013.8416⋅0.25​=0.00010.9604​=9604