Consensus Mechanism
Ontology's consensus network and mechanism
Last updated
Ontology's consensus network and mechanism
Last updated
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-
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 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.
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.
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.
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 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 |
