πŸ”—Technical Framework

Introduction to BitoroCore Architecture

System Architecture

BitoroCore has been designed to be fully decentralized end-to-end. The main components include the protocol, the Indexer, and the front end(s). Each of these components is available as open-source software, ensuring transparency and accessibility. None of these components are operated or controlled by Bitoro Labs.


Protocol (or β€œApplication”)

The open-source protocol is an L1 blockchain built on top of CometBFT and using CosmosSDK. The node software is written in Go and compiles into a single binary. Like all CosmosSDK blockchains, BitoroCore uses a proof-of-stake consensus mechanism.

The protocol is supported by a network of nodes, categorized into two types:

  1. Validators: Validators store orders in an in-memory order book (off-chain and not committed to consensus), gossip transactions to other validators, and produce new blocks through the consensus process. Block proposals rotate in a weighted round-robin manner, weighted by the number of tokens staked. Validators:

    • Propose blocks.

    • Match and execute orders.

    • Ensure consensus approval by a β…” majority (by stake weight).

  2. Full Nodes: Full nodes do not participate in consensus but connect to the validator network to:

    • Gossip transactions.

    • Process new committed blocks.

    • Support Indexers.

Organizations may deploy their own full nodes to enhance performance or reduce operational costs.


Indexer

The Indexer is a read-only service designed to index and serve blockchain data efficiently to end users. It:

  • Consumes real-time data from a BitoroCore full node.

  • Stores data in a database.

  • Serves data through APIs and WebSockets.

The Indexer ensures high-performance queries while avoiding excessive strain on validator nodes, which are optimized for consensus.

Core components of the Indexer:

  • Postgres Database: Stores on-chain data.

  • Redis: Manages off-chain data.

  • Kafka: Streams data for on/off-chain services.


Front Ends

To enable a decentralized user experience, BitoroCore includes an open-source front end for web (and eventually for iOS, and Android):

  • Web Application: Built with JavaScript and React, the web app interacts with the Indexer API for off-chain data and directly communicates with the chain for trades.

  • Mobile Apps: iOS and Android apps will be developed in Swift and Kotlin, respectively. They will function similarly to the web app and can be deployed independently to app stores.


Lifecycle of an Order

The following outlines the process of placing an order on BitoroCore:

  1. A user places a trade via a decentralized front end or API.

  2. The trade is routed to a validator and shared with other validators and full nodes.

  3. A validator proposes a block, matches the order, and adds it to the block.

  4. Validators approve the block if β…” of the stake weight supports it.

  5. The committed block updates the blockchain, and data is streamed to the Indexer.

  6. The Indexer makes the data available via APIs and WebSockets for front ends and external services.


On-Chain vs. Off-Chain Data

  • On-Chain Data: Includes account balances, order fills, trades, liquidations, and funding rates, validated through consensus.

  • Off-Chain Data: Includes ephemeral order book updates, short-term orders, and indexed updates before they are written to the blockchain.


Indexer Architecture

The Indexer comprises the following services:

  1. Ender (On-Chain Ingestion):

    • Processes and stores on-chain events in a Postgres database.

    • Emits WebSocket events for real-time updates.

  2. Vulcan (Off-Chain Ingestion):

    • Manages off-chain events, including order book updates, using Redis.

    • Updates Postgres for partially filled orders or cancellations.

  3. Comlink (API Server):

    • Provides REST API endpoints for querying on-chain and off-chain data.

  4. Roundtable (Aggregation Service):

    • Computes exchange metrics, such as 24-hour trading volume, open interest, and PnL.

  5. Socks (WebSocket Service):

    • Facilitates real-time communication between clients and the Indexer.


Hosting & Deploying the Indexer

The Indexer is open source and can be hosted by any third party. Comprehensive documentation and infrastructure-as-code will become available for deployment on popular cloud providers.

Responsibilities of a third-party operator include:

  • Initial deployment: Setting up infrastructure, deploying code, and integrating monitoring tools.

  • Maintenance: Keeping the Indexer up-to-date, monitoring performance, and troubleshooting.

Recommended infrastructure services:

  • AWS (ECS, RDS, Lambda, Redis, CloudWatch, etc.).

  • Terraform for deployment.

  • Datadog and Bugsnag for monitoring and alerts.

Operators should ensure high availability and uptime for hosted Indexers.

Last updated