Understanding nodes in the Chromia network

In the Chromia ecosystem, nodes are the backbone that power the functionalities of its blockchains. Each node is a dedicated computer equipped with a PostgreSQL database and Postchain, a combination that efficiently handles transaction validation, network security, and storage of all blockchain data within Chromia.

Postchain is the core software specifically designed for relational databases, storing data in a way similar to traditional databases, making it easier for developers to work with and understand.

Each node possesses a unique configuration, including a key pair (public and private keys) for communication and block signing, along with an IP address and port. While public keys and IP addresses are openly visible for communication between nodes, the private key remains confidential to each node.

How Postchain works?

Postchain serves as the backbone of Chromia's dapp infrastructure, orchestrating transaction processing, consensus verification, and database management to uphold the integrity and efficiency of the decentralized network. It is a relational blockchain framework, a software that adds a blockchain, including security and consensus mechanisms, to relational databases. Here's a concise overview of how Postchain works:

• Runs dapp code: Chromia nodes don't directly execute Rell code. Instead, they run containerized environments that house the necessary software to manage the dapp's Rell code.
• Receives transactions from users or clients: The dapp frontend uses postchain-client to communicate with the dapp's backend logic running on a Chromia node. This communication often resembles interacting with a traditional API.
• Verifies consensus with other nodes before committing a transaction: Chromia nodes rely on a robust consensus mechanism called eBFT (efficient Byzantine Fault Tolerance) to verify transactions and ensure agreement across the network before committing them to the blockchain.
• Updates database based on transaction contents: After a transaction achieves consensus and is added to a block on the dapp's blockchain, the validator node that proposed the block broadcasts this information to all nodes, including the relevant Chromia node. The Chromia node receives confirmation about the committed block, which triggers an update process within the Postchain database engine.
• Builds blocks containing transaction data and stores them in the database: Postchain extracts the specific details of the transaction from the committed block and executes the necessary operations to update its internal database.
• Responds to queries from users or clients: When the dapp's backend receives a query from the client library, Postchain retrieves the requested data from the relevant dapp's database and sends it back to the dapp's frontend through the client library.

Understanding key pairs

Chromia utilizes public-key cryptography with a pair of public and private keys to establish secure and trustworthy transactions on the blockchain. The private key, known only to its owner, is used for signing transactions, messages, or data, providing irrefutable proof of authenticity and integrity. The public key, derived from the private key, serves as a publicly shareable identifier or address of the key owner and is used to verify digital signatures.

Let's see an example of how a key pair can be used to sign a transaction sent to the Chromia network and perform an operation that requires authorization:

Achieving consensus through eBFT

Now, let's discuss how these nodes achieve consensus using the eBFT algorithm. eBFT operates within a Proof-of-Authority (PoA) framework, where a select group of validator nodes can create new blocks. These validator nodes work together to reach consensus, ensuring that only valid transactions are added to the blockchain, and the network remains secure and resilient.

The individual dapps are hosted on a subset of validator nodes, which establish consensus on any modifications to the dapp state. With eBFT, a primary node can propose a block, and the proposal is accepted if it gets a super-majority (greater than or equal to ⅔) of validators to sign the block. Validator nodes take turns creating the next block.

Any node that receives a transaction from a client replicates the transaction and multicasts it to all other nodes. 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, and if valid, they multicast their block (in a have block message) to all other nodes (including the primary node).
4. Upon receiving consistent blocks from at least 2f+1 nodes, each node stores the block in the blockchain, executes the transactions, and multicasts a new block signature to all other nodes.
5. Upon receiving new block signatures from at least 2f+1 nodes, each node commits the block to the database (executes the transaction within the block).

The consensus algorithm can withstand up to 1/3 of the validators acting maliciously, switching off, or isolating themselves from the rest of the network.