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 (
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.
Candidate Node Pool
The consensus network scale is administered using consensus smart contracts. Every node in the consensus network has its corresponding
stakeset 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
VBFTalgorithm configuration parameters.
PoStable is an important
VBFTis 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
VRFfor 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.
As part of the current
VRFvalue of each block is determined by the previous consensus blocks. The algorithm actually fetches transaction information from the previous block and calculates the
1024place hash value, and then uses it as the
VRFvalue for the next block.
VBFTalgorithm uses the
VRFvalue from the previous round of consensus as index to determine the nodes from the
PoStable that will participate the next round of consensus. The
PoStable generation takes every node owner's
PoSinformation and the consensus network's governance policy into account. Even though the random
VRFvalues can be considered to be uniformly distributed, the algorithm's random node selection process is still subject to Ontology's consensus network administration policies.
VRFvalue 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.
VRFin the algorithm selects nodes sequentially from the
PoStable. For this reason, each
VRFvalue 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
VBFTconsensus 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
VRFcan determine a node sequence. When
VBFTcarries 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
VBFTis 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
stakeand explicitly updates the node list of the consensus network.
After a new node gains more
stakeand 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.