Delegated Byzantine Fault Tolerance (dBFT)
Operates on the principle of Byzantine Fault tolerance to verify blocks, by using an election followed by a validation process. Used by: NEO
The Byzantine Generals’ Problem
Byzantine Fault Tolerance is the resistance of a fault-tolerant distributed computer system towards component failures where there is imperfect information on whether a component has actually failed. This concept is used by NEO to act as a consensus mechanism. To understand how this works, first we have to explain the problem:
The Byzantine Generals’ scenario is an analogy for the problem faced by distributed computing systems: How do we reach consensus when faced with untrustworthy and malfunctioning actors that threaten to destabilize the ecosystem?
- Not much unlike the process in Delegated Proof of Stake, all nodes in the network elect a group of consensus nodes.
- From this group, a ‘speaker’ is randomly chosen. The rest of the consensus nodes then assume the role of delegates.
- This speaker is responsible for constructing a new block from the waiting transactions. It has to verify these and calculate the hashes.
- This block proposal is then sent to the delegates, who will validate the proposed block and its transactions.
- The delegates share and compare their findings (block proposals) among themselves to verify that they all reach the same conclusion.
- In an ideal case where everyone is honest, the delegates reach consensus (more than the required 66.66%) and the block is added to the blockchain.
dBFT in practice: three scenarios
To understand how – and why – the dBFT consensus mechanism is fault-tolerant, we need to elaborate on three possible scenarios, shown below.
Scenario 1: The Dishonest Speaker
- There is always the chance the speaker is dishonest or otherwise malfunctioning. In this case, the speaker sends a malicious (block) proposal to 2 of 3 delegates.
- As each delegate has a copy of the waiting transactions, it can easily verify if a block proposal is valid or invalid.
- By comparing, the delegates determine that they received a corrupted proposal from the speaker, which is therefore considered dishonest.
- Consensus is reached, as more than 50% of the delegates find the block to be invalid, and the dishonest speaker is to be replaced.
Scenario 2: The Dishonest Delegate
- There is always the chance a delegate is dishonest or otherwise malfunctioning. In this case, all delegates receive a valid (block) proposal from the speaker.
- The dishonest delegate broadcasts its corrupted block proposal as valid to the other delegates.
- By comparing, the delegates determine that either the delegate is dishonest, or it has received a corrupted proposal from the speaker.
- Consensus is reached, as more than 50% of the delegates find the block to be valid, and the dishonest delegate is to be replaced.
Scenario 3: The Dishonest Speaker & Delegate
- There is always the chance that both speaker and a delegate are dishonest or otherwise malfunctioning. In this case, all delegates receive different (block) proposals from the dishonest speaker.
- The dishonest delegate broadcasts its corrupted block proposal as valid to the other delegates, and the honest delegates correctly (in)validate their own proposals.
- By comparing, each honest delegate determines that either all other delegates are dishonest, or everyone has received a corrupted proposal from the speaker.
- Consensus is reached, as more than 50% of the delegates find the block to be invalid, and the dishonest delegate and speaker are to be replaced.
- “Bad guys” would need to control 2/3rd of the nodes to corrupt transactions. Nodes are voted in by the NEO holders so it would be very difficult and expensive (at 1000 GAS a node) to try it. Why ruin your income to corrupt a transaction?
- Before you can be voted as consensus node, you need to be certified/validated. The node owners will be known people and not anonymous at all.
- NEO can roll back transactions without having to hard fork. NEO can simply roll back the transactions with consensus.