Consensus Mechanism

Ontology's consensus network and mechanism

Verifiable Byzantine Fault Tolerance (VBFT) is the core consensus algorithm of the Ontology Consensus Engine (OCE). It is a hybrid algorithm that combines Proof of Stake (PoS), Verifiable Random Function (VRF), and the Byzantine Fault Tolerance algorithm (BFT).

VBFT supports up-scaling of the consensus group. The randomness and fairness within the consensus group is safeguarded by the VRF, while also ensuring that a final consensus is swiftly reached.

The consensus network is fundamentally composed of two parts-

Consensus Network

The consensus network is made up of all the consensus nodes that carry out the consensus process with respect to the events that take place within the Ontology network. This includes block generation, maintaining ledger consistency, and sending the blocks that pass the consensus process to the synchronization node network.

Consensus Candidate Network

Candidate nodes do not participate in the consensus process, but stay synchronized to the consensus node status and update the new block information real time in the ledger they maintain.

The candidate nodes constantly monitor the consensus nodes and their status. They verify the consensus blocks and support Ontology network administration.

Candidate Node Pool

The consensus network scale is administered using consensus smart contracts. Every node in the consensus network has its corresponding stake set by the node administrator.

Building a Consensus Network

The consensus network is built using the consensus management smart contracts. Consensus management contracts are permanently deployed and running on the Ontology network and periodically update the consensus node list andVBFT algorithm configuration parameters.

The PoS table is an important VBFT parameter. When VBFT is run, all the nodes randomly choose the nodes that will participate and carry out a round of consensus process.

Algorithm Overview

The VBFT algorithm could be considered as an improvement on the traditional Byzantine Fault Tolerance (BFT) algorithm in terms of its randomness being verifiable.

A set of alternate block proposal nodes is selected sequentially on the basis of VRF for a round of consensus. The node sets are segregated in two, block verification node set and block confirmation node set, and then the consensus process is carried out based on this selection.

Owing to the randomness factor added by VRF, the proposal node, verification node, and confirmation node sets are different for each round of block consensus. This is very difficult to predict, and that makes this algorithm resistant to malicious attacks.

The algorithm can be summarized as follows:

1. Alternate proposal nodes are selected from the consensus network based on VRF. A block is proposed by each proposal node.

2. Verification nodes are chosen from the consensus network based on VRF. Each verification node collects the proposed blocks from the consensus network, carries out verification, and votes for the proposed block with the highest priority.

3. Confirmation nodes are selected from the consensus network based on VRF. These nodes carry out statistical verification for the voting carried out by the verification nodes and confirm the final consensus result.

4. All the nodes in the consensus then acknowledge the result obtained by the confirmation nodes. This marks the end of one round of consensus, and post confirmation a new round of consensus begins.

Verifiable Random Function

As part of the current VBFT algorithm, the VRF value of each block is determined by the previous consensus blocks. The algorithm actually fetches transaction information from the previous block and calculates the 1024 place hash value, and then uses it as the VRF value for the next block.

Node Selection

The VBFT algorithm uses the VRF value from the previous round of consensus as index to determine the nodes from the PoS table that will participate the next round of consensus. The PoS table generation takes every node owner's PoS information and the consensus network's governance policy into account. Even though the random VRF values can be considered to be uniformly distributed, the algorithm's random node selection process is still subject to Ontology's consensus network administration policies.

Since the VRF value generated by every block is verifiable, provided that a block is not split, all the nodes will be consistent for a block at a certain height.

The VRF in the algorithm selects nodes sequentially from the PoS table. For this reason, each VRF value maintains an alternate proposal node sequence, and this random node sequence is also consistent with the consensus process.

Fork Selection

Ontology by the virtue of being a public chain that operates on a public network inevitably needs to face issues such as malicious attacks and faults that any public network would face. Although the VBFT consensus algorithm uses the consensus nodes randomly, and this increases the level of difficulty to execute an attack, the risk of a fork still exists when network isolation occurs.

As discussed above, every block's VRF can determine a node sequence. When VBFT carries out fork choice, it assigns the level of priority for each node based on this node sequence. Next, each fork priority is weighted based on the sequence of these assigned priorities, and then each node makes the suitable fork choice based on the weighted fork priority levels.

Since each block is selected based on the priority sequence determined by VRF, we can say that it is very difficult, or even impossible for malicious forks to maintain a high level of priority for themselves, and thus such forks swiftly die out. This is how VBFT is able to ensure quick conclusion rate in terms of final states.

Automatic Configuration

To maintain the quality of the consensus network, Ontology consensus management contract automatically updates the node list. In the event of a network discrepancy, the consensus management contract supports the voting that place on the basis of stake and explicitly updates the node list of the consensus network.

After a new node gains more stake and it is confirmed that the node performance meets the requirements of the consensus network, it is added to the consensus network when the node list is updated.

The updation time of the consensus network is marked with block as the unit. Every time the consensus network completes consensus on a certain, fixed number of blocks, the next block's proposal node must construct a management contract execution event and package it into the next proposed block as the first event. The corresponding validation and confirmation nodes also verify the validity of this proposed block.

After the block that contains the consensus management contract execution event is reached consensus upon, every node in the network executes the consensus management contract and updates the node list. By the end of this process, the consensus node list would be updated throughout the consensus network.

Consensus Mechanism	Application Scenarios	Efficiency	Consensus Confirmation Rate	Consensus Confirmation Sample Time	Node Count	Anti-malicious Node Count	Resource Consumption Rate	Security Control
POW	Public Blockchain	< 20 tps	Slow	Bitcoin: 60 minutes Ethereum: 1 minute	-	50%	High	Low
DPOS	Public Blockchain	> 500 tps	Medium	Bitstocks: 10 seconds	< 30	Not known	Low	High
PBFT	Alliance/Proprietory Blockchain	> 1000 tps	Fast	FISCO-BCOS：1 second Fabric：1 second	< 30	No more than 1/3 consensus nodes	Low	High
VBFT	Public/Proprietory Blokchcain	> 3000 tps	Medium	Ontology Testnet：5-10 Seconds	< 1000	Configurable BFT number，Not more than 1/3 consensus nodes	Low	High
Paxos/RAFT	Alliance/Proprietory Blockchain	> 5000 tps	Fast	FISCO-BCOS：1 Second	< 30	None	Low	High