Potential benefits of implementation of distributed ledger technology are widely discussed among different business actors and governmental structures. Within the last decade, with growing popularity of blockchain-based payment systems and cryptocurrencies, these discussions considerably sharpened. Therefore, an extensive body of research has emerged on this soil. The goal of this study is to attempt to make a comparative analysis of several existing blockchain-based distributed ledger platforms. Besides that, authors overview the most commonly used consensus algorithms and design approaches, as for any blockchain product, consensus algorithm is a crucial part which determines the performance of the overall system. Choosing the right algorithm would ensure high reliability and throughput, while the wrong choice could cause fatal malfunctions for the application. A suitable algorithm usually should be chosen according to the task in consideration, e.g. Nakamoto-style protocols could be considered better for public networks, while multiround voting protocols are more suitable for private and secure systems. The highest attention is paid to consensus algorithms based on the solution of the Byzantine Fault Tolerance problem (BFT).
Current business trends are aimed at integrating and further complicating the IT environment. In these conditions, the need for universal solutions that can meet higher security requirements and at the same time can be versatile and flexible has grown like never before.
To make matters worse, businesses today tend to migrate their infrastructure to the cloud. This
is understandable, despite all the difficulties that migration to the cloud entails, it helps to effectively
optimize operational costs, deployment costs and operating costs [
Unfortunately, there are still many obstacles to deploying blockchain in the cloud. The most notable of these is the performance instability of blockchain-based solutions in dynamic cloud environments, which is also exacerbated by the difficulty of identifying enablers.
The key role in managing this instability is played by the choice of the consensus algorithm that is most suitable for the considered purpose.
While the variety of different consensus algorithms is great, they all impose different costs and constraints on the participants. One well-studied approach to building consensus protocols is based on the solution to the Byzantine fault tolerance problem. This study focuses on comparing two DLT products based on different BFT algorithms: Hyperledger Sawtooth and BGX/DGT, which are very similar but use different BFT-based consensus protocols.
The special interest of authors is centered around novel Federated Byzantine fault tolerance protocol(F-BFT) which, as it is claimed, should outperform classical BFT algorithms, such as PBFT, in terms of horizontal scalability.
Within the framework of the current research we tried to estimate capabilities of the latest version of BGX/DGT’s consensus module based on FBFT. In order to do that we conducted several tests and compared BGX/DGT performance with the benchmark.
The results of conducted tests would help to reveal strengths and weaknesses of the particular F-BFT-based DLT and, therefore, to determine its applicability in the real systems.
Hyperledger Sawtooth [
BFT is a type of system’s behavior in case of a malicious actor. It can be defined as the
maximal fraction of faulty nodes the distributed system can tolerate. The basic theory behind this is
explained by Lamport et al. [
RAFT is an election-style leader-based algorithm where each node can become a leader candidate if it does not hear back from a current leader after a certain amount of time. Candidate then requests votes from other nodes, and if it gets more than half of the votes, it becomes a new leader. The leader also has the job of replicating the new log to all other nodes to maintain consistency.
The last consensus algorithm implemented in Sawtooth is PBFT which was proposed by
Castro and Liskov [
BGX/DGT [6] is a DLT solution based on the Hyperledger Sawtooth platform. It inherits most of the architectural and technological concepts used in Sawtooth version 1.1. However, BGX/DGT differs from the original Sawtooth in the most crucial ways. BGX/DGT doesn't imply consensus module plugability. It can use Federated Byzantine fault tolerance (F-BFT) algorithm only. F-BFT is the implementation of PBFT algorithm in networks with federated structure (a set of nearlyindependent clusters).
The following section presents test results for several scenarios that will inevitably occur during system normal operation. The testing was carried out in order to investigate the weak points of the current version of BGX / DGT in cases that are not specific to various fields of application, as well as to assess its competitiveness at the current stage of development.
The environment configuration was used for testing is listed below: OS: Fedora 28 CPU: Intel(R) Xeon(R) CPU E5-2690 v4, 2.60GHz RAM: 255 GB
Tests were conducted using Docker and Docker-compose. All metrics were measured using Docker tools, vnStat and embedded tools of Hyperledger Sawtooth.
Tested version of the product was Kawartha. A typical node in BGX/DGT network consists of several components: transactions processor validator module shell module consensus module settings module topology processor REST API module
Each component was run in a separate docker container to stay isolated from the others. Hyperledger Sawtooth was chosen as a benchmark for comparison. This choice was dictated by several reasons. Firstly, BGX / DGT is a modification of Hyperledger Sawtooth, so it inherits almost all technologies and concepts used in Hyperledger Sawtooth, with the exception of the consensus algorithm and transaction store. Secondly, Hyperledger Sawtooth has a pluggable PBFT consensus algorithm, which is the closest relative of the F-BFT consensus developed for BGX / DGT.
A bunch of tests for this study describe four different situations that can occur during system exploitation and does not include situations of intended attacks on cryptographic protection nor taking control over one or several nodes of the network by intruder:
Single transactions committing. During this test transactions were made one at a time from each node. The next transaction was not sent until the previous had been committed. Asynchronous streams of transactions committing. Transactions were sent in bunches of 100 from different nodes in different clusters (through one node in cluster at the same time). Simultaneous transactions committing test I. As in the second, transactions were sent in bunches of 100 from different nodes in different clusters, but this time streams were synchronized – transactions were sent simultaneously.
Simultaneous transactions committing test II. A bunch of 100 transactions were sent simultaneously from every node.
Two clusters of 6 nodes, Two clusters of 6 nodes and one cluster of 3, Two clusters of 6 nodes and two clusters of 3, Two clusters of 6 nodes and three clusters of 3.
It should be kept in mind that the first and the second clusters had 6 nodes, while the third, fourth and fifth consisted of 3 only, this configuration was static and had never been changed during testing.
The explanation of why only those five configurations were chosen to conduct tests is due to several technical issues of BGX/DGT which impose restrictions on scalability of the network. The second reason is the fact that such a size of the network and its scaling dynamics was enough to see differences between BGX/DGT and the benchmark, and to establish the most crucial shortcomings of the current version (Kawartha) of the product in consideration.
In order to unify terminology we assume that the benchmark also has the federated structure, therefore in new terms the first six nodes will belong to the first cluster, the second six to the second cluster, 13, 14, 15 nodes to the third, and the last 6 nodes will compose the fourth and the fifth clusters correspondingly.
The benchmark and BGX/DGT were compared using two main metrics: committed transactions per second (CTPS) and the average volume of network traffic on validator per transaction (VONT).
As It may be seen on diagram (Figure 1), in Test 1 the speed of committing standalone transactions for BGX/DGT is considerably higher then for Sawtooth PBFT, moreover, the dynamics of the traffic volume ingested by a single node for BGX/DGT is much flatter than for Sawtooth PBFT.
In case of higher loads, with the presence of several parallel transaction streams, results shown by BGX/DGT are much more ambiguous. CTPS shows that the throughput of the system does not rise when the load increases, while Sawtooth shows quite steady rising dynamics. Also, Sawtooth works much more efficiently in terms of VONT when the load increases. It might be happening due to different storage models that BGX/DGT and Sawtooth use to store transactions. While Sawtooth unites simultaneous transactions in blocks and stores them, BGX/DGT stores standalone transactions in its databases so it is unable to process more than one transaction at the same time.
Test 3 and Test 4 were completely failed by BGX/DGT - there were no committed transactions, therefore, results are not shown on the diagram.
In this article, we have presented the results of implementing multiple test scenarios on BGX / DGT and Hyperledger Sawtooth. As far as the results are concerned, the main areas of applicability of BGX / DGT Kawartha can be assumed. For now, this can be applied to highly distributed but lightly loaded systems. For higher reliability systems, Sawtooth PBFT is preferred.
Should be mentioned that BGX/DGT is in the active development currently, and weaknesses revealed in this research would be eliminated in the future. [6] BGX/DGT 17.06.2021) repository