PBFT Visualization

Blockchain

What is Blockchain?

Blockchain is a decentralised and distributed system that has a continuous list of transactions stored in blocks in a linked list format. Each block contains a hash of the previous block, a timestamp and transaction data. Blockchains are managed by individual nodes, generally referred to as Replicas. These nodes internally follow different protocols to communicate and validate new blocks.

Blockchain Protocols

There have been many Byzantine fault tolerant consensus protocols (BFT) proposed over the years to result in better throughput and latency. In real world, adversarial attacks are a real concern and hence for a reliable consensus protocol it is very important to have higher resilience to faulty/byzantine behaviour of nodes.

Blockchain Applications

Cryptocurrency - Major applications build on blockchain technology such as Bitcoin, Etherium etc.

Financial services - Many banks are investing to use distributed ledger for banking by creating private blockchains for increase in efficiency along with reduction in cost

Supply chain - Retailers and consumers can use blockchain technology to track their products from warehouses to stores. Many retailers have started building backend blockhain system to manage their supply chain.

PBFT (Practical-Byzantine-Fault-Tolerance) Protocol

PBFT consensus protocol is the most basic BFT protocol based on voting which was proposed in the late 90s. It was designed to be able to tolerate a fixed fraction of malicious nodes in the network and still be able to reach consensus on a transaction proposed.

Algorithm Design

PBFT protocol is executed with a number of nodes ‘n’, where n>=3f + 1 and f is the number of byzantine nodes. One of the nodes acts as the primary node with some additional responsibilities. When the client sends a digitally signed transaction to a primary replica (which is elected by all other replicas in the block chain), it is responsible to coordinate, assign sequence number and send the ordered requests to all the other nodes called replicas (R1, R2 and R3). This phase is known as the ‘pre-prepare phase’. Now all the replicas send the pre-prepare message they received from primary to all the other replicas (including the primary node). This phase is known as the ‘prepare phase’. By the end of the prepare phase, all the good replicas would be able to know that the majority of other replicas have received the same transaction as they did and hence go ahead and prepare themselves for the commit. All the good replicas now create a ‘prepare certificate’ and send it to all the other replicas (including the primary). Hence, by the end of the commit phase if the majority of replicas send the same prepare certificate, all the good replicas will know that not only is there a majority of replicas who have received the same transaction but all the other good replicas have also sent the same prepare certificate. Hence consensus is reached for the given transaction, so replicas go ahead and execute the transaction and all the replicas including the primary reply to the client acknowledging the transaction.

Pbft

View Change

If the majority replicas didn’t send the same transaction by the end of prepare phase as the one a particular replica did (For e.g.: R1), R1 detects that primary is faulty and does not send the prepare certificate and instead it sends a view change request to replace the existing primary. Hence whenever there is some malicious behaviour of primary detected, nodes send view change requests. When enough votes representing majority (2/3rd) are received for view change, the existing primary is replaced with a new primary and the process repeats until an honest primary is elected and is working properly.

Advantages and Applications

Tolerates a fixed fraction of byzantine behaviour in the network which makes it reliable
Risk of centralization is removed and lower energy utilization to add a new block
Cryptocurrency platforms such as 'Zilliqa' use PBFT along with PoW consensus.

To overcome the drawback to scalability due to communication overhead of O(n^2), many new variants of PBFT have been proposed such as Zyzzyva, RBFT which were build on top of the traditional protocol.

Visualization Design

Technical Approach

Details on the 2-tier architecture of the dashboard developed

ResilientDB

Research on ResilientDB using Docker and Google Cloud Instances

Open source PBFT

Building visualization on an open source PBFT protocol

PBFT Protocol Visualization

Roadmap

Would like to know how PBFT-Visualization project was developed by our team?

29th Sep 21 - 4th Oct 21

Project Topic Selection

Team came up with the idea to develop visualization of existing BFT protocol to help users understand the working of the protocol. Initial plan was to develop visualization on ResilientDB dashboard built on top of ResilientDB PBFT implementation.
5th Oct 21 - 20 Oct 21

ResilientDB-Docker POC Work

Team started to set up and understand the flow of ResilientDB dashboard from frontend to backend. Tried to establish connection between docker container from a host using python docker packages.
21th Oct 21 - 29 Oct 21

ResilientDB-Google Cloud Instances POC Work

Since using Docker to get the data to build front end was getting complicated, we shifted our analysis to Google Cloud Instances. Team started to connect to instances through the host to understand how the underlying bash scripts work. But considering the timeframe ahead for completion of this project, the team parallely started to look for independent stable open sourse PBFT implementations.
30 Oct 21 - 30 Nov 21

Build Visualization on open source PBFT implementation

With continued parallel learning of hosting ResilientDB dashboard using GCPs, team started to work on building visualization on top of an open source PFBT implementation from GitHub. Team was divided to work on front end, back end and blog development.
Future
Work !!
Possible future work on top of existing application
- Simulation of the byzantine behaviour
- Extending the existing visualization to other open source BFT protocols
- Scaling up visualization when number of replicas is too large