2 Samarkand branch Tashkent university of information technology, Uzbekistan The process of digitalization of the Russian economy as the basis for the transition to the digital economy is conditioned by the requirements of objective reality and is based, first of all, on the introduction of digital technologies into the activities of its actors. The most promising is the Blockchain technology, which has the capabilities of the most effective coordination of the economic interests of the actors of the digital economy and is applicable in various spheres of economic activity. The article discusses the basics of cryptocurrencies and blockchain operation, as well as the technologies in which this "Tasks of Byzantine generals" (decision-making tasks) occurs. A comparison is made for solution of the problem with different blockchain technologies with several platforms that prevent behavior dangerous for transactions network and thereby increasing the competitiveness of the cryptocurrency.
In recent years, e-commerce has played an important role in modern economic life as a new
form of platform. It developed rapidly due to its characteristics of openness and efficiency [
In a private blockchain network, all the participants are whitelisted and bounded by strict
contractual obligations to behave “correctly”, and hence more efficient consensus protocols such as
Byzantine Fault Tolerance (BFT) can be used. BFT works on the assumption that less than one-third
of the peers are faulty (f), which means that the network should consist of at least n = 3 f + 1 peers to
tolerate f faulty peers [
The PBFT version included only two phases: PrepareRequest and PrepareResponse. This was a necessary simplification due to the high communication costs and inherent efficiency issues faced by the first prototype. The removal of the third phase made it possible to reach consensus much faster, which is especially necessary in a P2P network with the possibility of high delays. In practice, this demonstrated how strong the opponent is, according to (A.2). We start by demonstrating three “good cases” for PBFT: (a) no replica is faulty (Fig. 1); (b) one replica is faulty, but not the primary one (Fig. 2) (c) the primary one is faulty, review of changes is required (Fig. 3).
The reason for this was simple: some primary node could end up offering a valid block, receiving support from a sufficient number of nodes (at least 2f + 1), but these same nodes could only receive messages from each other after a long time. This will cause the view to change as the given timeout has expired for that view (at least for the 'M' replicas), so the other backup will become the primary and offer another valid block for the same height, again getting enough signatures from their peers ( at least 2f + 1). This situation is shown in figures 4 and 5
Within each cluster, a variable leader is determined, which changes after several rounds of
voting [
PFT prevents double-spending attacks due to intra-cluster voting time differences and DAG timing (state) timing, which is done through permalinks.
The solution to the problem was obvious: BFT required a third phase. It was clear that block signatures could not be represented on the network before the replica was sure that other nodes would follow, otherwise several valid blocks could be generated at each height (as shown in Figures 4-5). This issue stems from an adversarial condition where Byzantine agents can aggregate signatures (#H) σ i from 2f + 1 replicas (sent in response to preparation), which allows a valid block #H to be created even if all 2f + 1 replicas i are finally resolved retransmit #H 0 after view change. An interesting feature of this problem from a practical/applied point of view is that it only happened in the end (several times a year), even in a blockchain with systematic block generation (15s on average). Given that all replicas are healthy, only a very “bad” combination of latency can lead to this scenario. From a theoretical point of view, the problem is easy to reproduce.
Note that the time it takes to send a block commit event from the ID is considered negligible for the subscriber since they are both on the same virtual machine and as such there is no network latency. The transaction scheduler can be either sequential or parallel. When using sequential execution of a transaction, it is blocked until the execution of the previous transaction is completed; with parallel scheduling of transactions, the subsequent transaction that does not have dependencies on the current transaction can be executed in parallel with the current transaction sent for execution.
The research purposed in this paper is to optimise the performance of the blockchain PBFT consensus mechanism applied in the supply chain scenario. Therefore, to achieve the improvement of the system’s delay, throughput and other performance with less time consumption. The research work in this area has great scientific research significance and engineering application value. This article mainly starts from the current research status of PBFT consensus mechanism, introduces the current research results of PBFT consensus mechanism. It aims at its current weak link in the blockchain system.
We made a series of tests to eliminate errors and our recommendations were passed on to the
DGT developers to add a new version of the platform. The next steps are to repeat the experiments for
different consensus algorithms [