An Asynchronous Consensus Algorithm Performance Testing System and Method

Abstract

The present invention provides an asynchronous consensus algorithm performance testing system and method. The present invention uses a parsing module to mobilize other modules to perform testing work, hiding the cumbersome testing process from users and realizing the automation of the testing process. The present invention also uses the deployment script in the deployment module to transmit the compiled file of the specified asynchronous consensus algorithm, making the deployment process more concise and better applicable to the newly implemented asynchronous consensus algorithm. The present invention proposes two forms of load, namely actual load and theoretical load, and analyzes the theoretical performance and actual performance of the consensus algorithm from multiple perspectives such as the two load methods, the uniqueness of transactions, network bandwidth usage, network latency and packet loss rate, and node downtime, more clearly showing the gap between the theoretical value and the actual value of the performance of the existing consensus algorithm. Finally, the present invention divides the monitored data into a transaction broadcast stage and a consensus transaction stage in the monitoring module, more effectively analyzing the performance bottleneck of the asynchronous consensus algorithm.

Description

Technical Field

[0001] The present invention belongs to the technical field of blockchain and relates to a system and method for testing the performance of an asynchronous consensus algorithm. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] As a disruptive technology, blockchain is used in various industries such as finance, Internet of Things, healthcare, energy and logistics. Compared with traditional centralized systems, blockchain has the characteristics of tamper-proof, fault-tolerant and transparent, but its distributed nature leads to relatively low system performance. The number of transactions within a set time is small, and each transaction has a relatively long confirmation time. In contrast, traditional centralized payment systems can generally achieve thousands of transactions per second and almost real-time transactions. It can be clearly seen that the performance problem of blockchain is the main problem that limits the application of blockchain to actual products.

[0004] Consensus algorithm is the main factor affecting the performance of blockchain. With the increasing attention paid to blockchain, faster consensus algorithms are being designed. At present, consensus algorithms are mainly divided into semi-synchronous consensus algorithm and asynchronous consensus algorithm. Semi-synchronous consensus algorithm mainly makes assumptions about network delay, and the algorithm has better performance but weaker activity; while asynchronous consensus algorithm does not make assumptions about network delay, so it is more robust but its performance is not as good as semi-synchronous consensus algorithm. At present, the research on asynchronous consensus algorithm is gradually increasing. Although the performance of asynchronous consensus algorithm has obviously exceeded that of semi-synchronous consensus algorithm in these studies, it has not been put into practical application. There are two main reasons: 1. At present, the performance data of asynchronous consensus algorithm is mostly theoretical performance data, and such high theoretical values cannot be achieved in actual scenarios. 2. The engineering implementation of asynchronous consensus algorithm is relatively complex and difficult to realize as an actual product.

[0005] At present, the performance data of asynchronous consensus will inevitably give researchers a false impression. A good performance testing system should be more convenient to use and provide multi-faceted and multi-dimensional test results for researchers.

[0006] In summary, the current testing systems for asynchronous consensus algorithms have the following problems: (1) Currently, the testing of asynchronous consensus algorithms only stays at the theoretical level, and there is very little research on actual performance, which is very unfavorable for the actual application of asynchronous consensus algorithms to the market. (2) Most of the existing testing systems are aimed at the entire blockchain system, and blockchain systems basically use non-asynchronous consensus algorithms, which is very inconvenient for the research of asynchronous consensus algorithms. (3) Most blockchain testing tools require manual deployment of blockchain systems, which is a very cumbersome and difficult process that wastes a lot of time. Summary of the invention

[0007] In order to solve the above problems, the present invention proposes a performance testing system and method for an asynchronous consensus algorithm. The deployment script is divided into a blockchain system deployment script and a consensus algorithm deployment script. Users can perform performance testing on the overall blockchain system or a single consensus algorithm through different deployment scripts, and it is applicable to the performance testing of asynchronous consensus algorithms.

[0008] According to some embodiments, the present invention adopts the following technical solutions:

[0009] A performance testing method for an asynchronous consensus algorithm, comprising the following steps:

[0010] Obtain the parameters of the test case, determine the blockchain system or consensus algorithm to be tested, the load mode, and the monitored content, and form a test instruction;

[0011] Perform corresponding operations of deploying the blockchain or the consensus algorithm on the server or the virtual machine created on the server according to the test instruction;

[0012] According to the test instruction, construct corresponding load transactions for the deployed server to form a load request, and horizontally divide the load request into actual load and theoretical load according to different abstraction layers and different scenarios;

[0013] Convert the load request into a load transaction corresponding to the blockchain system or the consensus algorithm, and send the load transaction;

[0014] Monitor the message delay, bandwidth usage, central processing unit usage, and memory usage of the deployed server under the corresponding load transaction;

[0015] Analyze the monitored results to obtain test analysis results.

[0016] As an alternative implementation, the specific process of performing the corresponding operations of deploying the blockchain or the consensus algorithm includes two modes:

[0017] Cloud mode: Obtain the account password and virtual machine model uploaded by the user, connect to the cloud server through the script to create a corresponding virtual machine, and transfer the deployment script to the virtual machine for deployment;

[0018] Normal mode: Obtain the IP address of the corresponding virtual machine or server and the management user password uploaded by the user, and perform deployment on the specified virtual machine or server.

[0019] As a further limitation, in the deployment process, the network environment is set.

[0020] As an alternative embodiment, compared with the theoretical load, the actual load can simulate real clients to send transactions under the limitation of reasonable bandwidth. The load transactions are diverse and unique, and there are also network delays and packet losses.

[0021] As an alternative embodiment, when sending load transactions, they are sent in a manner of gradually increasing linearly at a rate.

[0022] An asynchronous consensus algorithm performance testing system includes:

[0023] A parsing module, configured to obtain the parameters of the test case, determine the blockchain system or consensus algorithm to be tested, the load mode, and the content to be monitored, and form a test instruction; analyze the monitored results to obtain a test analysis result;

[0024] A deployment module, configured to perform corresponding operations of deploying the blockchain or the consensus algorithm on a server or a virtual machine created on the server according to the test instruction;

[0025] A load module, configured to construct corresponding load transactions for the deployed server according to the test instruction to form a load request, and the load request is horizontally divided into an actual load and a theoretical load according to different abstraction layers and different scenarios;

[0026] A monitoring module, configured to monitor the message delay, bandwidth, central processing unit usage rate, and memory usage of the deployed server.

[0027] As an alternative embodiment, the system includes an interface layer, a core layer, and a data layer. The interface layer is connected to the user side and the server side, and is used to receive data and instructions uploaded by the user side and feedback the test results;

[0028] The core layer includes a parsing module, a deployment module, a load module, and a monitoring module, and is used to perform performance testing;

[0029] The data layer is used to store test data and deployment scripts.

[0030] As an alternative embodiment, the load module is configured to include a theoretical load and an actual load. Each coroutine of the theoretical load sends a batch of transactions to the consensus node, and each transaction is indistinguishable. Each coroutine of the actual load only sends one transaction to the consensus node and each transaction is different. Finally, the same transactions will be removed when counting the number of transactions. The actual load is diverse and unique and there are network delays and packet losses.

[0031] As an alternative embodiment, the monitoring module is configured to block the messages sent or received by the consensus node according to the requirements of the test case to simulate the downtime of the consensus node.

[0032] As an alternative embodiment, when the listening module performs tests on asynchronous consensus algorithms, the consensus process is divided into two stages, namely the transaction broadcasting stage and the consensus transaction stage. The network bandwidth utilization rate and message processing delay information in these two stages are monitored, and the bottleneck of the asynchronous consensus algorithm is analyzed by comparing the test data of the two stages.

[0033] The deployment module is configured to transfer the executable file obtained by compiling the code and the relevant configuration files to a specified remote server, and the executable file starts in the remote server to generate a consensus network.

[0034] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0035] In the present invention, the deployment module is used to manage the deployment scripts, which are divided into a blockchain system deployment script and a consensus algorithm deployment script. Users can perform performance tests on the overall blockchain system or a single consensus algorithm through different deployment scripts.

[0036] The present invention also takes the parsing module as the core to mobilize other modules to perform test work. Users only need to input a test case to obtain the corresponding test results, hiding the cumbersome test process from the users.

[0037] In the present invention, the actual load and the theoretical load are realized through the deployment module and the load module, and the performance of the consensus algorithm or the blockchain system is analyzed from multiple angles such as the type of transactions, the uniqueness of transactions, network bandwidth usage, network latency and packet loss rate, and node downtime.

[0038] In the present invention, the listening module divides the performance test process of the asynchronous consensus algorithm into a transaction broadcasting stage and a consensus transaction stage, and more effectively analyzes the performance bottleneck of the asynchronous consensus algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings forming a part of this specification are used to provide a further understanding of the present invention. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention.

[0040] Figure 1 is a schematic diagram of the system connection of the present invention;

[0041] Figure 2 is a schematic diagram of the internal architecture of the system of the present invention;

[0042] Figure 3 is a schematic diagram of the coroutine pool and task pool defined by the load module of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0043] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0044] It should be noted that the following detailed description is illustrative and is intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention pertains.

[0045] It should be noted that the terms used herein are merely for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular forms are also intended to include the plural forms. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they specify the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0046] An asynchronous consensus algorithm performance testing system, as Figure 1 shown, by the tester inputting test cases, the system (AsyncTool in the attached drawings) performs deployment test listening operations on the test server according to the test cases, and finally feeds back the test results to the tester.

[0047] AsyncTool is mainly divided into three layers, the interface layer, the core layer, and the data layer, as Figure 2 shown. The interface layer is the visual interface, which facilitates the tester to input test cases to obtain test results and supports querying and reviewing historical test results.

[0048] The core layer is the main function of AsyncTool, which is mainly divided into a parsing module, a deployment module, a load module, and a listening module, and the parsing module is used to mobilize for deployment, load, and listening and other work. The data layer stores the deployment scripts of each blockchain system and consensus algorithm and the results of completed tests.

[0049] The following introduces each module of the core layer.

[0050] The parsing module is equivalent to the interface for the core layer to interact with other layers, and its main functions are:

[0051] (1) It has the function of parsing test case parameters to determine the target blockchain system or consensus algorithm, load mode, and listening content;

[0052] (2) Sending corresponding instructions to the listening module, deployment module, and load module according to the information transmitted by the interface layer or other modules;

[0053] (3) Parsing the monitoring data and log after the test is completed to obtain the test results.

[0054] The deployment module performs corresponding operations of deploying the blockchain or consensus algorithm according to the instructions sent by the parsing module.

[0055] In this embodiment, the deployment method is divided into two modes: (1) Cloud mode, where the user needs to input the corresponding account password, virtual machine model, etc., and then connect to the cloud server through a script to create the corresponding virtual machine, deploy the asynchronous consensus algorithm in the virtual machine and configure the parameters, which also includes the relevant interfaces for virtual machine management; (2) Normal mode, where the user inputs the IP address of the corresponding virtual machine or server and the management user password, and the deployment module will deploy the asynchronous consensus algorithm on the specified virtual machine or server.

[0056] In addition to the system deployment, the deployment module can also set the network card of the server to simulate some network environments such as network latency and packet loss to further simulate the real network situation.

[0057] The deployment process of the present invention is applicable to consensus algorithms implemented in languages such as Go. The specific operation is to transfer the executable file obtained by compiling the code and the relevant configuration files to the specified server through ssh, and the executable file can start in the remote server to generate a consensus network.

[0058] The load module defines a coroutine pool and a task pool, which are used to manage the coroutines for load transactions and the load transaction tasks respectively, such as Figure 3 . In order to reflect the difference between the theoretical performance and the actual performance of the asynchronous consensus algorithm, two load modes are designed in the load module:

[0059] (1) Theoretical load, where the coroutine pool only contains one coroutine to process the load batch transaction tasks in the task pool, that is, each coroutine sends a batch of transactions to the consensus nodes, and each transaction is the same without difference.

[0060] (2) Actual load, where the coroutine pool contains many coroutines, and these coroutines process the load single transaction tasks in the task pool, that is, each coroutine only sends one transaction to the consensus node and each transaction is different. Finally, the same transactions will be removed when counting the number of transactions.

[0061] In this embodiment, compared with the theoretical load, under the limitation of reasonable bandwidth, the actual load simulates the real client to send transactions. The load transactions have diversity and uniqueness, and there are also network latency and packet loss in the environment deployed by the deployment module. In this way, the test results obtained from the actual load are more practical and can be compared and analyzed with the results obtained from the theoretical load.

[0062] The monitoring module is responsible for monitoring the message latency, bandwidth, CPU usage, and memory usage of the deployment server, etc. In addition to the monitoring function, it can also block the messages sent or received by the consensus nodes according to the requirements of test cases to simulate the downtime of consensus nodes. When the test is completed, the test data is passed to the parsing module for analysis. When testing the asynchronous consensus algorithm, the consensus process is divided into two stages, namely the transaction broadcast stage and the consensus transaction stage, and the network bandwidth usage, message processing latency and other information in these two stages are monitored. That is, the consensus process is refined into two steps to analyze the efficiency of the asynchronous consensus algorithm. By comparing the test data of the two stages, the bottleneck of the asynchronous consensus algorithm can be analyzed more clearly.

[0063] Specifically, by comparing the latency data of the two stages, it can be seen which stage has a higher latency consumption time, so as to find the starting point for optimizing the efficiency of the consensus algorithm. Usually, the high efficiency of the asynchronous consensus algorithm comes at the cost of using a large amount of network bandwidth to transmit a large number of transactions, which is not advisable in practical applications. By analyzing the network bandwidth usage of the two stages, it can be analyzed which stage needs to be optimized more. Generally speaking, by comparing the test data of the two stages, the performance bottleneck of the algorithm can be located more accurately and with finer granularity in which stage, which is more helpful for researchers to optimize.

[0064] The present invention uses the parsing module to mobilize other modules to carry out test work. The user only needs to input a test case to obtain the corresponding test result, hiding the cumbersome test process for the user and realizing the automation of the test process.

[0065] The present invention also uses the deployment script in the deployment module to transmit the compiled file of the specified asynchronous consensus algorithm, making the deployment process more concise and better applicable to the newly implemented asynchronous consensus algorithm.

[0066] The present invention proposes two forms of load, namely actual load and theoretical load, which are implemented by the load module. The theoretical performance and actual performance of the consensus algorithm are analyzed from multiple angles such as the two load methods, the uniqueness of transactions, network bandwidth usage, network latency and packet loss rate, and node downtime, more clearly showing the gap between the theoretical value and the actual value of the performance of the existing consensus algorithm. Finally, in the monitoring module of the present invention, the monitored data is divided into the transaction broadcast stage and the consensus transaction stage, more effectively analyzing the performance bottleneck of the asynchronous consensus algorithm.

[0067] As described in the background technology, the asynchronous consensus algorithm has not been applied to the market in a timely manner. A big reason is that the existing test performance data are all theoretical values, and no one has studied the performance of the algorithm in actual applications. There are two main reasons why the theoretical value data is too large. First, sending a large number of transactions at one time takes up a lot of network bandwidth; second, each transaction is non-repeated by default. According to the characteristics of the asynchronous consensus algorithm, repeated transactions will be removed, so the test data is high. Existing technologies can be used to reduce the transaction repetition rate.

[0068] The two loads of the present invention highlight the performance gap through the two factors of bandwidth usage gap and transaction repetition rate, and it can be clearly seen that the algorithm is affected by these two factors.

[0069] Some embodiments provide a method for testing the performance of an asynchronous consensus algorithm, comprising the following steps:

[0070] Obtain test case parameters, determine the blockchain system or consensus algorithm to be tested, load mode, and monitoring content, and form test instructions;

[0071] Perform corresponding deployment of blockchain or consensus algorithm operations on the server or the virtual machine created on the server according to the test instructions;

[0072] According to the test instructions, corresponding load transactions are constructed for the deployed servers to form load requests. According to different abstraction layers and different scenarios, the load requests are horizontally divided into actual load and theoretical load.

[0073] Convert the load request into a load transaction of the corresponding blockchain system or consensus algorithm, and send the load transaction;

[0074] Monitor the message latency, bandwidth, CPU usage, and memory usage of deployed servers;

[0075] Analyze the monitoring results to obtain the test analysis results.

[0076] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] The present invention is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in one flow Figure 1 or more flows and / or blocks Figure 1 or means for implementing the functions specified in one block or more blocks.

[0078] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means that implement the functions specified in one flow Figure 1 or more flows and / or blocks Figure 1 or means for implementing the functions specified in one block or more blocks.

[0079] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one flow Figure 1 or more flows and / or blocks Figure 1 or means for implementing the functions specified in one block or more blocks.

[0080] The above are only the preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the protection scope of the present invention.

[0081] Although the specific embodiments of the present invention have been described above in conjunction with the accompanying drawings, it is not a limitation on the protection scope of the present invention. Those skilled in the art should understand that based on the technical solutions of the present invention, various modifications or deformations that can be made without creative efforts by those skilled in the art are still within the protection scope of the present invention.

Claims

1. A method for testing the performance of an asynchronous consensus algorithm, characterized in that It includes the following steps: Obtain the parameters of the test case, determine the blockchain system or consensus algorithm to be tested, the load mode, and the content to be monitored, and form a test instruction; Perform corresponding operations of deploying the blockchain or consensus algorithm on the server or the virtual machine created on the server according to the test instruction; According to the test instruction, construct corresponding load transactions for the deployed server to form a load request, and according to different abstraction layers and different scenarios, the load request is horizontally divided into actual load and theoretical load; Convert the load request into a load transaction corresponding to the blockchain system or consensus algorithm, and send the load transaction; Monitor the message delay, bandwidth usage, CPU usage, and memory usage of the deployed server under the corresponding load transaction; Analyze the monitored results to obtain the test analysis results.

2. The performance testing method of an asynchronous consensus algorithm according to claim 1, characterized in that The specific process of performing the corresponding operations of deploying the blockchain or consensus algorithm includes two modes: Cloud mode: Obtain the account password and virtual machine model uploaded by the user, connect to the cloud server through a script to create a corresponding virtual machine, and transfer the deployment script to the virtual machine for deployment; Normal mode: Obtain the IP address of the corresponding virtual machine or server and the management user password uploaded by the user, and perform deployment on the specified virtual machine or server.

3. The performance testing method for an asynchronous consensus algorithm according to claim 1, characterized in that Compared with the theoretical load, the actual load can simulate real client transactions under the limitation of reasonable bandwidth. The load transactions are diverse and unique, and there are also network delays and packet losses.

4. The performance testing method for an asynchronous consensus algorithm according to claim 1, characterized in that, When sending the load transaction, it is sent in a way that the rate gradually increases linearly.

5. An asynchronous consensus algorithm performance testing system, characterized in that, It includes: Parsing module, configured to obtain the parameters of the test case, determine the blockchain system or consensus algorithm to be tested, the load mode, and the content to be monitored, and form a test instruction; Analyze the monitored results to obtain the test analysis results; Deployment module, configured to perform corresponding operations of deploying the blockchain or consensus algorithm on the server or the virtual machine created on the server according to the test instruction; Load module, configured to construct corresponding load transactions for the deployed server according to the test instruction to form a load request, and according to different abstraction layers and different scenarios, the load request is horizontally divided into actual load and theoretical load; convert the load request into a load transaction corresponding to the blockchain system or consensus algorithm, and send the load transaction; Monitoring module, configured to monitor the message delay, bandwidth, CPU usage, and memory usage of the deployed server, and analyze the monitored results to obtain the test analysis results.

6. The performance testing system for an asynchronous consensus algorithm according to claim 5, characterized in that, The system includes an interface layer, a core layer, and a data layer. The interface layer is connected to the user side and the server side, and is used to receive the data and instructions uploaded by the user side and feedback the test results; The core layer includes a parsing module, a deployment module, a load module, and a monitoring module, and is used to perform performance testing; The data layer is used to store test data and deployment scripts.

7. The performance testing system for an asynchronous consensus algorithm according to claim 5, wherein, The load module is configured to include a theoretical load and an actual load. Each coroutine of the theoretical load sends a batch of transactions to the consensus node, and each transaction is indistinguishable. Each coroutine of the actual load only sends one transaction to the consensus node and each transaction is different. Finally, the same transactions will be removed when counting the number of transactions. The actual load has diversity, uniqueness, network latency, and packet loss.

8. The performance testing system for an asynchronous consensus algorithm according to claim 5, characterized in that, The monitoring module is configured to block the messages sent or received by the consensus node according to the requirements of the test case, so as to simulate the downtime of the consensus node.

9. The performance testing system for an asynchronous consensus algorithm according to claim 5, wherein When testing the asynchronous consensus algorithm, the monitoring module divides the consensus process into two stages, namely the transaction broadcast stage and the consensus transaction stage, monitors the network bandwidth utilization rate and message processing delay information in these two stages, and analyzes the bottleneck of the asynchronous consensus algorithm by comparing the test data of the two stages.

10. The performance testing system for an asynchronous consensus algorithm according to claim 5, characterized in that, The deployment module is configured to transfer the executable file obtained by compiling the code and the relevant configuration files to the specified remote server, and the executable file starts in the remote server to generate a consensus network.

Images