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 (
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-
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.
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.
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.
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 and
VBFT algorithm configuration parameters.
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.
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:
Alternate proposal nodes are selected from the consensus network based on
VRF. A block is proposed by each proposal node.
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.
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.
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.
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.
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.
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.
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.
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.
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 Confirmation Rate
Consensus Confirmation Sample Time
Anti-malicious Node Count
Resource Consumption Rate
< 20 tps
Bitcoin: 60 minutes
Ethereum: 1 minute
> 500 tps
Bitstocks: 10 seconds
> 1000 tps
No more than 1/3 consensus nodes
> 3000 tps
Ontology Testnet：5-10 Seconds
Configurable BFT number，Not more than 1/3 consensus nodes
> 5000 tps