Cubiq Network Architecture

High-Level Architecture

Cubiq's architecture consists of three primary layers that work together to enable mobile-native blockchain participation while maintaining security and decentralization.

Design Principles

Cubiq is guided by five core principles that shape every architectural decision:

Key Components

Qubes (Mobile Nodes)

Qubes are lightweight mobile nodes that form the backbone of Cubiq's decentralized network. Each Qube performs several critical functions:

• Proof Verification: Validates zero-knowledge proofs using optimized WASM verifiers
• Block Propagation: Participates in gossip-based block distribution
• Consensus Voting: Votes on block validity through DPoS mechanism
• Staking: Stakes QUBE tokens to participate in consensus

Cloud Prover Network

The Cloud Prover Network handles computationally intensive zero-knowledge proof generation:

• Plonky3 Integration: Uses recursive STARK proofs for efficient verification
• Horizontal Scaling: Multiple provers can work in parallel
• Geographic Distribution: Provers deployed globally for low latency
• Proof Bundling: Aggregates multiple transactions into single proofs

Execution Layer

The execution layer provides full EVM compatibility while being optimized for zero-knowledge proof generation:

zkEVM Implementation

• Solidity Compatible: Supports Solidity 0.8.x with standard EVM opcodes
• ZK-Optimized: Opcodes restricted to those efficiently provable in Plonky3
• State Management: Uses sparse Merkle trees for efficient state proofs
• Gas Model: Modified gas pricing to account for proof generation costs

Smart Contract Execution

Smart contracts on Cubiq execute in a modified EVM environment:

// Example: ZK-compatible smart contract
pragma solidity ^0.8.19;

contract CubiqVoting {
    mapping(address => bool) public hasVoted;
    mapping(uint256 => uint256) public votes;
    
    // ZK-friendly: simple state transitions
    function vote(uint256 proposalId, bool support) external {
        require(!hasVoted[msg.sender], "Already voted");
        
        hasVoted[msg.sender] = true;
        votes[proposalId] += support ? 1 : 0;
        
        emit VoteCast(msg.sender, proposalId, support);
    }
    
    event VoteCast(address voter, uint256 proposalId, bool support);
}

Proving Layer

The proving layer is responsible for generating zero-knowledge proofs that validate state transitions:

Plonky3 Architecture

• Recursive Proofs: Enables proof composition and aggregation
• Fast Verification: Optimized for mobile device constraints
• Small Proof Size: Typically under 2MB per block
• Parallel Generation: Multiple proofs can be generated simultaneously

Proof Generation Workflow

1. Block Proposal: Qube proposes a new block with transactions
2. Execution Trace: Cloud prover simulates all transactions
3. Circuit Generation: Execution trace is encoded into Plonky3 circuits
4. Proof Creation: Zero-knowledge proof is generated
5. zkURL Publication: Proof is published via zkURL protocol

Consensus Layer

Cubiq uses a lightweight Delegated Proof of Stake (DPoS) consensus optimized for mobile participation:

DPoS Mechanics

zkURL Protocol Design

The zkURL protocol is Cubiq's innovation for decentralized proof distribution:

Protocol Format

zk://[proverID]@[domain_or_hash]/[proof_id]#[metadata]

Example:

zk://prover01@prover.cubiq.org/block/8472934#v1

Security Features

• Cryptographic Signatures: All proofs signed by registered provers
• Content Addressing: Proofs identified by cryptographic hashes
• Replay Protection: Timestamps and nonces prevent replay attacks
• Fallback Mechanisms: Multiple sources ensure availability

Proof Lifecycle

Understanding how proofs flow through the system:

Prover Network Architecture

The Cloud Prover Network is designed for scalability, reliability, and decentralization:

Infrastructure Components

Scalability Considerations

Cubiq's architecture is designed to scale to billions of mobile participants:

Horizontal Scaling

• Prover Parallelization: Multiple provers can work on different blocks simultaneously
• Geographic Distribution: Provers deployed in multiple regions for low latency
• Load Balancing: zkURL requests distributed across multiple endpoints
• Caching Layers: CDN and edge caching for proof distribution

Performance Metrics