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 the Chromia core software works to run dapps and store data.

The Chromia core software

The Chromia core software, Postchain, accepts transactions and queries, builds consensus within a cluster, interprets dapp code, builds blocks, and interacts with the relational database. It's a modular framework and entirely open source. Let's take a closer look at the framework's primary functions by following the lifecycle of a transaction on the Chromia network.

Receives 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 (Blockchain RID).
• A list of operations and operation arguments. Operations are methods defined in the dapp's code that can be called through transactions, resulting in mutating data. This determines what the transaction does.
• A list of signers and signatures.

Builds blocks and verifies consensus

The node that receives the transaction multicasts it to all other nodes in the cluster. The nodes then verify consensus using Chromia's eBFT algorithm, a modified version of Practical Byzantine Fault Tolerance. eBFT is a Proof-of-Authority (PoA) algorithm where a select group of validator nodes can create new blocks. These validator nodes (the nodes in the dapp's cluster) work together to reach a consensus, ensuring that only valid transactions are added to the blockchain and 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. The primary node multicasts the proposed block to all the other nodes.
3. Upon receiving the proposed block from the primary node, the other nodes validate it by executing the transactions in it (but without committing changes to the database). If valid, they sign the block and multicast their signature to all other nodes (including the primary node).
4. Upon receiving block signatures from more than ⅔ 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 achieved, the transactions contained in them can be safely committed.

Executes dapp code

Dapps on the Chromia network are written in the programming language Rell, designed specifically for the platform. Rell makes it easy to work with Chromia's relational blockchain model. Postchain interprets and executes dapp code in response to transactions, executing the operations specified in the transactions with the arguments in the transactions.

Updates the relational database

Each dapp on Chromia has its instance of a relational database. When a new dapp (or an update to a dapp) is deployed to a cluster, Postchain interprets the dapp's code and determines what database tables the dapp requires. It then automatically creates tables and columns in the database to ensure the dapp can run.

Postchain also updates the database as a result of transactions. Transactions invoke operations defined in the dapp's Rell code. When interpreted by Postchain, the Rell code results in SQL queries applied to the database, thus updating the dapp's data and state. Instead of giving developers the ability to execute raw SQL queries, Rell provides an abstraction that ensures that dapps can only access and update their own data and provides developers with a more convenient and expressive way to interact with the database.

Postchain also stores system-level data in the relational database behind the scenes. For example, each dapp's blockchain and the history of each verified transaction are stored in the database. If necessary, this information can be combined and replayed to recreate each dapp's database state at any given block height, thus protecting the integrity of the data on the network.

Responds 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. Unlike transactions, however, nodes running Postchain respond directly to read-only queries without verifying consensus. This means that responding to queries is quick and efficient, and the client or frontend can employ its own strategy to verify consensus if necessary. In some cases, randomizing which node in a cluster to send a query to may be enough, and in other instances, querying multiple nodes and verifying consensus on the front end may be warranted.

Similarly to operations, queries are defined in Rell and form part of a dapp's deployed code. They are automatically exposed as part of a dapp's API and invoked by using a client library to call a query with a set of arguments.

Dapp containers

Dapps on the Chromia network have their own dedicated compute and storage resources to ensure consistent throughput. In practice, each node on the network runs several instances of the core software, Postchain. There is a main instance that runs directly on the node machine. To run dapps, the main instance spawns containers (isolated virtual machines), which host their own instance of Postchain to run a specific dapp. The main instance routes transactions and other events to and from the correct container. From the outside, the node acts as a single entity on the Chromia network that can accept transactions meant 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 for the dapp.
• Node configuration, including addresses to peer nodes in the same cluster.
• System chain replicas.

Next up

Now that we've covered the anatomy of nodes on the Chromia network, we'll continue looking at who hosts these nodes, namely Chromia's Providers.