System Overview

Three-Layer Architecture

Frontier Chain's architecture separates concerns into three distinct layers, each optimized for its specific role:

┌─────────────────────────────────────────────────────────────────┐
│                      API LAYER                                  │
│                                                                 │
│  • REST API Server (HTTP/WebSocket)                            │
│  • Order submission and validation                             │
│  • Market data distribution                                    │
│  • Account management                                          │
│                                                                 │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────┴────────────────────────────────────────┐
│                     CORE LAYER                                  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │   HotStuff BFT Consensus (100ms rounds)                  │  │
│  │   • Leader rotation                                      │  │
│  │   • Byzantine fault tolerance (1/3 malicious nodes)      │  │
│  │   • Deterministic finality                               │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │   Frontier-Core Matching Engine (369K ops/sec)           │  │
│  │   • Multi-pair order books (spot & perpetuals)           │  │
│  │   • Parallel signature verification                      │  │
│  │   • Deterministic execution                              │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │   Order Gossip Protocol                                  │  │
│  │   • Pre-consensus order distribution                     │  │
│  │   • 30ms minimum age requirement                         │  │
│  │   • Mempool synchronization                              │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                 │
└────────────────────────┬────────────────────────────────────────┘
                         │
┌────────────────────────┴────────────────────────────────────────┐
│                   STORAGE LAYER                                 │
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌────────────────────┐   │
│  │   Memory     │→ │   RocksDB    │→ │   PostgreSQL       │   │
│  │   (Hot)      │  │   (Blocks)   │  │   (TimescaleDB)    │   │
│  │              │  │              │  │                    │   │
│  │ 100 blocks   │  │ Full history │  │ Order tracking     │   │
│  │ 0.83ms       │  │ Async writes │  │ Market data        │   │
│  └──────────────┘  └──────────────┘  └────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Layer 1: API Layer

Purpose

The API layer provides external access to the blockchain, handling order submission, market data queries, and account management through standard HTTP and WebSocket protocols.

Components

REST API Server

Order Submission: POST /v1/exchange for placing and canceling orders
Market Data: GET endpoints for order books, trades, and 24-hour statistics
Account Queries: Balance inquiries, position details, order history
Perpetuals: Funding rates, margin information, liquidation status

WebSocket Server

Real-Time Updates: Live order book changes, trade executions, position updates
Market Data Streaming: Continuous price feeds and funding rate changes
User-Specific Feeds: Personal order status, fill notifications, margin alerts

Validation Layer

EIP-712 Signature Verification: Cryptographic validation of all orders
Balance Checks: Pre-flight validation of sufficient funds
Order Format Validation: Ensure orders meet pair requirements (min size, tick size)

Design Decisions

Why REST + WebSocket?

REST for stateless request/response operations (placing orders, queries)
WebSocket for continuous data streams (market data, personal updates)
Industry-standard protocols familiar to all traders and developers

Why API Layer Separation?

Isolates external traffic from core consensus
Enables horizontal scaling of API servers
Allows rate limiting and DDoS protection
Provides flexibility for multiple API versions

Layer 2: Core Layer

The core layer implements the blockchain's consensus, execution, and networking protocols.

HotStuff BFT Consensus

Purpose: Achieve agreement among validators on block ordering and finality

Key Features:

100ms block production
Linear communication complexity O(n)
Byzantine fault tolerance (up to 33% malicious validators)
Block commit in 100ms (single round)
Deterministic finality in 300ms (3-chain rule)

Why HotStuff?

Modern BFT protocol with proven security properties
Optimistic responsiveness (fast in normal operation)
View synchronization for network partition recovery
Lower message overhead than traditional BFT (PBFT)

Frontier-Core Matching Engine

Purpose: Execute orders with deterministic, high-performance matching

Capabilities:

369,000 operations per second (spot + perpetuals)
Multi-pair order books (5+ trading pairs)
Parallel signature verification across CPU cores
Self-trade prevention at matching engine level

Architecture:

pub struct MultiPairEngine {
    order_books: HashMap<PairId, OrderBook>,       // Spot markets
    perp_order_books: HashMap<PairId, OrderBook>,  // Perpetual futures
    pair_configs: HashMap<PairId, PairConfig>,
    trigger_manager: TriggerOrderManager,          // Stop loss, take profit
}

Performance Optimizations:

Pre-computed Order Hashes: Orders hashed once, verified 1000s of times (40% CPU reduction)
Parallel Signature Verification: Multi-core ecdsa recovery
Slab Allocator: O(1) order memory allocation/deallocation
Fixed-Precision Arithmetic: All assets use 6 decimal precision (no floating point)

Order Gossip Protocol

Purpose: Distribute orders to all validators before consensus begins

Why Gossip?

Ensures all validators have all orders before block proposal
Prevents leader from proposing orders only they have
Provides fairness (30ms minimum age prevents instant leader advantage)
Decouples order propagation from consensus rounds

Protocol Flow:

gantt
    title Order Gossip Protocol Timeline
    dateFormat X
    axisFormat %Lms

    section API Layer
    Receive & validate signature    :0, 5

    section Gossip
    Broadcast to validators (QUIC)  :5, 15

    section Validators
    Add to mempool                  :15, 20
    Track order age                 :20, 50

    section Consensus
    Wait for 30ms minimum age       :20, 50
    Leader selects eligible orders  :50, 55

QUIC Transport Benefits:

0-RTT connection establishment (faster than TCP)
Stream multiplexing without head-of-line blocking
Built-in TLS 1.3 encryption
Connection migration (validator IP changes don't break connections)

Layer 3: Storage Layer

Three-tier storage optimized for both performance and durability.

Tier 1: Memory Cache (Hot Storage)

Purpose: Immediate consensus commits without I/O blocking
Retention: 100 most recent blocks (~10 seconds)
Latency: 0.83ms average commit time
Capacity: 500MB maximum (emergency eviction at 450MB)

Tier 2: RocksDB (Block Storage)

Purpose: Persistent block history
Write Mode: Asynchronous (background worker)
Throughput: 820,000 ops/sec to disk
Storage: Full chain history retained

Tier 3: PostgreSQL/TimescaleDB (Analytics)

Purpose: Queryable order history and market data
Optimization: Time-series compression and continuous aggregates
Schema: Orders, trades, balances, positions, funding records
Access: Optimized for API queries and analytics

Component Interaction

Order Submission Flow

1. Client → API Layer
   • REST POST /v1/exchange
   • EIP-712 signed order

2. API Layer → Gossip Protocol
   • Validate signature
   • Broadcast to all validators

3. Gossip Protocol → Validator Mempools
   • All validators receive order
   • Track order age (30ms minimum)

4. Mempool → Consensus (Leader)
   • Leader selects eligible orders
   • Creates block proposal

5. Consensus → Frontier-Core Engine
   • All validators execute orders
   • Verify identical state roots

6. Frontier-Core → Storage Layer
   • Commit to memory (0.83ms)
   • Async persist to RocksDB
   • Update PostgreSQL

7. Storage → API Layer
   • Order confirmed
   • WebSocket notification to client

State Synchronization

All three layers maintain synchronized state:

API Layer: Queries storage for current balances and positions
Core Layer: Executes state transitions through consensus
Storage Layer: Persists state changes with multiple redundancy

Consistency Guarantees:

Consensus ensures all validators have identical state
Memory-first commits prevent I/O from delaying consensus
Async persistence doesn't block state progression
Crash recovery from RocksDB or network sync

Network Topology

Validator Mesh

     Validator 1 (Leader View 0)
          /  |  \
         /   |   \
        /    |    \
Validator 2 - Validator 3 - Validator 4
        \    |    /
         \   |   /
          \  |  /
     Validator 5 (Leader View 1)

Full Mesh Benefits:

Every validator connects to every other validator
Redundant message paths (fault tolerance)
Low latency (direct connections, no relaying)
Scales to ~100 validators before bandwidth limits

API Server Deployment

Modes:

Standalone Mode: Development/testing without validators (local matching engine)
Validator Sync Mode: Production sync from HotStuff validators
Archive Mode: Full historical block storage for queries

Scaling:

Multiple API servers can sync from same validator set
Load balancing across API instances
Geographic distribution for low-latency global access

Security Architecture

Layer Isolation

Each layer has distinct security boundaries:

API Layer:

Rate limiting per IP/account
DDoS protection
Input validation
Signature verification

Core Layer:

Byzantine fault tolerance
Cryptographic vote verification
Quorum certificates
Slashing for misbehavior

Storage Layer:

Write-ahead logging
Atomic commits
Backup and replication
Access control

Attack Surface Reduction

Principle: Minimize exposure of consensus to external traffic

API layer absorbs invalid requests (signature failures, malformed data)
Gossip protocol filters invalid orders before consensus
Consensus only processes validated, well-formed orders
Storage layer is append-only (no external writes)

Performance Characteristics

Measured Throughput

Component

Throughput

Latency

API Server

50K requests/sec

<10ms

Gossip Protocol

20K orders/sec

<30ms propagation

Consensus

10 blocks/sec

100ms/block

Frontier-Core

369K ops/sec

<1ms execution

Memory Storage

820K ops/sec

0.83ms commit

Bottleneck Analysis

Current Bottlenecks:

Consensus Round Time: 100ms minimum (by design)
Signature Verification: CPU-bound ecdsa recovery
Network Bandwidth: QUIC overhead for large batches

Optimization Strategies:

Pre-computed order hashes (implemented)
Parallel signature verification (implemented)
Adaptive batch streaming for bursts (implemented)
Memory-first storage (implemented)

Scalability Limits

Horizontal Scaling:

API servers: Unlimited (stateless design)
Validators: ~100 (full mesh bandwidth limit)
Storage: Sharding and archival nodes (future)

Vertical Scaling:

CPU: Parallel verification across cores
Memory: 500MB cache + swap to disk
Disk: NVMe SSD for RocksDB performance
Network: 1Gbps+ for validator communication

Comparison to Traditional Architectures

vs. Centralized Exchanges

Aspect

CEX

Frontier Chain

Block Commit

Instant (database)

100ms (consensus)

Finality

Instant (database)

300ms (3-chain BFT)

Throughput

100K-1M ops/sec

369K ops/sec

Trust Model

Trust exchange

Trustless (BFT)

Transparency

Opaque

Fully transparent

Custody

Exchange controls

User controls

vs. Traditional Blockchains

Aspect

Ethereum L1

Frontier Chain

Block Time

12 seconds

0.1 seconds

Finality

~15 minutes

0.3 seconds

Consensus

PoS (Gasper)

BFT (HotStuff)

Throughput

~15 TPS

20K orders/block

Purpose

General-purpose

Trading-optimized

vs. Other L1 DEXs

Aspect

Solana

Frontier Chain

Consensus

PoH + PoS

HotStuff BFT

Block Time

400ms

100ms

Finality

~14 seconds

300ms

Determinism

Probabilistic

Deterministic

Order Matching

On-chain AMM

Native order book

Future Architecture Evolution

Planned Enhancements

EVM Integration:

REVM execution engine
Precompiler at 0x1000 for Frontier-Core access
Unified state root (EVM + matching engine)
Smart contract composability with order books

Scalability Improvements:

Sharded order books by trading pair
Parallel execution threads
State channels for high-frequency traders
Archival nodes for historical data

Advanced Features:

Cross-chain bridges
Decentralized oracle integration
Governance modules
MEV protection mechanisms

Conclusion

Frontier Chain's three-layer architecture achieves institutional-grade performance while maintaining full decentralization. By separating API access, core consensus/execution, and storage into distinct layers, the system optimizes each component independently while ensuring consistency through well-defined interfaces.

Key Architectural Advantages:

Performance: 369K ops/sec with 0.83ms commits
Security: Byzantine fault tolerance with cryptographic guarantees
Scalability: Horizontal API scaling, vertical validator optimization
Transparency: All operations verifiable on-chain
Determinism: Identical execution across all validators

PreviousFrontier Chain Architecture NextConsensus Layer

Last updated 1 month ago

Good morning

Three-Layer Architecture

Layer 1: API Layer

Purpose

Components

REST API Server

WebSocket Server

Validation Layer

Design Decisions

Layer 2: Core Layer

HotStuff BFT Consensus

Frontier-Core Matching Engine

Order Gossip Protocol

Layer 3: Storage Layer

Tier 1: Memory Cache (Hot Storage)

Tier 2: RocksDB (Block Storage)

Tier 3: PostgreSQL/TimescaleDB (Analytics)

Component Interaction

Order Submission Flow

State Synchronization

Network Topology

Validator Mesh

API Server Deployment

Security Architecture

Layer Isolation

Attack Surface Reduction

Performance Characteristics

Measured Throughput

Bottleneck Analysis

Scalability Limits

Comparison to Traditional Architectures

vs. Centralized Exchanges

vs. Traditional Blockchains

vs. Other L1 DEXs

Future Architecture Evolution

Planned Enhancements

Conclusion