=Paper=
{{Paper
|id=Vol-3041/592-596-paper-109
|storemode=property
|title=Comparative Analysis and Applicability Determination for Several DLT Solutions
|pdfUrl=https://ceur-ws.org/Vol-3041/592-596-paper-109.pdf
|volume=Vol-3041
|authors=Alexander Bogdanov,Vladimir Korkhov,Nadezhda Shchegoleva,Valery Khvatov,Nodir Zaynalov,Jasur Kiyamov,Aleksandr Dik,Anar Faradzhov
}}
==Comparative Analysis and Applicability Determination for Several DLT Solutions==
https://ceur-ws.org/Vol-3041/592-596-paper-109.pdf
Proceedings of the 9th International Conference "Distributed Computing and Grid Technologies in Science and
Education" (GRID'2021), Dubna, Russia, July 5-9, 2021
COMPARATIVE ANALYSIS AND APPLICABILITY
DETERMINATION FOR SEVERAL DLT SOLUTIONS
A. Bogdanov1, V. Korkhov1,3, N. Shchegoleva1, V. Khvatov4, N. Zaynalov2,
J. Kiyamov1, A. Dik1, A. Faradzhov1,a
1
St Peterburg university, Russia
2
Samarkand branch Tashkent university of information technology, Uzbekistan
3
Plekhanov Russia university of economics, Russia
4
DGT Technologies AG, http://dgt.world/
E-mail: a st069744@student.spbu.ru
Abstract: 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).
Keywords: Byzantine Fault Tolerance problem, distributed ledger technology, multiround
voting protocols
Alexander Bogdanov, Vladimir Korkhov, Nadezhda Shchegoleva, Valery Khvatov,
Nodir Zaynalov, Jasur Kiyamov, Aleksandr Dik, Anar Faradzhov
Copyright © 2021 for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
592
Proceedings of the 9th International Conference "Distributed Computing and Grid Technologies in Science and
Education" (GRID'2021), Dubna, Russia, July 5-9, 2021
1. Introduction
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 [1,2]. The proliferation of cloud
services has sparked interest in highly scalable blockchain systems, their capabilities and applicability
in various business environments.
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.
2. Considered platforms
Hyperledger Sawtooth [3] is built to be an open source distributed ledger for the modern
enterprise. Unlike many popular blockchains, Sawtooth is not built for cryptocurrency, but instead for
business supply chain management. The transaction flow begins with the client placing all transactions
into a block, and then signing the batch and sending it to a validator. The validator uses its transaction
processor to ensure the integrity of the batch, and then commits it. Sawtooth executes transactions in
parallel, instead of in serial, when possible through a REST API to improve performance. It also
contains the novel feature of being modular, which includes consensus algorithms, rule sets, coding
language, and smart contracts. This allows it to efficiently change depending on the business need.
Programmers can use Python, JavaScript, Go, C++, Java, and Rust to build and interact with the
Sawtooth blockchain. Currently, four different consensus algorithms are supported by Sawtooth.
These are Dev_mode, PoET, RAFT and PBFT. Dev_Mode is a random generator algorithm used
purely for developer testing. Proof of Elapsed Time (PoET) is built specifically for Sawtooth and does
not follow byzantine fault tolerance (BFT), allowing it to reach higher throughput than other models.
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. [4].
593
Proceedings of the 9th International Conference "Distributed Computing and Grid Technologies in Science and
Education" (GRID'2021), Dubna, Russia, July 5-9, 2021
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 [5]. This is a classical four-stage election-style Byzantine fault tolerant algorithm.
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 nearly-
independent clusters).
3. Testing
3.1 Configuration
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.
3.2 Scenarios
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:
594
Proceedings of the 9th International Conference "Distributed Computing and Grid Technologies in Science and
Education" (GRID'2021), Dubna, Russia, July 5-9, 2021
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.
Tests were taken in five different configurations:
One cluster of 6 nodes,
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.
3.3 Metrics
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).
3.4 Results
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.
595
Proceedings of the 9th International Conference "Distributed Computing and Grid Technologies in Science and
Education" (GRID'2021), Dubna, Russia, July 5-9, 2021
Figure 1. Testing results
4. Conclusion
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.
References
[1] Jeffery, K., Kousiouris, G., Kyriazis, D., Altmann, J., Ciuffoletti, A., Maglo-giannis, I., Nesi, P.,
Suzic, B., Zhao, Z.: Challenges Emerging from Future Cloud Application Scenarios. Procedia
Computer Science. 68. 227–237 (2015). DOI: 10.1016/j.procs.2015.09.238
[2] Koulouzis, S, Martin, P, Zhou, H, et al. Time-critical data management in clouds: Challenges and
a Dynamic Real-Time Infrastructure Planner (DRIP) solution. Concurrency Computat Pract Exper.
2020; 32:e5269.(2019). DOI: 32.10.1002/cpe.5269
[3] Hyperledger Sawtooth repository https://github.com/hyperledger/sawtooth-core (Last accessed
15.06.2021)
[4] Lamport, L., Shostak, R., Pease, M.: The Byzantine general problem. ACM Trans. Programm.
Lang. Syst.. 4. 382-401. (1982)
[5] Castro, M., Liskov, B.: Practical Byzantine Fault Tolerance. In Proceedings of the third
symposium on Operating systems design and implementation (OSDI ’99).USENIX Association, USA,
173–186. (1999)
[6] BGX/DGT repository https://github.com/DGT-Network/DGT-Kawartha (Last accessed
17.06.2021)
596