Skip to main content

Artha Chain Consensus Mechanism

This document provides technical documentation for the Artha Chain consensus mechanism, which comprises two key components:

  • Social Verified Consensus Protocol (SVCP) - For block proposer selection
  • Social Verified Byzantine Fault Tolerance (SVBFT) - For block finalization

Overview​

Artha Chain implements a novel consensus approach that moves beyond traditional Proof of Work (PoW) and Proof of Stake (PoS) by incorporating social verification and contribution metrics into the consensus process. This multi-dimensional approach enhances security, promotes equitable participation, and improves resource efficiency.

┌─────────────────────────────────────────────────────────────────┐
│                       Transaction Flow                           │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Mempool Management                          │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│ SVCP: Social Verified Consensus Protocol                         │
│                                                                  │
│ ┌─────────────────┐   ┌───────────────────┐   ┌───────────────┐ │
│ │ Score Calculation│──▶│ Proposer Selection │──▶│Block Creation │ │
│ └─────────────────┘   └───────────────────┘   └───────────────┘ │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│ SVBFT: Social Verified Byzantine Fault Tolerance                 │
│                                                                  │
│ ┌─────────────────┐   ┌───────────────────┐   ┌───────────────┐ │
│ │  Prepare Phase   │──▶│   Commit Phase    │──▶│  Finalization  │ │
│ └─────────────────┘   └───────────────────┘   └───────────────┘ │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                        Block Inclusion                           │
└─────────────────────────────────────────────────────────────────┘

1. Social Verified Consensus Protocol (SVCP)​

SVCP is responsible for selecting block proposers based on their contributions to the network and creating candidate blocks.

1.1 Configuration Parameters​

The SVCP component uses several key configuration parameters that can be adjusted to tune the consensus behavior:

struct SVCPConfig {
    // Minimum score required to participate in consensus
    min_score_threshold: f32,            // Default: 0.6
    // Maximum number of proposer candidates
    max_proposer_candidates: usize,      // Default: 100
    // Minimum number of proposer candidates
    min_proposer_candidates: usize,      // Default: 10
    // Target block time in seconds
    target_block_time: u64,              // Default: 15
    // Difficulty adjustment window (in blocks)
    difficulty_adjustment_window: u64,    // Default: 10
    // Initial POW difficulty
    initial_pow_difficulty: u64,         // Default: 4
    // Weight for device score in candidate selection
    device_weight: f32,                  // Default: 0.2
    // Weight for network score in candidate selection
    network_weight: f32,                 // Default: 0.3
    // Weight for storage score in candidate selection
    storage_weight: f32,                 // Default: 0.1
    // Weight for engagement score in candidate selection
    engagement_weight: f32,              // Default: 0.2
    // Weight for AI behavior score in candidate selection
    ai_behavior_weight: f32,             // Default: 0.2
    // Base batch size for transactions per block
    base_batch_size: usize,              // Default: 10
}

1.2 Node Scoring​

Node scores are calculated across multiple dimensions, producing a NodeScore structure with the following components:

struct NodeScore {
    // Overall node score (0.0-1.0)
    overall_score: f32,
    // Device health score (CPU, memory, disk)
    device_health_score: f32,
    // Network connectivity score
    network_score: f32,
    // Storage contribution score
    storage_score: f32,
    // Governance/community engagement score
    engagement_score: f32,
    // AI behavior trust score
    ai_behavior_score: f32,
    // Last updated timestamp
    last_updated: SystemTime,
}

Each component is normalized to a 0.0-1.0 range and contributes to the overall score based on the configured weights.

1.3 Proposer Selection​

Block proposers are selected from a pool of candidates using a combination of their scores and time since last block proposal:

  1. Candidate Qualification: Nodes with overall scores above min_score_threshold are considered as candidates.

  2. Weighted Score Calculation: Each candidate's score is calculated as:

    weighted_score = device_score * device_weight +
                    network_score * network_weight +
                    storage_score * storage_weight +
                    engagement_score * engagement_weight +
                    ai_behavior_score * ai_behavior_weight

  3. Time-Weighted Selection: To prevent high-scoring nodes from dominating block production, selection also considers time since last proposal. The selection formula sorts candidates first by last proposal time (older is better) and then by weighted score.

  4. Selection Process: The implementation uses a BinaryHeap to efficiently maintain the ordering of candidates.

  5. Proposer Updates: The proposer set is periodically updated (default is every 5 minutes) to reflect changes in node scores.

1.4 Block Production​

Once selected as a proposer, a node follows these steps to produce a block:

  1. Transaction Selection: Select transactions from the mempool based on gas price, priority, and validity.

  2. Block Assembly: Create a new block with the selected transactions, setting appropriate header values.

  3. Block Verification: Perform initial validation to ensure the block is well-formed.

  4. Block Submission: Submit the block to the SVBFT layer for consensus.

1.5 Difficulty Adjustment​

SVCP includes a difficulty adjustment mechanism to maintain target block times:

  1. Block Time Tracking: The system maintains a window of recent block times.

  2. Adjustment Calculation: If the average block time deviates from the target, the difficulty is adjusted accordingly:

    if avg_time > target_time {
        // Block time too long, decrease difficulty
        new_difficulty = current_difficulty.saturating_sub(1);
    } else if avg_time < target_time * 0.8 {
        // Block time too short, increase difficulty
        new_difficulty = current_difficulty + 1;
    }

  3. Bounded Changes: Changes are limited to prevent extreme difficulty swings.

1.6 Performance Scaling​

SVCP includes mechanisms for scaling performance with network growth:

  1. Parallel Processing: The ParallelProcessor component enables parallel transaction execution.

  2. TPS Scaling: Transaction throughput scales with the number of validators:

    let batch_size = self.svcp_config.base_batch_size * validator_count;

  3. Adaptive Parameters: Several parameters automatically adjust based on network conditions.

2. Social Verified Byzantine Fault Tolerance (SVBFT)​

SVBFT provides the consensus mechanism for finalizing blocks proposed by SVCP.

2.1 Protocol Phases​

The SVBFT consensus process consists of multiple phases:

  1. Prepare Phase: Validators indicate their initial assessment of a block proposal.

    Validator → Network: Prepare(blockHash, validatorID, signature)

  2. Commit Phase: After seeing sufficient prepare messages (≥ 2/3 of voting power), validators commit to the block.

    Validator → Network: Commit(blockHash, validatorID, signature)

  3. Finalize Phase: Once sufficient commit messages are received (≥ 2/3 of voting power), the block is finalized.

    Validator → Network: Finalize(blockHash, validatorID, signature)

2.2 Validator Committees​

SVBFT organizes validators into committees for efficient operation:

  1. Committee Formation: Validators are assigned to committees based on a combination of stake, reputation, and randomness.

  2. Committee Size: Committee sizes typically range from 50-200 validators depending on network conditions.

  3. Rotation Schedule: Committee membership rotates periodically (every 2-4 weeks) to prevent collusion.

2.3 Byzantine Fault Tolerance​

SVBFT maintains security under Byzantine conditions:

  1. Fault Tolerance Threshold: The system remains secure as long as less than 1/3 of validator voting power is malicious.

  2. Safety Property: Honest validators will never agree on different blocks at the same height.

  3. Liveness Property: The system continues to make progress as long as more than 2/3 of validators are honest and active.

2.4 View Change Mechanism​

SVBFT includes a view change mechanism to handle cases where the block proposer fails:

  1. Timeout Detection: Validators start a timeout timer when expecting a proposal.

  2. View Change Initiation: Upon timeout, validators broadcast view change messages.

  3. View Change Quorum: When sufficient view change messages are received (≥ 2/3 of voting power), the next validator in the rotation becomes the proposer.

2.5 Reputation Integration​

SVBFT integrates reputation in several ways:

  1. Voting Weight: Validator voting weight is determined by a combination of stake and reputation.

  2. Committee Assignment: Higher-reputation validators may be assigned to more critical committees.

  3. Reward Distribution: Consensus rewards are adjusted based on validator reputation.

3. Mobile-Optimized Consensus​

Artha Chain's consensus mechanism is specially optimized for mobile devices, allowing smartphones and tablets to participate as full validators:

3.1 Mobile-Optimized SVBFT​

The SVBFT protocol includes several optimizations for mobile devices:

  1. Reduced Message Size: Compact message format to minimize bandwidth usage
  2. Battery-Aware Participation: Intelligent scheduling that considers device battery level
  3. Background Processing: Efficient background consensus processing
  4. Intermittent Connectivity Handling: Ability to recover from temporary network disconnections
  5. HotStuff-Based Protocol: Linear communication complexity to reduce network overhead

3.2 Lightweight Verification​

Mobile nodes can participate in consensus with minimal resource requirements:

  1. Partial State Verification: Only verify state relevant to the validator's committee
  2. Incremental Block Processing: Process blocks in small chunks to avoid memory pressure
  3. Configurable Resource Limits: Set maximum CPU, memory, and bandwidth usage
  4. Mobile-Specific Optimizations: ARM-optimized cryptographic operations

4. Objective Sharding​

Artha Chain implements Objective Sharding to scale throughput as more validators join the network:

4.1 Dynamic Shard Management​

  1. Auto Shard Resizing: Shards automatically grow or shrink as validators join or leave
  2. Performance-Based Scaling: New shards are created when transaction load approaches capacity
  3. Optimal Shard Size: Each shard maintains 50-200 validators for optimal performance

4.2 Cross-Shard Transactions​

  1. Coordinator Selection: For each cross-shard transaction, one shard acts as coordinator
  2. Two-Phase Commit Protocol: Ensures atomicity across shards
  3. Minimized Cross-Shard Communication: Transaction routing algorithm minimizes cross-shard operations
  4. Parallel Processing: Independent cross-shard transactions are processed in parallel

4.3 Mobile-Optimized Shard Assignment​

  1. Device Capability Awareness: Mobile devices are assigned to shards based on their capabilities
  2. Proximity-Based Assignment: Devices are assigned to shards with low network latency
  3. Battery-Aware Rotation: Mobile devices can rotate between active and standby roles based on battery level

4.4 Shard Security​

  1. Random Validator Assignment: Validators are randomly assigned to shards to prevent attacks
  2. Cross-Shard Verification: Transactions affecting multiple shards are verified by all involved shards
  3. Reshuffling: Periodic reshuffling of validators between shards for enhanced security

5. Integration Between SVCP and SVBFT​

The two consensus components work together in the following manner:

  1. Block Proposal: SVCP selects proposers and generates block proposals.

  2. Consensus Building: SVBFT builds consensus on block validity and finality.

  3. Feedback Loop: SVBFT results feed back into SVCP score updates:

    • Successful block proposals increase reputation
    • Failed proposals or malicious behavior decreases reputation

  4. Dynamic Adjustment: Both components adapt to network conditions and validator behavior.

6. Security Properties​

The combined SVCP+SVBFT consensus mechanism provides several key security properties:

  1. Multi-dimensional Security: Security derives from a combination of stake, reputation, and social verification.

  2. Sybil Resistance: Multiple verification dimensions make identity multiplication attacks prohibitively expensive.

  3. Economic Security: Alignment of economic incentives with secure, honest behavior.

  4. Adaptive Security: Security parameters adjust based on network threat levels.

  5. Social Verification Layer: Additional security through reputation and social graph analysis.

7. Implementation Notes​

7.1 Key Data Structures​

// Block proposal
struct Block {
    header: BlockHeader,
    transactions: Vec<Transaction>,
    // Consensus-specific data
    consensus: ConsensusData,
}

// Consensus metadata
struct ConsensusData {
    // Current consensus status
    status: ConsensusStatus,
    // Validator votes
    votes: Vec<Vote>,
    // View change information (if applicable)
    view_changes: Vec<ViewChange>,
}

// Vote from a validator
struct Vote {
    // Validator ID
    validator_id: String,
    // Vote type (Prepare, Commit, Finalize)
    vote_type: VoteType,
    // Signature
    signature: Signature,
}

7.2 State Management​

The consensus mechanism maintains several key state components:

  1. Blockchain State: The current state of the blockchain, including block history.

  2. Validator Set: The current set of validators and their properties.

  3. Node Scores: Reputation and contribution scores for all nodes.

  4. Proposer Candidates: The current set of eligible block proposers.

  5. Block Times: Recent block creation times for difficulty adjustment.

7.3 Performance Characteristics​

The consensus mechanism achieves the following performance characteristics:

  1. Throughput:

    • Small transactions (100 bytes): Up to 22,680,000 TPS
    • Medium transactions (1KB): Up to 4,694,000 TPS
    • Large transactions (10KB): Up to 608,000 TPS
    • Cross-shard consensus: 731.5 nanoseconds per operation

  2. Latency:

    • Time to finality: 2-3 seconds under normal conditions
    • Cross-shard transactions: 4-6 seconds

  3. Resource Efficiency:

    • Minimal energy usage compared to Proof of Work
    • Optimized message patterns to reduce network overhead

8. Configuration and Tuning​

8.1 Important Configuration Options​

The following parameters can be adjusted to tune consensus behavior:

  1. SVCP Parameters:

    • target_block_time: Target time between blocks (seconds)
    • min_score_threshold: Minimum score for consensus participation
    • Various weights for different score components

  2. SVBFT Parameters:

    • committee_size: Number of validators in each committee
    • rotation_frequency: How often committee membership rotates
    • timeout_period: Timeout for view change initiation

Development Environment​

target_block_time: 5
min_score_threshold: 0.4
committee_size: 10

Testnet Environment​

target_block_time: 10
min_score_threshold: 0.6
committee_size: 50

Production Environment​

target_block_time: 15
min_score_threshold: 0.7
committee_size: 100

9. Troubleshooting​

9.1 Common Issues​

  1. Low Proposer Count: If there are too few proposer candidates:

    • Check the min_score_threshold (may be too high)
    • Verify node score calculations
    • Ensure enough validators are registered

  2. Block Time Variability: If block times are inconsistent:

    • Review the difficulty adjustment algorithm
    • Check for network delays
    • Monitor validator performance

  3. Consensus Stalls: If consensus appears to stall:

    • Check for view change conditions
    • Verify validator connectivity
    • Ensure sufficient validator participation

9.2 Diagnostic Tools​

The system provides several tools for diagnosing consensus issues:

  1. Consensus Metrics: Real-time metrics on consensus performance
  2. Validator Status: Status of all validator nodes
  3. Proposer Analytics: Analysis of proposer selection patterns
  4. Score Breakdown: Detailed breakdown of node scores

10. Future Development​

The consensus mechanism is actively being developed with several planned enhancements:

  1. Formal Verification: Mathematical proofs of protocol security properties
  2. Advanced Cryptography: Integration of post-quantum cryptography
  3. Zero-Knowledge Integration: Enhanced use of zero-knowledge proofs
  4. Cross-Chain Consensus: Extended consensus mechanisms for cross-chain operations
  5. AI-Enhanced Security: Further integration of AI for anomaly detection

This documentation is maintained by the Artha Chain Core Development Team.