Architecture Deep-Dive

This document provides a comprehensive technical overview of GX Core’s internal architecture, including consensus, block production, state management, and the data flow from order submission to settlement.

Dual-Engine Architecture

GX Chain runs two execution environments under a shared BFT consensus layer:

Both engines process transactions proposed in the same block. GX Core transactions are applied first (deterministic, native), followed by GX EVM transactions. A system contract interface allows the EVM to read GX Core state (prices, positions, balances).

GX BFT Consensus

GX Chain uses GX BFT consensus, a leader-based Byzantine Fault Tolerant protocol with linear message complexity and consensus pipelining for overlapping proposal/vote phases.

How It Works

1. Leader election — A round-robin or stake-weighted leader is selected for each block height
2. Proposal — The leader bundles pending transactions into a block proposal
3. Voting — Validators vote on the proposal; a block is committed when more than two-thirds of weighted stake votes in favor
4. Finality — Committed blocks are final immediately — no reorgs, no rollbacks
5. View change — If the leader fails to propose within the timeout, validators elect a new leader

Key Properties

Validator Set

The validator set is managed through epochs. At each epoch boundary (configurable number of blocks), the active validator set can be updated based on staking changes, jailing events, or governance decisions.

Block Production Pipeline

1. MEMPOOL
   - Orders arrive via REST API (port 4001)
   - Each order is EIP-712 signature-verified
   - Orders are placed in the semantic mempool
   - Semantic ordering: cancels before new orders, liquidations before regular orders

2. BLOCK PROPOSAL (Leader)
   - Leader drains the mempool up to the block gas/size limit
   - Constructs a block with ordered transactions
   - Signs the block proposal
   - Broadcasts to all validators via P2P gossip

3. BFT VOTING
   - Validators verify the block proposal
   - Each validator votes (sign with validator key)
   - Leader collects votes; commits when >2/3 quorum reached
   - Block is finalized (near-instant from proposal)

4. BLOCK APPLICATION (All Validators)
   - GX Core transactions applied first:
     a. Process cancellations
     b. Process liquidations
     c. Match new orders against the order book
     d. Update positions, margin, PnL
     e. Apply funding rate payments
     f. Settle trading fees
   - GX EVM transactions applied second:
     a. Execute Solidity contract calls
     b. Update EVM state trie
   - State hash computed and stored

5. PERSISTENCE
   - RocksDB: block state snapshot
   - PostgreSQL: fills, candles, block metadata
   - WebSocket: broadcast orderbook updates, trades, positions

Semantic Mempool

Unlike generic blockchain mempools that order transactions by gas price, GX Core uses a semantic mempool that understands the meaning of each transaction type:

Within each priority level, transactions are ordered by arrival time (FIFO). This semantic ordering prevents front-running and ensures that risk-critical operations always execute before regular trades.

State Storage

RocksDB (Hot State Persistence)

RocksDB stores the canonical chain state as key-value pairs. On every committed block, the full state is checkpointed. On validator restart, state is loaded from the latest RocksDB snapshot.

Key state domains:

PostgreSQL (Historical Indexer)

PostgreSQL stores historical data for API queries. It is populated asynchronously by the indexer and is not part of the consensus-critical path.

P2P Networking

GX Chain uses a libp2p-based P2P layer for inter-validator communication:

The P2P port is 9000 by default. All validator-to-validator communication is authenticated using secp256k1 signatures and encrypted using Noise framework.

Authentication

All user-facing operations require EIP-712 typed data signatures:

EIP-712 Domain:
  name: "GXExchange"
  version: "1"
  chainId: 42069

Order Signature Payload:
  market: "BTC-USD"
  side: "buy"
  size: "1.5"
  price: "67400"
  type: "limit"
  nonce: 42
  expiry: 1714000000

The same Ethereum private key that controls a user’s MetaMask wallet signs orders on GX Chain. No separate key generation or chain-specific wallet is required.

For programmatic access, GX Core also supports API key authentication using HMAC-SHA256 signatures, enabling low-latency trading bots without per-order wallet signing.

Monitoring

GX Core exposes Prometheus-compatible metrics at the /metrics endpoint: