Consensus

Our consensus method is based on PBFT (Practical Byzantine Fault Tolerance) protocol. It's our custom implementation from the ground up called eBFT, a Proof-of-Authority (PoA) protocol. In PoA, rights to generate new blocks are awarded to nodes that have proven their authority. These nodes are called validator nodes, and they validate transactions and blocks.

Each blockchain within Chromia is associated with a set of validator nodes, a subset of all nodes. 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.

1. The primary node collects all incoming transactions within a certain (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, switched off, or isolated from the rest of the network.