Delegated Byzantine Fault Tolerance

5 min readFeb 7, 2018

Looking into the basics of NEO’s Consensus Mechanism.

Originally published at cryptographics.info on February 7, 2018.

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?

So, how does Byzantine Fault Tolerance translate into a blockchain consensus mechanism?

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’ (red) is randomly chosen. The rest of the consensus nodes then assume the role of delegates (green).

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 in practice: three scenarios

To understand how — and why — the dBFT consensus mechanism is fault-tolerant, we need to elaborate on three possible scenarios.

Scenario 1: The Dishonest Speaker

There is always the chance the speaker (brown) 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 (brown) 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 (brown)and a delegate (brown) 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.

Overview

Notes

“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 and not anonymous at all.
NEO can roll back transactions without having to hard fork. NEO can simply roll back the transactions with consensus.

Sources/Further reading