Practical Byzantine Fault Tolerance (PBFT) - Consensus Mechanism of Blockchain

PBFT mainly focuses on the state machine. It replicates the system but gets rid of the main Byzantine general problem. Now, how does it do that?

Well, the algorithm assumes from the start that there could be possible failures in the network and some independent nodes can malfunction at certain times.

The algorithm is designed for asynchronous consensus systems and further optimized in an efficient way to deal with all the problem.

Moreover, all the nodes inside the system gets arranged in a specific order. One node is selected as the primary one, and others work as the backup plan. However, all the nodes inside the system work in harmony and communicate with one another.

The communication level is pretty high because they want to verify every information found on the network. This gets rid of the unreliable information problem.

However, with this new process, they’re able to find out if even one of the node gets compromised. All of the nodes reach an agreement through majority voting.

The Benefits of PBFT Consensus Algorithm

Practical Byzantine Fault Tolerance algorithms share some interesting facts with us. The model was primarily designed for practical use cases, and they are extremely easy to implement. Thus, PBFT possesses a certain advantage over all other consensus algorithms.

No Need for Confirmation:

The transactions on this network work a bit differently. It can finalize a transaction without any type of confirmation as we see in the PoW system.

If the nodes agree on a specific block, then it gets finalized. This is due to the fact that, all the authentic nodes communicate with each other at the same time and come to an understanding of the specific block.

Reduction in Energy: The new model offers a good amount of reduction in consumption of power than PoW. In the PoW, every block needed individual PoW round. However, in this model, not every miner is solving the typical hashing algorithm.

That’s why the system doesn’t need that much of computational power.

Drawbacks of the System Although PBFT provided a lot of advantages and promising facts, still it happens to have quite a lot of disadvantages. Let’s see what they are.

Communication Gap: The most important factor of this algorithm is the communication among the nodes. Every node on the network has to make sure that the information they gather is solid. However, the Consensus algorithms only happen to work efficiently for a smaller group of nodes.

If the group of nodes increases to a great extent, the system may find it hard to keep track of all the nodes and can’t communicate with every single one of them.

The paper is backing this model up states to use MACs and other digital signature to prove the authenticity of the information. That being said, MACs aren’t capable of handling the blockchain type network system, so using it would be a significant loss at the end.

The digital signature can be a good point but maintaining security with all these communication nodes would become harder and harder as the number of the node will increase.

Sybil Attack:

PBFT is quite vulnerable to Sybil attacks. In these attacks, they can manipulate a group of nodes together, and by doing so, they compromise the whole network. This also gets far worse with larger networks, and the scalability of the system gets reduced.

If one can use this model with another consensus algorithms, then they will probably get a solid secured combo.

Simplified Byzantine Fault Tolerance (SBFT)

In SBFT, the system works a bit differently.

First, a block generator will collect all the transaction at a time and validate them after batching them together in a new type of block.

In simple terms, a block will gather all the transactions, batch them accordingly into another block and then finally validate all of them together.

The generator applies certain rules that all the nodes follow to validate all the transactions. After that, a block signer will validate them and add their very own signature. That’s why if any of the blocks miss even one of the keys then it will get rejected.

Different Stages of Simplified Byzantine Fault Tolerance

• The stage starts with the creation phase, where the asset user will produce a greater number of unique asset IDs.
• After that, in the submission phase, the user submits all the IDs on the platform.
• Then begins the validation phase, where the IDs get specified terms of use cases.
• Once they are all signed up, they will get stored and transferred to different accounts. The transactions could happen with the help of smart contracts.
• Lastly, the transactions become live.

Another cool feature of this awesome system is the Account manager, which helps in many stages. The primary target is to store all the assets securely. Account manager also stores all the transactional data. The manager can contain all sorts of combinational assets for different types of users.

You can think of these as digital wallets. Using these digital wallets, you’ll be able to transfer your assets from the wallet and even receive some of them in return. You can also use the account manager to form the smart contacts, and when the specific requirement gets met, it releases the funds.

But how does the ownership of assets flow? 

Well, they actually use a push model that contains addresses and Assets ID to send them their earned asset.

Security and Privacy

SBFT is for a private network where confidentiality is the priority of the network. The platform was designed in a fashion to expose sensitive information but with certain limitations. That’s why the system uses three types of techniques, such as Zero-knowledge proofs, one-time use addresses, and encrypted metadata.

One Time Use Addresses:

Every time a user wants to receive some assets in his/her wallet, they will be assigned one-time use addresses. Every address differs from each other and thus, prevents any other user to intercept with the transaction.

Zero Knowledge Proof:

Zero knowledge proof is used to conceal all the components of a transaction. However, the entire network would still be able to validate the integrity. This gets done with the help of Zero-Knowledge Proofs where one party will prove their authenticity to another party.

In this way, only the receiver and the sender will be able to see the components of the transaction.

Metadata Encryption:

The metadata of the transitions is also encrypted to ensure further security. The network will allow the usage of keys to validate the authenticity. However, for better protection, the keys will alter every 2-3 days.

Also, all of them are kept separated and on different parts of the data network. So, if one of them gets hacked, one can use other keys to generate more unique keys. Managing these keys and rotating them every few days is necessary for ensuring the integrity of these consensus algorithms.

Chain, a blockchain based platform uses SBFT to validate all of their transaction on the network. Other than that, they are also using an HSM (Hardware Security Module) for an industry level security. By using HSMs, they ensure extra security without the need for any single point failure.

Delegated Byzantine Fault Tolerance (dBFT)

There is no debate on the fact that Proof-of-Work and Proof-of-Stake are the most widely known consensus algorithms. While a lot of the blockchain ecosystem follows these two common algorithms, some are trying to impose newer and more advanced consensus systems. Among these pioneer blockchain brands, NEO’s name is sure to come.

With the thriving growth in the last 12 months, NEO is now the hotcake in the industry. The Chinese brand has shown quite the potential. And why wouldn’t they? They are the inventor of the advanced consensus theorem – Delegated Byzantine Fault Tolerance (dBFT).

A Popular Blockchain Technology: NEO

This is one of the popular cryptocurrencies on the market now. It’s sometimes referred to as China’s Ethereum. The primary focus of the network is to create a smart economy where are you can share your digital assets at a low price.

NEO uses Delegated Byzantine Fault Tolerance to validate all the transactions. If you stake your NEO, you will able to generate GAS. GAS is the platforms main circulating currency. You will have to pay up to a certain amount of GAS fee for every transaction. That’s why the more NEO you will stake, the more GAS you will get.

However, this staking is a bit different than PoS.

Many exchanges offer a pooling system. However, it’s best to use the official NEO wallet instead of another storage wallet.

Before we begin our analysis on the dBFT, we must let you know the faults of the father of this algorithm – Byzantine Fault Tolerance consensus algorithm.

The Flaws of Byzantine Generals!

A major flaw of the system occurs when we witness any kind voting and the outcome of it. But how? To understand the fault better, you need to grasp this following consensus example.

You already know that the nodes that follow the dBFT consensus algorithms are known as the army. An army of nodes have a single general, and they follow the command of their general always.

Now imagine, the Byzantine army is planning to attack Rome and take it over. Let’s consider there are nine generals of the Byzantine army and the generals have surrounded the city and prepared to attack! They can take over Rome only if the generals plan to attack or retreat following a unified, single strategy.

Here’s the catch! The generals have a unique nature – they will follow the decision that has 51% majority regarding vote. There is another twist here; the generals are not taking decision sitting a table. Instead, they are positioned in different locations and use couriers to transfer messages.

The Four Threats!

Four possible ways could help the Romans to retain their throne –

First, the Romans could try bribing the generals and gain their favor. The general who would take the bribe will be considered as a “Traitorous General.”

Second, any general could take a wrong decision that is against the collective will. These generals are better known as “Improperly Functioning General.”

Third, the messenger or the courier could take bribes from the Romans and deliver misleading decisions to the other generals.

And lastly, fourth, the Romans could kill the courier or the messenger to sabotage the communication network of the generals.

So, the Byzantine Fault Tolerance has four significant faults that make the consensus algorithms imperfect.

How Delegated Fault Tolerance (dBFT) Changes the Scene?

Don’t take a sweat; NEO has shown us a better way to solve the faults of the Byzantine generals. Now let’s take a look at that Delegated Byzantine Fault Tolerance of which NEO is so proud of! The dBFT mainly focuses on solving the existing model in two ways – better scalability and enhanced performance.

 The Speakers and the Delegates!

We will again use another example to clarify the model of dBFT. Let’s consider that the Byzantine army has an elected leader rather than a bureaucratic general. This chosen leader will act as the delegate of the band of the army.

You could think of the generals being replaced by these elected delegates democratically. Even the army can disagree with these delegates and choose another delegate to replace the prior one.

This limits the bureaucratic power of the generals, and no general could betray the overall army. So, the Romans now cannot just bribe and buy the generals to work for them.

In dBFT, the elected delegates have to keep track of the decisions of the individual nodes. A decentralized ledger notes down all the decisions of the nodes.

The army of nodes also elects a Speaker to share their common and unified thought to the delegate. To pass a new law, the Speakers share the idea of the army of the nodes to the delegates, and at least 66% of the delegates have to agree on the motion. Otherwise, the proposed law will not pass.

If a motion doesn’t get the approval of the 66% of the delegates, the proposal gets denied, and a new motion is proposed until they reach to a consensus. This process protects the whole army from traitorous or the betraying generals.

The Dishonest Speakers

There are still two possible scenarios that could hamper the integrity of the dBFT blockchain consensus protocol – a dishonest speaker and a dishonest delegate.

The dBFT blockchain consensus protocol also gives us the solution to these scenarios. As we have said, a ledger keeps the decisions of the nodes in a single place. The delegates can verify if the speaker is truly speaking for the army. If the speaker’s proposal and the ledger don’t unite, the 66% of the delegates will reject the speaker’s proposal and ban the speaker altogether.

The Dishonest Delegates

The second scenario has an honest speaker and probably betraying delegate. Here, the honest delegates and the honest speaker will try to achieve a 66% majority and diminish the efforts of the dishonest delegate.

So, you could see how the Delegated Byzantine Fault Tolerance (dBFT) overcomes the flaws of the Byzantine generals and the BFT consensus altogether. Surely, NEO deserves praise from all around the world for their effort to create a better consensus algorithm.

Platforms Implementing Optimized Versions of pBFT Today

Today, there are a handful of blockchain platforms that use optimized or hybrid versions of the pBFT algorithm as their consensus model or at least part of it, in combination with another consensus mechanism.

Zilliqa

Zilliqa employs a highly optimized version of classical pBFT in combination with a PoW consensus round every ~100 blocks. They use multisignatures to reduce the communication overhead of classical pBFT and in their own testing environments, they have reached a TPS of a few thousand with hopes to scale to even moreas more nodes are added. This is also a direct result of their implementation of pBFT within their sharding architecture so that pBFT consensus groups remain smaller within specific shards, thus retaining the high-throughput nature of the mechanism while limiting consensus group size.

Hyperledger

Hyperledger Fabric is an open-source collaborative environment for blockchain projects and technologies that is hosted by the Linux Foundation and uses a permissioned version of the pBFT algorithm for its platform. Since permissioned chains use small consensus groups and do not need to achieve the decentralization of open and public blockchains such as Ethereum, pBFT is an effective consensus protocol for providing high-throughput transactions without needing to worry about optimizing the platform to scale to large consensus groups.

Additionally, permissioned blockchains are private and by invite with known identities, so trust between the parties already exists, mitigating the inherent need for a trustless environment since it is assumed less than ? of the known parties would intentionally compromise the system.