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: Libra (Facebook blockchain), 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 ProblemThe Byzantine Generals Problem
The Byzantine Generals 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?

Basic Principle

  • 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.
dBFT: consensus nodesdBFT: consensus nodes
dBFT: consensus nodes
dBFT: speakerdBFT: speaker
dBFT: speaker
  • 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.
Note: ‘transactions‘ can also mean (the results of) scripts, claims, invocations, smart contracts or any other form of data that was chosen to be recorded on the blockchain.
  • 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: consensusdBFT: consensus
dBFT: consensus

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.
dBFT: dishonest speaker scenariodBFT: dishonest speaker scenario
dBFT: dishonest speaker scenario
dBFT: dishonest speaker scenariodBFT: dishonest speaker scenario
dBFT: dishonest speaker scenario
  • 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.
dBFT: dishonest delegate scenariodBFT: dishonest delegate scenario
dBFT: dishonest delegate scenario
dBFT: dishonest delegate scenariodBFT: dishonest delegate scenario
dBFT: dishonest delegate scenario
  • 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.
dBFT: dishonest speaker & delegate scenariodBFT: dishonest speaker & delegate scenario
dBFT: dishonest speaker & delegate scenario
dBFT: dishonest speaker & delegate scenariodBFT: dishonest speaker & delegate scenario
dBFT: dishonest speaker & delegate scenario
  • 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.

Overview

Delegated Byzantine Fault ToleranceDelegated Byzantine Fault Tolerance
Delegated Byzantine Fault Tolerance

Notes

  1. “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?
  2. 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.
  3. NEO can roll back transactions without having to hard fork. NEO can simply roll back the transactions with consensus.