Nodes in the Chromia network

A node in the Chromia network is a computer (such as a virtual or physical server) that runs the Chromia core software, Postchain, and the open-source relational database PostgreSQL. A node holds a unique cryptographic key pair and is identified on the network through its public key. In this section, we'll explore how Postchain powers the network by handling decentralized transaction processing and data storage.

Postchain overview

Postchain is the core software that manages blockchain operations and integrates them with relational database functionality through PostgreSQL. It serves as the backbone of Chromia, enabling decentralized transaction processing and data consistency across multiple nodes.

Postchain handles key tasks on Chromia's nodes, such as:

• Transaction processing: It accepts and processes signed transactions submitted by users or applications.
• Consensus management: The system employs the eBFT (Enhanced Byzantine Fault Tolerance) consensus protocol to validate blocks and achieve agreement among nodes.
• Data storage: It interacts with PostgreSQL to store blockchain data, which includes the history of verified transactions and the states of each dapp’s individual blockchain.
• Dapp code execution: It executes dapp-specific code written in the Rell programming language, translating operations into database actions that update the state of each dapp.

PostgreSQL integration and indexing

The PostgreSQL integration within Postchain enables automatic data indexing, allowing Chromia to support complex relational queries directly on-chain. This approach offers significant performance advantages in both read and write operations, enhancing data accessibility and flexibility for developers. With these capabilities, dapp developers can:

• Retrieve specific data points or datasets using advanced filters, eliminating the need to retrieve full data arrays.
• Perform relational queries across multiple tables or entities, allowing complex on-chain data interactions without relying on off-chain processing.

Together, these features empower developers to build data-rich, complex dapps that leverage Chromia’s on-chain database integration for optimal efficiency and functionality.

Transaction lifecycle on Postchain

The lifecycle of transactions on Postchain involves several interconnected tasks, ensuring that each transaction is properly received, processed, and stored. These tasks include:

Receiving transactions

To execute a transaction for a dapp on the Chromia network, a user or client sends that transaction to any node that runs that dapp via the node's REST API. In practice, this means sending the transaction to any node within the cluster that houses the dapp. Transactions are encoded according to Chromia's Generic Transaction Protocol (GTX) and include the following:

• The unique ID of the dapp chain on the network (referred to as the Blockchain RID).
• A list of operations and their corresponding arguments. These operations are defined in the dapp's code, allowing users to call them through transactions and modify data. This defines what the transaction accomplishes.
• A list of signers along with their signatures.

Building blocks and verifying consensus

When a node receives a transaction, it quickly multicasts it to all other nodes in the cluster. These nodes then verify consensus using Chromia's eBFT algorithm, a modified version of Practical Byzantine Fault Tolerance. eBFT operates as a Proof-of-Authority (PoA) algorithm, allowing a select group of validator nodes to create new blocks. The validator nodes in the dapp's cluster collaborate to achieve consensus, ensuring only valid transactions are added to the blockchain and that the network remains secure and resilient.

With eBFT, a node can propose a block, and the proposal is accepted if it gets a super-majority (greater than ⅔) of validators to sign the block. Validator nodes take turns creating the next block. The consensus process follows these steps:

1. The primary node collects all incoming transactions within a specific (configurable) time interval and adds them to the proposed block for the current round.
2. It then multicasts the proposed block to all other nodes.
3. Upon receiving the proposed block, the other nodes validate it by executing the transactions (without making changes to the database). If valid, they sign the block and multicast their signatures to all other nodes, including the primary node.
4. Once the primary node receives signatures from more than two-thirds of the nodes, each node commits the block to the database.

The consensus algorithm can withstand just under ⅓ of the nodes in a cluster acting maliciously, switching off, or isolating themselves from the rest of the network. Once consensus around a block of transactions is reached, those transactions can be safely committed.

Executing dapp code

Dapps on the Chromia network are written in Rell, a programming language specifically designed for the platform. Rell simplifies working with Chromia's relational blockchain model. When transactions occur, Postchain interprets and executes the dapp code, performing the specified operations with the transaction's provided arguments.

Updating the relational database

Each dapp on Chromia operates with its own instance of a relational database. Upon deploying a new dapp or updating an existing one, Postchain interprets the dapp's code to determine the required database tables. It automatically creates the necessary tables and columns, ensuring the dapp functions smoothly.

Postchain also updates the database as transactions occur. When transactions invoke operations defined in the dapp’s Rell code, Postchain translates this code into SQL queries, updating the dapp's data and state. Rell prevents developers from executing raw SQL queries directly, instead offering an abstraction that limits access to their own data while providing a more convenient and expressive way to interact with the database.

Additionally, Postchain stores system-level data in the relational database. This includes storing each dapp's blockchain and the history of verified transactions. If needed, this information can be combined and replayed to restore each dapp's database state at any block height, ensuring data integrity across the network.

Responding to queries

Besides transactions, which invoke operations and mutate data, Chromia allows you to perform read-only queries for a dapp. Like transactions, queries are typically called using one of Chromia's client libraries. However, unlike transactions, nodes running Postchain quickly respond to read-only queries without needing to verify consensus. This efficiency allows the client or frontend to implement its own consensus verification strategy if required. For instance, you might randomly choose a node from the cluster for a query, or in more complex cases, you might query multiple nodes and validate consensus on the frontend.

Queries, like operations, are defined in Rell and are part of the deployed code for a dapp. They automatically form part of a dapp's API and can be invoked through a client library by passing the necessary arguments.

Dapp containers

Dapps on the Chromia network have their own dedicated compute and storage resources to ensure consistent throughput. Each node on the network runs multiple instances of the core software, Postchain. The main instance operates directly on the node machine and spawns containers (isolated virtual machines) to host specific dapps. This setup allows the main instance to route transactions and events efficiently to the corresponding container. From an external perspective, each node functions as a single entity on the Chromia network, capable of accepting transactions intended for any of the dapps it hosts.

The relational database

Each dapp container hosts its own instance of a PostgreSQL relational database to support that container's dapp. The database stores:

• Dapp data, with tables corresponding to entities in the dapp's Rell code.
• A dapp's individual blockchain.
• A complete history of verified transactions related to the dapp.
• Node configuration settings, including addresses of peer nodes within the cluster.
• Replicas of the system chain.

Next up

Having explored the structure of nodes in the Chromia network, we'll now explore the Chromia architecture.