ResView: A PBFT visualizer based on the ResilientDb blockchain fabric
A novel PBFT graphical visualizer based on the ResilientDb sustainable blockchain fabric.
1. Abstract:
1.1 What is ResView?
Seeing the tremendous growth in the field of decentralised computing [1], it is necessary to have tools that enable visualisation of the various processes, workings, and protocols required in the functioning of such complex systems.
This project aims to develop precise visualisation aids for any distributed database system that works on a consensus protocol.
ResView is a graphical visualizer for simulating the Practical Byzantine Fault Tolerance, or PBFT, consensus protocol [3] developed on top of the ResilientDb [2] fabric developed by the Exploratory Systems Lab and the Department of Computer Science, UC Davis.
1.2 Why?
We believe that as decentralised systems become more widely used, the demand for visual parametric process tools will skyrocket. A simple analogy would be a social media manager attempting to meet the needs of their clients without the assistance of fancy UI dashboards and data-driven analytical tools. Consider how much more difficult it will be to determine user interaction or whether a post has had the desired impact if APIs that return raw JSON data are used instead of precise graphs and visual drawings, which increase data understanding, system monitoring, and, overall, make the process much faster.
Our aim is similar. Imagine a single source from which you can observe the operation of an entire decentralised system. Being able to monitor system vitals, look for malicious and thus predictable behaviour, and react appropriately based on the desired outcome. ResView aims to take a small step towards developing visual tools for decentralised distributed systems by creating novel libraries for UI/UX-based apps on a wide range of data and protocols.
In this article, I will be talking about some of the tools we have created to visualise the famous consensus protocol: Practical Byzantine Fault Tolerance, or PBFT [3], which is used to derive a common consensus between distributed systems in order to execute a transaction even if 1/3 of the system is faulty or malicious.
1.3 Tools?
The first tool is a novel PBFT graph developed using d3.js which visualizes the workings of the creation and execution of a consensus between distributed replicas. Furthermore, this graph allows the user to see the location of the fault, the malicious node, transference of requests/responses and overall derivation of the consensus between n nodes or replicas of a system.
The second and third tool are line graph visualizers to show the count of messages received by replicas and their respective timestamps. The timestamps start when a replica is first able to send messages.
2. Theory:
2.1 General Theory:
PBFT is a consensus algorithm that allows nodes in a distributed system to reach agreement on the state of the system even when some of the nodes, called Byzantine nodes, behave arbitrarily.
It works in rounds, with a leader node proposing a value to be agreed on. The other nodes then vote to approve or reject it in subsequent rounds until a decision is definitively reached. Specifically, in the pre-prepare phase, the leader or primary sends a pre-prepare message with the proposed value. In the prepare phase, nodes broadcast that they are prepared to agree on that value. In the commit phase, a node sees enough prepared messages to commit to the value. Once a node has committed, it announces this and will never agree to another value.
As long as fewer than one-third of nodes are Byzantine, PBFT guarantees safety and liveness, so the non-faulty nodes will reach consensus on the same committed value despite failures.
2.2 Working Example:
In the above figure 2.1, we can see that a client sends its request to a system with four nodes, or replicas. Node 0, acting as the primary, sends a pre-prepared message with the proposed value to the other three nodes.
In the prepare phase, all nodes except node 3 reply to all other nodes to show that they are prepared to agree on the value and subsequent transaction. In this scenario, node 3 acts like a faulty or malicious node that does not reply in the prepare phase.
Furthermore, in the commit phase, all nodes check whether they have received messages from other nodes. If n ≥ 2/3 of nodes, then a positive consensus has been received between the distributed nodes, and each node commits its value, which guarantees that it will not accept any other value.
Finally, all non-faulty nodes reply to the client with the agreed-upon value.
Note: The term “node” and “replica” are used interchangeably in this article.
3. Architecture:
3.1 Overview:
The application is based on a common architecture, which includes splitting the front end and the back end.
The technologies used for FE are as follows:
- React.js: App responsiveness, contexts, memory
- D3 and Nivo: Visualisation
- Websockets: real-time communication with BE
- Tailwind: Application Design and Styling
The technologies used for BE are as follows:
- ResDb Python SDK: For APIs
- C++: Development of the Server
An application’s UI/UX can make or break it [4]. Keeping this in mind, we have worked on developing a bespoke UI for the application. Our app supports light and dark modes, graph resizing, front-end node computation, separation of contexts, and data customizability.
3.2 Working:
The user interacts with the ResilientDB architecture through transaction forms or simulation buttons to simulate different edge cases.
3.2.1 Transaction Forms:
Within the transaction forms, users choose whether to perform a SET or GET transaction and enter the appropriate data fields, key and value, or just key. Once confirmed, this transaction is routed through Axios to the SDK, which verifies it and sends it to the ResilientDB backend, where it is processed and executed.
3.2.2 Simulation Buttons:
When the faulty buttons are pressed, they send a signal to the corresponding replica, instructing it to reject any transactions it receives, simulating a replica that cannot receive messages. Prior to this addition, there was no way to cause a replica to be faulty, making this a useful addition for testing various cases and potential situations that ResilientDB may encounter.
3.2.3 Data Structures and Communication:
In addition, we used static data structures to collect the contents of transactions from ResilientDb, which included timestamps for when each state was reached and when messages were received.
These statistics are then grouped into JSON and sent to the front-end application. The data is collected in this manner to allow ResView to generate visualisations without access to log files, as well as to gather information regardless of who initiated the transaction.
3.3 PBFT Graph:
To simulate a PBFT graph, we created a custom visualizer based on d3.js. All the phases of PBFT consensus are shown for each node, including the client. A malicious or faulty node will not show process arrows from it to other nodes, hence confirming its fault. The JSON data is processed in the FE in order to match each node with respect to the other nodes it is going to be contacting via arrows for each phase.
Furthermore, each graph can be custom-resized in real time, and loaders are provided during computation so as to have smooth UI transitions.
3.4 Messages vs Time Graph:
We have developed two graphs, viz., Number of Commit Messages vs. Time and Number of Prepare Messages vs. Time, to visualise each replica’s message collection with respect to the time elapsed. The UI is based on chart.js, which includes auto-scaling, tooltips, and multi-coloured data lines.
The timestamps begin when a replica is first able to send messages, and the message collection times are relative to that. The goal of displaying lines from each replica is to allow you to easily compare the rates at which replicas collected messages in order to understand their relationship and identify any potential message collection issues. To focus on specific replicas, the user can toggle the lines of any replica, reducing the amount of data displayed on the graph.
3.5 Video Demo:
Below is a video demonstration of the project:
4. Usage:
- The target userbase is made up of developers who want to observe the status of ResilientDB and the rate at which various ResilientDB processes are occurring, such as message collection.
- Furthermore, people learning about ResilientDB want a better understanding of how the PBFT consensus protocol works and the general flow of blockchain consensus.
5. Future Work:
- Creation of novel libraries to make visualization data and fabric independent
- Increased interactivity between data and graphs
- Cloud deployment
- Dynamic scaling of ResDb to n replicas
- Look-up history with BE data stores
6. Credits & Contributions:
Designed and Developed by:
The ResView Team
@ The Department of Computer Science & The Exploratory Systems Lab
@ University of California, Davis | Fall ‘23
Check out the source of this blog on ResDb here.
Sources:
[1] Libardi, Filippo. (2020). The Rise of Decentralised Systems. 10.13140/RG.2.2.18626.30406
[2] ResilientDB: A Global-scale sustainable blockchain fabric
[3] Castro M. and Liskov B. (1999) Practical Byzantine Fault Tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation
[4] Pratama, Tama & Cahyadi, A. (2020). Effect of User Interface and User Experience on Application Sales. IOP Conference Series: Materials Science and Engineering. 879. 012133. 10.1088/1757–899X/879/1/012133.
