ChainOS Architecture

Architecture Overview

ChainOS is built on a multi-layered architecture designed for high performance, security, and scalability. This document provides a comprehensive overview of the system's components and their interactions.

Architectural Layers

ChainOS implements a modular architecture with four primary layers:


┌───────────────────────────────────────────────────────────┐
│                    Application Layer                      │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐   │
│   │ Transaction │  │   Smart     │  │State Transition │   │
│   │  Execution  │  │  Contracts  │  │     Engine      │   │
│   └─────────────┘  └─────────────┘  └─────────────────┘   │
├───────────────────────────────────────────────────────────┤
│                    Consensus Layer                        │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐   │
│   │  Modified   │  │Probabilistic│  │ Byzantine Fault │   │
│   │  Tendermint │  │  Finality   │  │     Tolerance   │   │
│   └─────────────┘  └─────────────┘  └─────────────────┘   │
├───────────────────────────────────────────────────────────┤
│                    Networking Layer                       │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐   │
│   │  P2P Mesh   │  │  Libp2p     │  │  Gossip Protocol│   │
│   │  Network    │  │  Subsystem  │  │  Implementation │   │
│   └─────────────┘  └─────────────┘  └─────────────────┘   │
├───────────────────────────────────────────────────────────┤
│                    Persistence Layer                      │
│   ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐   │
│   │  LevelDB    │  │ Merkleized  │  │  IAVL+ Tree     │   │
│   │  Storage    │  │   State     │  │  Implementation │   │
│   └─────────────┘  └─────────────┘  └─────────────────┘   │
└───────────────────────────────────────────────────────────┘

Application Layer

The Application Layer is responsible for transaction execution, state transitions, and business logic:

Key Components

Transaction Execution Engine: Processes and validates transactions according to the protocol rules
Smart Contract VM: Executes deterministic smart contracts with sandboxed execution environment
State Transition Engine: Manages the application state and applies state transitions based on transaction results
Module System: Pluggable modules for specific functionality (staking, governance, etc.)

The Application Layer communicates with the Consensus Layer through the Application Blockchain Interface (ABI), which provides a standardized way for the consensus engine to deliver transactions to the application and receive results.

Consensus Layer

The Consensus Layer ensures that all nodes in the network agree on the state of the blockchain:

Key Components

Modified Tendermint BFT: ChainOS uses a modified version of Tendermint Byzantine Fault Tolerance consensus with optimizations for higher throughput
Validator Set Management: Manages the active set of validators based on stake and performance
Block Production: Coordinates the creation and validation of new blocks
Finality Gadget: Provides fast probabilistic finality (4.5 seconds) with eventual absolute finality

The consensus mechanism can tolerate up to 1/3 of validators being Byzantine (malicious or faulty) while still maintaining safety and liveness properties.

Consensus Optimizations

ChainOS has implemented several optimizations to the consensus layer that enable 2.37-second block times and up to 8,750 transactions per second:

Parallel transaction validation
Optimized signature verification with batch processing
Pipelined block production and propagation
Adaptive gossip protocol for efficient block distribution

Networking Layer

The Networking Layer facilitates communication between nodes in the network:

Key Components

P2P Mesh Network: Connects nodes in a resilient peer-to-peer topology
Libp2p Subsystem: Provides transport, discovery, and routing capabilities
Gossip Protocol: Efficiently propagates blocks, transactions, and consensus messages
Connection Management: Handles peer discovery, connection establishment, and maintenance

The networking layer includes optimizations for reducing latency and maximizing throughput, such as prioritized message queues, adaptive peer selection, and bandwidth management.

Persistence Layer

The Persistence Layer handles data storage and retrieval:

Key Components

LevelDB Storage: Fast key-value store for blockchain data
Merkleized State: Efficient state representation with cryptographic verification
IAVL+ Tree: Optimized Merkle tree implementation for state storage
Pruning System: Manages historical data retention and state pruning

The persistence layer is designed for high performance and data integrity, with optimizations for both read and write operations.

Node Types

ChainOS supports several types of nodes with different roles in the network:

Validator Nodes

Validator nodes participate in consensus by proposing and validating blocks:

Run the full ChainOS stack with all four layers
Stake UOS tokens as collateral
Earn rewards for block production and transaction validation
Require high reliability and performance

Full Nodes

Full nodes maintain a complete copy of the blockchain but do not participate in consensus:

Verify all transactions and blocks
Serve API requests from applications
Relay transactions and blocks to other nodes
Can be used as sentry nodes to protect validators

Archive Nodes

Archive nodes maintain the complete historical state of the blockchain:

Store all historical states without pruning
Support historical queries and data analysis
Require significantly more storage than full nodes
Useful for explorers, indexers, and analytics services

Light Clients

Light clients provide minimal functionality for resource-constrained environments:

Verify block headers and proofs without storing the full state
Trust full nodes for data retrieval
Suitable for mobile devices and IoT applications
Significantly lower resource requirements

Transaction Flow

The following diagram illustrates the flow of a transaction through the ChainOS architecture:

┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐
│  Client  │────▶│  Mempool │────▶│ Consensus│────▶│   Block  │────▶│  State   │
│          │     │          │     │  Engine  │     │ Producer │     │ Transition│
└─────────┘     └─────────┘     └─────────┘     └─────────┘     └─────────┘
     │                                                                 │
     │                                                                 │
     │                                                                 ▼
     │                                                           ┌─────────┐
     │                                                           │ Commit  │
     │                                                           │         │
     │                                                           └─────────┘
     │                                                                 │
     ▼                                                                 │
┌─────────┐                                                            │
│ Response│◀───────────────────────────────────────────────────────────┘
│         │
└─────────┘

Transaction Creation: A client creates and signs a transaction
Mempool Submission: The transaction is submitted to a node's mempool
Mempool Validation: Basic validation checks are performed
Consensus Processing: The consensus engine selects transactions for inclusion in a block
Block Production: A validator proposes a block containing the transaction
Block Validation: Other validators verify the block
State Transition: The transaction is executed, and state changes are applied
Commit: The new state is committed to the database
Response: The client receives confirmation of the transaction

Consensus Mechanism

ChainOS uses a modified Tendermint BFT consensus algorithm with several optimizations:

Consensus Rounds

Each block production cycle consists of several steps:

Propose: The designated proposer creates and broadcasts a block proposal
Prevote: Validators vote on whether the proposal is valid
Precommit: If 2/3+ of validators prevote for the same block, they precommit to it
Commit: If 2/3+ of validators precommit to the same block, it is committed

Consensus Performance

Block Time: 2.37 seconds average
Finality Time: 4.5 seconds
Transaction Throughput: Up to 8,750 TPS
Fault Tolerance: Can withstand up to 1/3 of validators being Byzantine

Validator Selection

ChainOS uses a Delegated Proof of Stake (DPoS) mechanism for validator selection:

The top 100 nodes by stake amount become active validators
Stake can come from the validator's own tokens or from delegations
Validators are incentivized to maintain high uptime and performance
Malicious or faulty validators can be slashed, losing a portion of their stake

State Management

ChainOS uses a sophisticated state management system to maintain the blockchain state:

State Structure

The state is organized as a Merkleized key-value store with the following properties:

Each state transition produces a new state root
The state root is included in each block header
State proofs can be generated to verify specific state entries
The state is organized into namespaces for different modules

State Pruning

To manage storage requirements, ChainOS implements several pruning strategies:

Default: Keeps recent states for fast access and pruning older states
Sync: Keeps only the most recent state, suitable for syncing nodes
Archive: Keeps all historical states, suitable for data analysis
Custom: Configurable pruning parameters for specific needs

Security Model

ChainOS implements a comprehensive security model to protect the network:

Cryptographic Primitives

Digital Signatures: Ed25519 for transaction and message authentication
Hash Functions: SHA-256 and BLAKE2b for data integrity
BLS Signatures: For efficient aggregate signature verification
Merkle Trees: For efficient state verification

Economic Security

Staking: Validators must stake UOS tokens as collateral
Slashing: Penalties for misbehavior (double signing, downtime)
Rewards: Incentives for honest participation
Delegation: Token holders can delegate to validators they trust

Scalability Approach

ChainOS addresses scalability through several approaches:

Horizontal Scaling

Optimized Consensus: Reduced communication overhead and faster block times
Parallel Transaction Processing: Multiple transactions processed simultaneously
Efficient State Management: Optimized data structures for state access
Network Optimizations: Efficient block propagation and peer selection

Future Scaling Solutions

The ChainOS roadmap includes several advanced scaling solutions:

Sharding: Partitioning the network into multiple shards for parallel processing
Layer 2 Solutions: Off-chain scaling solutions for specific use cases
State Channels: Private payment channels for high-frequency transactions
Optimistic Rollups: Batch processing of transactions with fraud proofs

Developer Resources

For more detailed information about the ChainOS architecture, check out these resources: