Delegated Byzantine Fault Tolerance (dBFT) & Generals’ Problem Explained

19 Mar 2019

Delegated Byzantine Fault Tolerance (dBFT)

The developers of NEO, one of the world’s largest platforms for building and deploying decentralized applications (dApps), have proposed a new type of blockchain consensus algorithm called delegated Byzantine Fault Tolerance (dBFT).

As NEO’s new consensus mechanism, dBFT has been derived from the classic Byzantine Generals' Problem. Filip Martinsson, co-founder at Stockholm Blockchain, explains that this problem involves “a group of Generals trying to invade a city and the success of this invasion” depends on “all of the Generals acting in the same fashion.” For instance, if all the Generals plan an attack on a city, then that could potentially be successful. Alternatively, if all the Generals decide to retreat, then that might also be successful.

Byzantine Generals’ Problem: Dealing With Dishonest Actors

However, we need to consider the possibility that if all Generals made a plan to attack the city and one General was lying, and “instead of attacking the city, that General or his or her army left,” Martinsson notes. He points out that this would “pose a problem to the army as a whole because now they are not working in a unit.” As a result, the invasion might not go as planned and this “can be exploited by the enemy.” In order to address this problem, there are a few issues we need to deal with, Martinsson states.

First of all, Martinsson argues it’s possible that the Generals lie about their intentions. They might “say one thing and do another.” For example, “they can say that ‘I’m voting [in favor of] invading the city and so is everyone else.’” Instead, they can decide to retreat with their army. Another potential problem, Martinsson mentions, may occur with the couriers. Because these “Generals are spread out around the city,” messages need to be sent (from one General to another) using a courier.

Couriers Responsible For Reliably Sending Messages Between All The Generals

Each General can make their own decision regarding what they want to do, and they also need to convey their plan of action to the other Generals. In order to communicate with the other Generals, there are people designated as couriers who carry messages on the battlefield between all the Generals, Martinsson explains. He adds that it’s possible that the couriers may be corrupt because they may not always tell the truth.

Dishonest couriers could potentially “mislead” some of the Generals by telling them to attack a city or enemy - while all the other Generals are actually retreating. This may result in a lot of casualties on the battlefield and also “the failure of the invasion.”

Realizing The Byzantine Generals’ Problem On Decentralized Crypto Networks

These same types of problems can occur on decentralized computing networks where there are many nodes communicating with each other and processing transactions, Martinsson notes. He mentions that there’s a risk of having faulty nodes or “untrustworthy” nodes on a blockchain network. We must consider the possibility of a node acting dishonestly by not “telling the truth” or not conveying an important message to the other nodes on the network. These types of issues can be solved in many different ways, Martinsson says.

Distributed systems developers currently use various consensus algorithms such as proof-of-work (PoW), proof-of-stake (PoS), delegated proof-of-stake (DPoS), among others, to manage blockchain networks. NEO’s newly developed delegated Byzantine Fault Tolerance (dBFT) consensus protocol is similar to DPoS in that each user on the NEO blockchain is able to choose delegates, Martinsson explains. He adds that users vote for and appoint delegates that represent their interests (like a democracy).

Stakeholders, or users who hold the native cryptocurrency of a blockchain network, have a certain interest in the platform. For example, Martinsson notes that those who have a stake in a blockchain platform would want the system governing the network to be honest. In order to maintain the integrity of the blockchain network, users try to vote for delegates they think would be truthful and “represent them in a good way.”

Speakers Are Randomly “Drawn From A Group Of Delegates”

After the delegates have been appointed, they start “voting on the truth,” Martinsson explains.

He also points out that on a blockchain-based cryptocurrency network, this means that delegates are voting on which blocks are valid (contain a legitimate set of transactions) and which blocks may be corrupt. Each time a new block is generated on the blockchain, a speaker is “randomly drawn from the group of delegates.” Once the speaker has been chosen, he will proceed to propose a new block as “the truth” to the other delegates.

He goes on to explain that at least 66%, or two thirds of the delegates, will then have to “approve” the block that was proposed by the speaker. After a block has been approved, the set of transactions associated with that particular block will be processed, Martinsson adds. However, if 66% (or more) delegates do not approve the block a speaker recommends, then that block is discarded. After this, a speaker “goes back to being a delegate,” the co-founder at Stockholm Blockchain notes.

Speakers Propose Blocks (For Validation) To Delegates

When the approval process of the next block is initiated, a new speaker is randomly chosen from the pool of delegates. The appointed speaker then proposes a block that they think should be processed on the network. This newly appointed speaker may have “a different truth” which they are proposing to the delegates.

He continues to note that if at least 66% of the delegates decide to approve the block recommended by the speaker, then that particular block is processed and the transactions associated with it are recorded on the blockchain. However, if at least two thirds of the delegates do not approve, or agree, to process the block, the same cycle (as described) keeps repeating itself.

Potential Blockchain Governance Problems: Delegates Could Be Dishonest When Voting On Speaker’s Proposal

Some potential problems in this type of blockchain governance include delegates being dishonest when voting on the speaker’s proposal.

For instance, a delegate might receive a proposal for a new block and they might mislead the network’s participants into thinking a block is valid even though they know the block is corrupt, or faulty.

Developers of the dBFT algorithm assume that only a minority of delegates will act dishonestly, Martinsson explains. Based on this assumption, a corrupt or faulty block will not be chosen and will be discarded. Responsible users of dBFT-based crypto networks “need to find out which delegate is not trustworthy, which delegate is lying to us, and which delegate is misbehaving with their vote,” Martinsson states. Knowing which delegates are honest and which ones are acting maliciously helps users decide which delegates they should choose to represent them.

Another potential problem that may occur on a blockchain network (that uses dBFT as its consensus mechanism) is having dishonest speakers. This means that the node which proposes the new block could be proposing a faulty block. In this case, we “need to rely on delegates to vote [the corrupt or faulty] block down.” In order to ensure that a faulty block is not approved, the majority (or 66%) of delegates must act honestly. If a delegate misbehaves, they must be replaced so that the blockchain network can function reliably.

NEO’s Latest Version Of dBFT Has Been Released

On March 14th 2019, Erik Zhang, the co-founder of NEO, announced that the development of NEO’s dBFT version 2.0 had been completed (according to a specification document) and that the NEO command line interface (CLI) version 2.10.0 had been released. Zhang also revealed that the latest version of NEO’s dBFT algorithm would be deployed to the platform’s testnet. If the newly implemented consensus protocol works properly on the testnet, then NEO’s developers will activate the latest dBFT consensus mechanism on the smart contract network’s mainnet.

Comments
CryptoCompare needs a newer browser in order to work.
Please use one of the browsers below: