# Consensus 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.
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** and`VBFT` 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 |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.ont.io/ontology-elements/consensus-mechanism.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.