Test method and device of consensus algorithm, electronic equipment and storage medium

Abstract

The application provides a consensus algorithm test method and device, an electronic device and a storage medium. A block to be consensus is simulated to generate, and the block contains a preset number of virtual transactions. The block is consensus processed based on a consensus algorithm configured in a consensus node network, and after the block passes the consensus processing, the block is simulated to perform on-chain storage. According to record data obtained by the consensus node network during the consensus processing, a test result related to the consensus algorithm is generated. The technical scheme of the embodiment of the application simulates the generation of the block and the on-chain storage of the block, so that the performance consumption of the consensus algorithm running process is completely retained during the consensus algorithm test process, and the performance consumption of other functions is reduced, and finally an accurate consensus algorithm test result is obtained.

Description

Technical Field

[0001] This application relates to the field of secure network technology, and more specifically, to a testing method, apparatus, electronic device, and storage medium for a consensus algorithm. Background Technology

[0002] Currently, testing the performance of blockchain consensus algorithms typically requires a complete blockchain operation process. This involves completing a block processing cycle on the blockchain and then testing the consensus algorithm on the data generated during block processing. However, this method, which requires the full participation of the blockchain in block processing, relies on a fully functional blockchain. Blockchains are costly, and with numerous functional implementations, other modules can interfere with the consensus algorithm implementation. When the blockchain malfunctions, it's impossible to determine whether the failure is due to the consensus algorithm or other modules, thus making accurate test results difficult to obtain. Furthermore, during the algorithm testing process, other blockchain modules also participate in the testing, further increasing performance overhead. Therefore, the final test data essentially reflects the overall performance of the blockchain and cannot accurately reflect the performance of the consensus algorithm. Summary of the Invention

[0003] To address the aforementioned technical problems, embodiments of this application provide a method and apparatus for testing consensus algorithms, an electronic device, a computer-readable storage medium, and a computer program product.

[0004] According to one aspect of the embodiments of this application, a method for testing a consensus algorithm is provided, which involves simulating the generation of a block to be consensused, the block containing a preset number of virtual transactions; performing consensus processing on the block based on a consensus algorithm configured in a consensus node network, and simulating the on-chain storage of the block after the consensus processing; and generating test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing.

[0005] According to one aspect of the embodiments of this application, a testing apparatus for a consensus algorithm is provided, comprising a consensus block generation module configured to simulate generating a block to be consensused, the block containing a preset number of virtual transactions; a consensus module configured to perform consensus processing on the block based on a consensus algorithm configured in a consensus node network, and to simulate on-chain storage of the block after the block has passed the consensus processing; and a test result generation module configured to generate test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing.

[0006] In one embodiment, the testing apparatus for the consensus algorithm further includes:

[0007] The consensus node configuration module is configured to configure a fixed number of consensus nodes based on pre-loaded configuration data.

[0008] The consensus node network configuration module is configured to establish communication connections between consensus nodes and configure the consensus algorithm for each consensus node based on the configuration data, so as to obtain the consensus node network composed of the consensus nodes.

[0009] In one embodiment, the configuration data includes operating mode information, which includes multi-process mode information; the consensus node configuration module includes:

[0010] The process creation unit is configured to create a fixed number of processes in the server based on the process number information contained in the multi-process mode information.

[0011] The first consensus node acquisition unit is configured to use the created process as a consensus node; wherein the communication connection between the consensus nodes is implemented as an inter-process communication connection.

[0012] In one embodiment, the configuration data includes operating mode information, which includes single-node mode information, and the single-node mode information includes address information of multiple servers; the consensus node configuration module includes:

[0013] The configuration data sending unit is configured to send configuration data to the corresponding servers based on the address information of the plurality of servers, so that the plurality of servers can construct the consensus node network according to the configuration data;

[0014] The second consensus node acquisition unit is configured to identify multiple servers as consensus nodes; wherein the consensus nodes communicate with each other through the address information of the corresponding servers.

[0015] In one embodiment, the testing apparatus for the consensus algorithm further includes:

[0016] The test model acquisition module is configured to acquire a pre-configured test model, which contains information about the number of blocks to be reached in consensus.

[0017] The first test model processing module is configured to start the test model, perform simulated generation of a corresponding number of blocks based on the test model, perform consensus processing on each block based on the consensus algorithm configured in the consensus node network, and simulate the steps of storing the corresponding blocks on the chain after each block has passed the consensus processing.

[0018] In one embodiment, the number of pre-configured test models is multiple, and the multiple test models have a sequential execution order; the testing device for the consensus algorithm further includes:

[0019] The second test model processing module is configured to start each test model sequentially according to the execution order among the multiple test models, so as to complete the consensus processing and on-chain storage of the specified number of blocks in each test model through the consensus node network.

[0020] In one embodiment, the test result generation module includes:

[0021] The log data acquisition unit is configured to print log data associated with the performance test metrics of the consensus algorithm from the recorded data according to a pre-written log printing method;

[0022] The first test result generation unit is configured to generate test results related to the performance of the consensus algorithm based on the log data.

[0023] In one embodiment, the test result generation module includes:

[0024] The indicator data acquisition unit is configured to extract indicator data associated with the performance test indicators of the consensus algorithm based on the data embedding points pre-set by each consensus node in the consensus node network.

[0025] The second test result generation unit is configured to generate test results related to the performance of the consensus algorithm based on the indicator data.

[0026] According to one aspect of the embodiments of this application, an electronic device is provided, including one or more processors; and a storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement a test method for the consensus algorithm as described above.

[0027] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided that stores computer-readable instructions thereon, which, when executed by a computer's processor, cause the computer to perform a test method for a consensus algorithm as described above.

[0028] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the testing method for the consensus algorithm provided in the various alternative embodiments described above.

[0029] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the test method for the consensus algorithm as described above.

[0030] In the technical solution provided by the embodiments of this application, by simulating the generation of blocks and storing the simulated blocks on the chain, the performance consumption of the consensus algorithm operation process is fully preserved during the consensus algorithm test, while reducing the performance consumption of other functions. The final recorded data can accurately reflect the test performance of the consensus algorithm, thereby obtaining accurate consensus algorithm test results.

[0031] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0033] Figure 1A This is a schematic diagram of one implementation environment involved in this application;

[0034] Figure 1B This is a schematic diagram of another implementation environment involved in this application;

[0035] Figure 2 This is a flowchart illustrating a testing method for a consensus algorithm, as shown in an exemplary embodiment of this application;

[0036] Figure 3 This is a schematic diagram of the functional module structure in a consensus node, as illustrated in an exemplary embodiment of this application.

[0037] Figure 4 This is a flowchart illustrating a testing method for a consensus algorithm, as shown in another exemplary embodiment of this application;

[0038] Figure 5 yes Figure 4 A flowchart of step S410 in an exemplary embodiment shown in the illustrated example;

[0039] Figure 6 This is a schematic diagram illustrating the communication method between processes in a multi-process mode, as shown in an exemplary embodiment of this application;

[0040] Figure 7 yes Figure 4A flowchart of step S410 in another exemplary embodiment of the illustrated embodiment;

[0041] Figure 8 This is a schematic diagram illustrating the communication method between consensus nodes in a single-node mode consensus node network, as shown in an exemplary embodiment of this application.

[0042] Figure 9 This is a flowchart illustrating a testing method for a consensus algorithm, as shown in another exemplary embodiment of this application;

[0043] Figure 10 This is a schematic diagram of the test model pool structure shown in an exemplary embodiment of this application;

[0044] Figure 11 This is a schematic diagram of the test process structure shown in an exemplary embodiment of this application;

[0045] Figure 12 This is a flowchart illustrating a testing method for a consensus algorithm, as shown in another exemplary embodiment of this application;

[0046] Figure 13 yes Figure 2 A flowchart of step S250 in an exemplary embodiment shown in the illustrated example;

[0047] Figure 14 yes Figure 2 A flowchart of step S250 in another exemplary embodiment of the illustrated embodiment;

[0048] Figure 15 This is a flowchart illustrating a testing method for a consensus algorithm, as shown in another exemplary embodiment of this application;

[0049] Figure 16 This is a schematic diagram of the structure of a test apparatus for a consensus algorithm, as illustrated in an exemplary embodiment of this application.

[0050] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0051] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0052] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0053] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0054] It should also be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0055] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms (consensus algorithms), and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying platform, a platform product service layer, and an application service layer.

[0056] Consensus mechanisms, also known as consensus algorithms, are algorithms used to achieve distributed consensus on blockchain transactions. They embody how all nodes in blockchain technology reach a consensus to determine the validity of a record (block). Consensus mechanisms serve both as a means of determination and a means of preventing tampering. Currently, there are four main types of consensus mechanisms: PoW (Proof of Work: the most widely used consensus mechanism in public blockchains), PoS (Proof of Stake: a distributed consensus mechanism that requires nodes to compete for the right to record transactions on the blockchain), DPoS (Delegated Proof-of-Stake), and distributed consensus algorithms. Distributed consensus algorithms are further divided into Byzantine fault-tolerant algorithms that solve the Byzantine Generals Problem, such as PBFT (Byzantine Fault Tolerance Algorithm), and distributed consensus algorithms that solve non-Byzantine problems.

[0057] The underlying blockchain platform can include processing modules such as basic services, smart contracts, and operational monitoring. The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), then encrypt the business information using a consensus algorithm (consensus management), and finally transmit the encrypted information completely and consistently to the shared ledger (network communication) for recording and storage. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, execution is triggered by calling keys or other events to complete the contract logic. It also provides functions for contract upgrades and cancellations. The operational monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization during product launch, such as alarms, network status monitoring, and node device health monitoring.

[0058] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services for use by business stakeholders.

[0059] Please refer to the following first. Figure 1A and 1B , Figure 1A and 1B This is a schematic diagram of one implementation environment involved in this application. This implementation environment relies on blockchain technology.

[0060] Specifically, for Figure 1A The implementation environment includes a terminal 101A and multiple servers 103A. Each server can communicate with each other. The terminal 101A can communicate with a specific server 103A or with multiple servers 103A. Each server 103A can be equivalent to a consensus node, which can implement the application process of consensus algorithms in blockchain technology. Multiple servers 103A can form a consensus node network.

[0061] It should be understood that Figure 1A The number of servers 103A shown is merely illustrative. Any number of servers 103A can be used as needed, and communication connections can be established between multiple servers 103A.

[0062] In some embodiments of this application, the testing method for the consensus algorithm is provided by... Figure 1AThe consensus node network, composed of multiple servers 103A, is used for consensus algorithm testing. A testing device for the consensus algorithm is configured within this network. When testing the consensus algorithm, a test notification is sent via terminal 101A. The consensus node network then simulates the generation of blocks to be agreed upon, containing a preset number of virtual transactions. Consensus processing is then performed on the blocks based on the consensus algorithm configured within the network, and the blocks are simulated for on-chain storage after successful consensus processing. Based on the recorded data obtained during the consensus processing, test results related to the consensus algorithm are generated. During this process, server 103A, acting as a consensus node, is only used for consensus processing of blocks based on the pre-configured consensus algorithm and does not perform the block packaging and data storage processes within the blockchain system.

[0063] Of course, after obtaining the test results, the results can also be displayed through a visualization device connected to any server 103A or through the visualization module built into the terminal 101A.

[0064] In other embodiments, the testing method for the consensus algorithm is determined by... Figure 1B Implementation environment execution Figure 1B The implementation environment includes only a terminal 101B and a server 103B. The terminal 101B and the server 103B communicate with each other. The server 103B can be used to build a consensus node network. Multiple processes can be created in the network, and each process is equivalent to a consensus node. The consensus node can implement the application process of the consensus algorithm in blockchain technology. Multiple consensus nodes form a consensus node network.

[0065] exist Figure 1B In the implementation environment, a test notification can be sent through terminal 101A. Then, the consensus node network will simulate the generation of blocks to be agreed upon, and the blocks will contain a preset number of virtual transactions. Then, the consensus processing of the blocks will be carried out based on the consensus algorithm configured in the consensus node network, and the on-chain storage of the blocks will be simulated after the blocks pass the consensus processing. Based on the recorded data obtained by the consensus node network during the consensus processing, test results related to the consensus algorithm will be generated. During this process, the process of the consensus node in server 103B is only used to carry out consensus processing of the blocks based on the pre-configured consensus algorithm, and does not perform the process of block packaging and data storage in the blockchain system.

[0066] Terminals 101A and 101B include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, and aircraft. They can be any electronic device capable of image visualization, such as smartphones, tablets, laptops, or computers; no restrictions are imposed here. Servers 103A and 103B can be independent physical servers, or they can be cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms; no restrictions are imposed here either.

[0067] It should be noted that this embodiment is merely an exemplary implementation environment provided to facilitate understanding of the ideas of this application, and should not be considered as providing any limitation on the scope of use of this application.

[0068] Figure 2 This is a flowchart illustrating a testing method for a consensus algorithm according to an exemplary embodiment. This testing method can be applied to... Figure 1A A consensus node network composed of multiple 103A servers or Figure 1B The consensus node network built by server 103B is specifically executed. It should be understood that this method can also be used in other exemplary implementation environments and executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which this method is applicable.

[0069] In an exemplary embodiment, the method may include steps S210 to S250, which are described in detail below:

[0070] Step S210: Simulate the generation of blocks to be agreed upon.

[0071] In the consensus process of practical applications, the blockchain is first started. After the blockchain is started, transaction information is sent to the blockchain using client tools. After the transaction information arrives at the transaction pool, the transaction pool or core processing engine will package the transaction information in the transaction pool into blocks according to its own and consensus logic, and send them to the consensus module. The consensus module, based on the consensus algorithm, verifies the validity of the block through the AC (Access Control) module, and then performs two-phase or three-phase consensus logic processing. Finally, the block is submitted to the storage module, completing the consensus processing cycle of one block.

[0072] Unlike in real-world blockchain applications where nodes package transactions sent by clients to form blocks, this embodiment simulates a mock (virtual object) transaction pool within the consensus nodes. This mock transaction pool replaces the actual implementation of blocks and replaces the functions of client-submitted transactions, transaction storage, and transaction packaging into blocks. Instead, it directly mocks a block awaiting consensus, and the consensus node network then performs consensus processing based on this block.

[0073] Specifically, each consensus node in the consensus node network is equipped with a mock transaction pool. When it is necessary to test the consensus algorithm, an instruction can be sent to any consensus node. The consensus node that receives the instruction will continuously send mock transactions (virtual transactions) to the mock transaction pool to simulate the process of a client sending a transaction to a node in the blockchain in a real application.

[0074] In this embodiment, in order to ensure the accuracy of the test data for the consensus algorithm, the size of the mock transactions can be pre-configured, specifying how many virtual transactions are included in the block simulated by the mock transaction pool. In this way, the block size simulated by the mock transaction pool can be fixed.

[0075] Step S230: Perform consensus processing on the block based on the consensus algorithm configured in the consensus node network, and simulate the on-chain storage of the block after the block has passed the consensus processing.

[0076] In this embodiment, the consensus node network is a network structure composed of multiple consensus nodes. A schematic diagram of the functional modules within each consensus node can be found in the provided text. Figure 3 Each consensus node contains a mock transaction pool, a consensus module, and a mock storage module. The functions implemented by the consensus module are the same as those implemented by the consensus module of the node in the blockchain, which can complete the consensus processing based on the consensus algorithm. Each consensus node in the consensus node network must participate in the consensus processing of the block in step S210 and only actually execute the consensus process of the consensus algorithm.

[0077] Specifically, the consensus node network will have a master node, which is a special node among the consensus nodes. The master node can be determined by either pre-setting a consensus node as the master node, or by the consensus nodes in the network selecting their own master node. That is, when consensus algorithm testing is required, an instruction can be sent to the pre-determined master node to instruct it to simulate generating blocks to be agreed upon, and then the master node will perform consensus processing on the blocks based on the consensus algorithm. Alternatively, when consensus algorithm testing is required, an instruction can be sent to any consensus node, which will send the blocks to other consensus nodes, and then the consensus nodes will select their own master node, which will then perform consensus processing on the blocks based on the consensus algorithm.

[0078] When testing consensus algorithms, a target consensus algorithm can be identified. For example, if the TBFT consensus algorithm needs to be tested, the consensus node network will use the TBFT (Byzantine Fault Tolerance) consensus algorithm for consensus processing. Specifically, the master node can broadcast the proposal corresponding to the block to other consensus nodes through communication between consensus nodes. Other consensus nodes will then perform voting operations such as Precommit and Commit. Once a certain number of consensus nodes in the consensus node network have confirmed the proposal, the consensus processing is complete. This consensus process using the consensus algorithm is completed within the consensus module.

[0079] In this embodiment, different consensus algorithms have different consensus processing procedures in the consensus module. In addition, in the actual consensus processing of the blockchain, there is also an AC (access control) module that signs and verifies the block data. In this embodiment, in order to reduce the performance consumption caused by signing and verifying the signature, which would affect the testing of the consensus algorithm, a mock AC unit is built in the consensus module of each consensus node. The mock AC unit writes a specific signature string and is set to pass 100% verification when verifying the signature, so as to ensure that the AC module has no significant performance consumption in the consensus process.

[0080] After the consensus processing of blocks is completed based on the consensus algorithm, in actual blockchain technology, one or more database management tools, such as LevelDB (a high-efficiency database), are used to store the submitted blocks. However, the consensus node network in this embodiment does not fully implement the functions of a blockchain; it is only used to test the performance of the consensus algorithm and needs to minimize other performance-intensive interference during the consensus process. Therefore, the consensus algorithm testing scheme proposed in this embodiment does not require actual on-chain storage. After passing through the mock storage module in the consensus node, no processing of the consensus-submitted blocks is required; the storage completion information is directly returned to the consensus module, informing it that the block has been stored, i.e., consensus is complete.

[0081] Step S250: Generate test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing.

[0082] In this embodiment, after the consensus node network completes the consensus of the block based on steps S210 to S230, the consensus module will have running data when it processes the block through the consensus algorithm. The consensus module will record the relevant data. After the consensus of the block is completed, the test results related to the consensus algorithm can be generated by extracting the relevant data from the consensus module. The performance of the consensus algorithm can be evaluated by the test results.

[0083] In this embodiment, testing the consensus algorithm does not require running the entire blockchain. Instead, relevant modules are mocked. During the consensus algorithm test, only the actual processing of the consensus algorithm is completed. When the consensus logic makes dependent calls to other modules, the relevant functions are completed through the mocked modules, resulting in almost no performance overhead. This yields record data that is only related to the consensus algorithm, accurately reflecting its performance. In this process, the blockchain does not need to complete the entire consensus logic, greatly simplifying the availability testing of the consensus algorithm. Furthermore, this process ensures that the performance overhead of the consensus algorithm far outweighs that of other performance overheads, effectively improving the accuracy of consensus algorithm testing.

[0084] Figure 4 This is a flowchart illustrating a testing method for a consensus algorithm according to another exemplary embodiment. For example... Figure 4 As shown, in an exemplary embodiment, the method is implemented in Figure 2 Before step S230, specifically, when implementing the test method for the entire consensus algorithm, Figure 4 The method shown needs to be implemented in Figure 2 Before step S210, that is, before passing through Figure 4 The method shown involves constructing a consensus node network and then simulating the generation of blocks to be reached for consensus. This method may include steps S410 to S430, which are detailed below:

[0085] Step S410: Configure a fixed number of consensus nodes according to the pre-loaded configuration data.

[0086] In this embodiment, the configuration data is pre-set. The configuration data includes running mode information, number of consensus nodes, size of mock transactions, and number of virtual transactions contained in the block simulated by the mock transaction pool. Information such as the size of mock transactions and number of virtual transactions contained in the block simulated by the mock transaction pool can be used to simulate and generate blocks to be reached in step S210, while the running mode information and number of consensus nodes are used to generate the consensus node network in this embodiment.

[0087] To ensure the integrity and security of the configuration data during loading, security checks can be performed on the configuration data, such as: the simulated block size cannot exceed 20% of the current server memory, and whether the path of the certificate file required for communication is correct.

[0088] The operating mode information includes multi-process mode information and single-node mode information. The single-node mode information is implemented in... Figure 1A The implementation environment, i.e., the consensus node network, is in single-node mode, with one server acting as a consensus node. Each server loads configuration data to obtain the consensus node information. Multi-process mode information is implemented in... Figure 1B The implementation environment, namely the consensus node network, is a multi-process mode. One server loads configuration data and pulls multiple processes. Each process is a consensus node, and the number of consensus nodes is obtained from the number of consensus nodes contained in the configuration data.

[0089] Of course, regardless of whether it's single-node mode or multi-process mode, the consensus node will be configured with the following: Figure 3 The structure shown.

[0090] Step S430: Establish communication connections between consensus nodes and configure consensus algorithms for each consensus node based on configuration data to obtain a consensus node network composed of each consensus node.

[0091] In this embodiment, the configuration data also includes a consensus algorithm. This consensus algorithm can be any consensus algorithm. The consensus algorithm can be stored in the consensus module of each consensus node. When used later, the consensus algorithm for a particular test can be determined and called from the consensus module. Alternatively, it can be only the consensus algorithm for this test, indicating that this consensus algorithm is tested here. If the consensus algorithm needs to be changed later, the consensus node network construction and consensus algorithm testing process can be repeated by changing the parameters in the configuration data.

[0092] In this embodiment, the consensus node network is initialized by configuring data to build a consensus node network structure that can be used to quickly and accurately test consensus algorithms. By modifying the configuration data, consensus algorithms under different conditions, different consensus algorithms, and different testing directions can be tested.

[0093] Figure 5 yes Figure 4 The flowchart of step S410 in the illustrated embodiment is shown in an exemplary embodiment. Figure 5 As shown, in an exemplary embodiment, the configuration data includes operating mode information, which includes multi-process mode information; step S410, configuring a fixed number of consensus nodes according to the pre-loaded configuration data, may include steps S510 to S530, which are described in detail below:

[0094] Step S510: Create a fixed number of processes in the server based on the process count information contained in the multi-process mode information.

[0095] In this embodiment, a consensus node network is constructed using a multi-process mode. In this case, the configuration data specifies that the consensus algorithm will be tested using the multi-process mode. Therefore, the configuration data can be sent to a server, which loads and stores the configuration data, performs security checks on the configuration data, and then pulls a fixed number of processes from the server according to the number of processes specified in the configuration data.

[0096] Step S530: Use the created process as a consensus node.

[0097] In this embodiment, the created process is used as a consensus node, that is, each process is configured with the following... Figure 3 The structure allows each process to perform the functions required by nodes in the actual blockchain based on the consensus algorithm, thus a process can be regarded as a consensus node.

[0098] Of course, consensus nodes need to communicate with each other when reaching block consensus, and there are many ways to achieve inter-process communication, see reference. Figure 6 This is a diagram illustrating the communication methods between processes in a multi-process model. Figure 6 In this embodiment, communication between processes is accomplished through a channel. However, in other embodiments, communication between processes can also be accomplished through shared memory, message queues, signals, sockets, etc., which are not limited here. All of these methods can realize communication between processes, which can also realize communication between consensus nodes obtained through processes.

[0099] In this embodiment, a multi-process mode is proposed to construct a consensus node network. In this mode, when a consensus node needs to broadcast information such as proposals and votes to other consensus nodes, it can send it to the other party only through inter-process communication. Moreover, the consensus node network only depends on one server, which reduces the dependence on servers and networks, reduces the testing cost of consensus algorithms, and makes it easier to test the availability of consensus algorithms.

[0100] Figure 7 yes Figure 4 The flowchart of step S410 in the illustrated embodiment is shown in an exemplary embodiment. Figure 7 As shown, in an exemplary embodiment, the configuration data includes operating mode information, which includes single-node mode information, and the single-node mode information includes the address information of multiple servers; step S410, which configures a fixed number of consensus nodes according to the pre-loaded configuration data, may include steps S710 to S730, which are described in detail below:

[0101] Step S710: Send configuration data to the corresponding server based on the address information of multiple servers, so that the multiple servers can construct a consensus node network according to the configuration data.

[0102] In this embodiment, when the running mode information corresponding to the configuration data points to single-node mode information, it proves that the consensus node network constructed here is completed through multiple servers.

[0103] Specifically, the configuration data can be sent to the corresponding servers based on the address information of multiple servers in the configuration data, and then the configuration data can be loaded through multiple servers to construct, such as Figure 3 The structure shown indicates that each server can perform the consensus module function of a node in an actual blockchain. Alternatively, configuration data can be sent to only one server. When that server receives and loads the configuration data, if it confirms that the consensus node network is operating in single-node mode, the server will send the configuration data to other servers based on the address information in the configuration data, thereby completing the reception of the node network by multiple servers.

[0104] Step S730: Identify multiple servers as consensus nodes.

[0105] In this embodiment, consensus nodes communicate with each other through the address information of their respective servers.

[0106] After the configuration data is loaded on multiple servers, each server can be regarded as a consensus node. In order to complete the function of the consensus node network, it is also necessary to establish communication links between consensus nodes, that is, to establish communication links between servers.

[0107] The single-node mode in this embodiment is based on a P2P (Peer-to-Peer) network model. Each node has its own independent IP address and receives communication data from a specific port. To establish communication between servers, messages are sent via the P2P network during broadcasting. (Refer to...) Figure 8 This is a schematic diagram illustrating the communication method between consensus nodes in a single-node consensus node network. In single-node mode, the consensus node network needs to implement a P2P network service. Specifically, communication data can be added in the configuration data. This communication data can implement P2P network services between servers based on the server's address information, thereby enabling communication between servers and facilitating functions such as broadcasting and voting between consensus nodes during subsequent consensus algorithm testing.

[0108] The single-node mode in this embodiment requires the implementation of a P2P network link between servers. This P2P network link is the actual function implemented during the test process, in addition to the consensus algorithm in the consensus module performing consensus. Since in actual blockchain applications, the effectiveness of the consensus algorithm depends on the network module in many aspects, the single-node mode truly includes the consensus algorithm test in the consensus node network. Therefore, the single-node mode can more effectively and realistically test the performance of the consensus algorithm, and can ensure the integrity and security of the consensus algorithm performance test process.

[0109] Figure 9 This is a flowchart illustrating a testing method for a consensus algorithm according to another exemplary embodiment. For example... Figure 9 As shown, in an exemplary embodiment, the method can be implemented in... Figure 2 Before step S210, steps S910 to S930 may be included, as detailed below:

[0110] Step S910: Obtain a pre-configured test model, which contains information about the number of blocks to be reached in consensus.

[0111] In this embodiment, the test model can be configured and written into the configuration data. After the consensus node network is built based on the configuration data, each consensus node can carry out the block consensus process in the consensus node network according to the scheme configured in the test model.

[0112] The test model contains information about the number of blocks to be consensused, the number of consensus nodes, the consensus algorithm to be tested, and the corresponding test tasks for the consensus algorithm. For example, in one embodiment, a test model is the performance test of a seven-node TBFT consensus algorithm submitting 100 blocks. This test model shows that the TBFT consensus algorithm is being tested, requiring consensus on 100 blocks. The consensus node network has seven consensus nodes. The number of consensus nodes in the test model corresponds to the process of building the consensus node network through configuration data. Figure 5 or Figure 7 In constructing a consensus node network, the number of consensus nodes obtained should be the same as the number of consensus nodes in the test model.

[0113] Step S930: Start the test model.

[0114] In this embodiment, once the test model is obtained, the test model can be started to execute the steps of simulating the generation of a corresponding number of blocks based on the test model, performing consensus processing on each block based on the consensus algorithm configured in the consensus node network, and simulating the on-chain storage of the corresponding blocks after the consensus processing of each block.

[0115] Specifically, steps S210 and S230 are executed first to simulate the generation of blocks to be reached through consensus, and then the blocks are processed through consensus algorithm before being stored on the blockchain. Of course, the consensus algorithm in step S230 is the consensus algorithm to be tested in the test model.

[0116] After step S230 is completed, the number of blocks that have reached consensus can be determined. If the number of blocks that have reached consensus is less than the number of blocks to be reached, then step S210 and step S230 are repeated until the number of blocks that have reached consensus reaches the number of blocks to be reached.

[0117] In this embodiment, it can be determined whether the consensus node network has completed the test task specified by the test model through log keyword filtering. For example, for the test model proposed above, which is the performance of a seven-node TBFT consensus algorithm submitting 100 blocks, it proves that in the consensus node network, a block height exceeding 100 indicates that consensus on 100 blocks has been achieved. The height exceeding 100 can be determined by the filtered log keyword "Commit Block Height: 101" during the consensus process. If the height exceeds 100, the test model task is completed, and then step S250 can be executed. For example, the TPS (Transactions Per Second) performance can be calculated based on the time difference between the extracted 101st block and the 1st block.

[0118] This embodiment proposes loading the test model into the configuration data, which allows the test model to be modified according to testing needs, thereby improving the convenience of testing different consensus algorithms.

[0119] Of course, the above describes how to test the consensus algorithm for a single test model. In some cases, there may be multiple test models in the configuration data, such as... Figure 10 This is a test model pool output in an exemplary embodiment. The test model pool includes multiple test models, each with a different test task. For example, different test tasks may be due to different information about the number of blocks to be consensused, different numbers of consensus nodes, different consensus algorithms to be tested, or different test tasks corresponding to different consensus algorithms. For example, Model 1 tests the addition and deletion of nodes in a four-node TBFT consensus algorithm, Model 2 tests the performance of submitting 100 blocks in a four-node TBFT consensus algorithm, and Model 3 tests the performance of submitting 100 blocks in a seven-node TBFT consensus algorithm. The number of test models in this test model pool is not unique and can be added or deleted.

[0120] In one specific embodiment, if a configuration data set contains multiple test models (i.e., multiple test models are selected from a test model pool), then when writing the multiple test models into the configuration data, it is also necessary to configure the test flow between the multiple test models, as described above. Figure 11 This is a schematic diagram of a test process structure, which is the sequence of multiple test models.

[0121] against Figure 11 In a specific embodiment, the test model first loads configuration data, then configures the consensus node network using the method described above. This consensus node network configuration references the data from test model 2, meaning it includes four consensus nodes. Then, it proceeds through... Figure 9 The test task of test model 2 is completed using the following method. After the test task of test model 2 is completed, the test result corresponding to the task of test model 2 is obtained through step S250. At this time, the task of test model 2 is completed. Since test model 2 is followed by the task of test model 3 in the test process, the record data generated during the processing of the test model 2 task is deleted first, and the configuration data of the consensus node network is deleted. Based on test model 3 and the configuration data, a new consensus node network is configured. At this time, the consensus node network has 7 consensus nodes. The task specified by test model 3 is completed according to the new consensus node network. In this way, according to the execution order between multiple test models, each test model is started in sequence to complete the consensus processing process and on-chain storage process of the number of blocks specified in each test model through the consensus node network. Finally, the test result corresponding to each test model can be obtained. When finally displaying the test results, the test results of each test model can be merged to generate a test report.

[0122] In this embodiment, reference Figure 12 When configuring the consensus algorithm, the configuration data is loaded first, and then it can be determined whether there are multiple test models in the configuration data. If there is only one, the consensus algorithm is tested based on that test model. If there are multiple models, automated testing is performed according to the test process in multiple models. That is, based on the order in the test process, the task of each test model is automatically completed.

[0123] By making the test model configurable and enabling the establishment of test processes for multiple test models, multiple test tasks can be completed automatically. Tests on different operating conditions and different consensus algorithms can be completed in one go, which greatly reduces the difficulty and complexity of testing and improves testing efficiency.

[0124] Figure 13 yes Figure 2 The flowchart of step S250 in the illustrated embodiment is shown in an exemplary embodiment. Figure 13As shown, in an exemplary embodiment, step S250, which generates test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during consensus processing, may include steps S1310 to S1330, which are detailed below:

[0125] Step S1310: Print log data associated with the performance test metrics of the consensus algorithm from the recorded data according to the pre-written log printing method.

[0126] In this embodiment, during the construction of the consensus node network, the consensus module of each consensus node can realize the function of the blockchain node consensus module in actual application. That is, the consensus module in this case is configured with log rules. After the test tasks specified by the test model are completed, a log analysis tool can be written according to the log rules of the consensus module. In this way, log data related to the performance test indicators of the consensus algorithm can be printed from the recorded data through log printing. Generally, the log format of the consensus module is fixed, and it is easy to filter out the required state changes by the keywords of the logs. Then, the effective information of this log data can be extracted to complete the data collection.

[0127] Step S1330: Generate test results related to the performance of the consensus algorithm based on log data.

[0128] Once log data related to a test task is collected, the test results can be analyzed based on the log data. For example, the TPS performance of the consensus algorithm can be calculated based on the task completion time in the log data. Of course, TPS performance is only an example. In other embodiments, other performance parameters can be used as test results of the consensus algorithm. No specific limitations are imposed here.

[0129] In this embodiment, log data during the consensus algorithm testing process is extracted by logging, thereby completing the test data collection for the consensus algorithm. This allows data collection to be completed without modifying the consensus module's code, ensuring the universality of the consensus module and improving the security of the test results.

[0130] Figure 14 yes Figure 2 The flowchart of step S250 in the illustrated embodiment is shown in an exemplary embodiment. Figure 14 As shown, in an exemplary embodiment, step S250, which generates test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during consensus processing, may include steps S1410 to S1430, as detailed below:

[0131] Step S1410: Based on the data points pre-set by each consensus node in the consensus node network, extract the indicator data associated with the performance test indicators of the consensus algorithm.

[0132] In this embodiment, data embedding points can be set for the consensus modules of each consensus node during the construction of the consensus node network. In this way, when the consensus algorithm is tested in the consensus node network, key data can be collected to obtain indicator data.

[0133] Step S1430: Generate test results that correlate with the performance of the consensus algorithm based on the indicator data.

[0134] Similarly, referring to step S1330, after obtaining the indicator data, test results can be obtained based on the indicator data.

[0135] In this embodiment, it is only necessary to set the relevant program in the configuration data to set data points at key locations in the consensus module. The method is simple and the obtained indicator data is accurate. Thus, accurate test results can be obtained through the indicator data.

[0136] refer to Figures 2 to 14 The consensus algorithm testing method shown is as follows. Figure 15 This is a flowchart illustrating a testing method for a consensus algorithm according to another exemplary embodiment. For example... Figure 15 As shown, in this embodiment, the consensus algorithm testing process involves the server loading configuration data after the test is started. The server then checks the validity of the configuration data, i.e., its security. If the check passes, a multi-process consensus node network or a single-node consensus node network is constructed based on the operating mode information set in the configuration data. Subsequently, block consensus is achieved according to the test model in the configuration data. After a block consensus is completed, status information, such as Commit Block Height, is recorded. The system then checks whether this status information meets the requirements of the test model, i.e., whether the number of blocks to be consensused as specified by the test model has been completed. If not, the block simulation, block consensus, and simulated on-chain submission steps are performed again until the status information meets the requirements of the test model. At this point, the test task is stopped, and test results are generated based on the data generated during the test process.

[0137] The consensus algorithm testing method proposed in this embodiment only implements the actual functionality of the consensus algorithm in the consensus module, mocking other functions in the complete consensus process of other modules. This reduces the performance overhead caused by implementing other functions, greatly improving the accuracy of consensus algorithm testing. Furthermore, it eliminates the need to fully implement all blockchain functions, thus reducing testing difficulty. Simultaneously, the construction of the consensus node network supports both single-node and multi-process modes. The single-node mode includes a network module, allowing for better testing and verification of the consensus algorithm's security and activity. The multi-process mode reduces server dependence and testing costs. Additionally, the method proposes configurable test models, allowing for the configuration of test tasks and automated testing of multiple test models based on test processes. This improves the efficiency of consensus algorithm testing and significantly reduces testing difficulty and operational complexity.

[0138] The consensus algorithm testing method proposed in this embodiment can flexibly set configuration data according to needs to test the status and performance of the consensus algorithm in the blockchain. Moreover, this testing method can detect whether the consensus algorithm module itself can run normally when the blockchain is not running, or test the processing performance of the consensus algorithm alone when other dependent modules are not running.

[0139] Figure 16 This is a schematic diagram illustrating the structure of a test apparatus for a consensus algorithm according to an exemplary embodiment. Figure 16 As shown, in an exemplary embodiment, the testing apparatus for the consensus algorithm includes:

[0140] The consensus block generation module 1610 is configured to simulate the generation of blocks to be agreed upon, and the blocks contain a preset number of virtual transactions;

[0141] The consensus module 1630 is configured to perform consensus processing on blocks based on the consensus algorithm configured in the consensus node network, and simulate the on-chain storage of blocks after the blocks have passed the consensus processing.

[0142] The test result generation module 1650 is configured to generate test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing.

[0143] The consensus algorithm testing device proposed in this embodiment can reduce the performance consumption caused by other modules during consensus algorithm testing, so as to obtain accurate consensus algorithm test results.

[0144] In one embodiment, the testing apparatus for the consensus algorithm further includes:

[0145] The consensus node configuration module is configured to configure a fixed number of consensus nodes based on pre-loaded configuration data.

[0146] The consensus node network configuration module is configured to establish communication connections between consensus nodes and configure consensus algorithms for each consensus node based on configuration data, so as to obtain a consensus node network composed of each consensus node.

[0147] In one embodiment, the configuration data includes operating mode information, which includes multi-process mode information; the consensus node configuration module includes:

[0148] The process creation unit is configured to create a fixed number of processes in the server based on the process count information contained in the multi-process mode information.

[0149] The first consensus node acquisition unit is configured to use the created process as a consensus node; wherein the communication connection between consensus nodes is implemented as an inter-process communication connection.

[0150] In one embodiment, the configuration data includes operating mode information, which includes single-node mode information, and the single-node mode information includes the address information of multiple servers; the consensus node configuration module includes:

[0151] The configuration data sending unit is configured to send configuration data to the corresponding servers based on the address information of multiple servers, so that the multiple servers can build a consensus node network according to the configuration data;

[0152] The second consensus node acquisition unit is configured to identify multiple servers as consensus nodes; wherein the consensus nodes communicate with each other through the address information of the corresponding servers.

[0153] In one embodiment, the testing apparatus for the consensus algorithm further includes:

[0154] The test model acquisition module is configured to acquire a pre-configured test model, which contains information about the number of blocks to be reached in consensus.

[0155] The first test model processing module is configured to start the test model, generate a corresponding number of blocks based on the test model, perform consensus processing on each block based on the consensus algorithm configured in the consensus node network, and simulate the steps of storing the corresponding blocks on the chain after the consensus processing of each block.

[0156] In one embodiment, the number of pre-configured test models is multiple, and the multiple test models have a sequential execution order; the testing device for the consensus algorithm further includes:

[0157] The second test model processing module is configured to start each test model sequentially according to the execution order among multiple test models, so as to complete the consensus processing and on-chain storage of the specified number of blocks in each test model through the consensus node network.

[0158] In one embodiment, the test result generation module includes:

[0159] The log data acquisition unit is configured to print log data associated with the performance test metrics of the consensus algorithm from the recorded data according to a pre-written log printing method;

[0160] The first test result generation unit is configured to generate test results based on log data that are correlated with the performance of the consensus algorithm.

[0161] In one embodiment, the test result generation module includes:

[0162] The indicator data acquisition unit is configured to extract indicator data associated with the performance test indicators of the consensus algorithm based on the data points pre-set by each consensus node in the consensus node network.

[0163] The second test result generation unit is configured to generate test results that are correlated with the performance of the consensus algorithm based on indicator data.

[0164] It should be noted that the consensus algorithm testing device and the consensus algorithm testing method provided in the above embodiments belong to the same concept. The specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0165] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the test method of the consensus algorithm provided in the above embodiments.

[0166] Figure 17 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0167] It should be noted that, Figure 17 The computer system 1700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0168] like Figure 17As shown, the computer system 1700 includes a Central Processing Unit (CPU) 1701, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 1702 or programs loaded from storage portion 1708 into Random Access Memory (RAM) 1703. The RAM 1703 also stores various programs and data required for system operation. The CPU 1701, ROM 1702, and RAM 1703 are interconnected via a bus 1704. An Input / Output (I / O) interface 1705 is also connected to the bus 1704.

[0169] The following components are connected to I / O interface 1705: an input section 1706 including a keyboard, mouse, etc.; an output section 1707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1708 including a hard disk, etc.; and a communication section 1709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1709 performs communication processing via a network such as the Internet. Drive 1710 is also connected to I / O interface 1705 as needed. Removable media 1711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1710 as needed so that computer programs read from them can be installed into storage section 1708 as needed.

[0170] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1709, and / or installed from removable medium 1711. When the computer program is executed by central processing unit (CPU) 1701, it performs various functions defined in the system of this application.

[0171] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0172] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0173] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0174] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements a test method for the consensus algorithm as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0175] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the test method for the consensus algorithm provided in the various embodiments described above.

[0176] The above content is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A testing method for a consensus algorithm, characterized in that, include: Simulate the generation of blocks awaiting consensus, wherein the blocks contain a preset number of virtual transactions; The consensus algorithm configured in the consensus node network is used to process the block, and the block is simulated to be stored on the chain after the consensus processing is completed; each consensus node in the consensus node network includes a consensus module, a virtual mock transaction pool for generating the block, and a mock storage module; Based on the recorded data obtained by the consensus node network during the consensus processing, test results related to the consensus algorithm are generated. The consensus algorithm configured in the consensus node network performs consensus processing on the block, and simulates the on-chain storage of the block after the consensus processing, including: The consensus module performs consensus processing on the block based on the consensus algorithm. After the block passes the consensus processing, the mock storage module sends the storage completion information corresponding to the block to the consensus module to simulate the on-chain storage of the block.

2. The method according to claim 1, characterized in that, The method further includes: before simulating on-chain storage of the block after the consensus algorithm configured in the consensus node network performs consensus processing on the block, and before simulating on-chain storage of the block after the consensus processing. Configure a fixed number of consensus nodes based on pre-loaded configuration data; Establish communication connections between consensus nodes, and configure the consensus algorithm for each consensus node based on the configuration data to obtain the consensus node network composed of the consensus nodes.

3. The method according to claim 2, characterized in that, The configuration data includes operating mode information, which includes multi-process mode information; configuring a fixed number of consensus nodes according to the pre-loaded configuration data includes: A fixed number of processes are created in the server based on the process number information contained in the multi-process mode information. The created processes are used as consensus nodes; the communication connection between the consensus nodes is implemented as an inter-process communication connection.

4. The method according to claim 2, characterized in that, The configuration data includes operating mode information, which includes single-node mode information, and the single-node mode information includes the address information of multiple servers; configuring a fixed number of consensus nodes according to the pre-loaded configuration data includes: The configuration data is sent to the corresponding server based on the address information of the multiple servers, so that the multiple servers can construct the consensus node network according to the configuration data; Multiple servers are designated as consensus nodes; the consensus nodes communicate with each other through the address information of their respective servers.

5. The method according to claim 1, characterized in that, The method further includes: Obtain a pre-configured test model, which contains information about the number of blocks to be reached in consensus; The test model is started to simulate the generation of a corresponding number of blocks based on the test model, and consensus processing is performed on each block based on the consensus algorithm configured in the consensus node network. After each block passes the consensus processing, the steps of storing the corresponding block on the chain are simulated.

6. The method according to claim 5, characterized in that, The number of pre-configured test models is multiple, and the multiple test models have a sequential execution order; the method further includes: According to the execution order of the multiple test models, each test model is started sequentially to complete the consensus processing and on-chain storage of the specified number of blocks in each test model through the consensus node network.

7. The method according to claim 1, characterized in that, The step of generating test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing includes: Log data associated with the performance test metrics of the consensus algorithm is printed from the recorded data according to a pre-written log printing method; Test results are generated based on the log data and correlated with the performance of the consensus algorithm.

8. The method according to claim 1, characterized in that, The step of generating test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing includes: Based on the data embedding points pre-set by each consensus node in the consensus node network, extract the indicator data associated with the performance test indicators of the consensus algorithm; Test results are generated based on the aforementioned indicator data and correlated with the performance of the consensus algorithm.

9. A testing device for a consensus algorithm, characterized in that, include: The consensus block generation module is configured to simulate the generation of blocks to be agreed upon, wherein the blocks contain a preset number of virtual transactions; The consensus module is configured to perform consensus processing on the block based on the consensus algorithm configured in the consensus node network, and to simulate the on-chain storage of the block after the block has passed the consensus processing; each consensus node in the consensus node network includes a consensus module, a mock transaction pool for generating the block, and a mock storage module; The test result generation module is configured to generate test results related to the consensus algorithm based on the recorded data obtained by the consensus node network during the consensus processing. The consensus algorithm configured in the consensus node network performs consensus processing on the block, and simulates the on-chain storage of the block after the consensus processing, including: The consensus module performs consensus processing on the block based on the consensus algorithm. After the block passes the consensus processing, the mock storage module sends the storage completion information corresponding to the block to the consensus module to simulate the on-chain storage of the block.

10. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more computer programs that, when executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by the processor of a computer, cause the computer to perform the method described in any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 8.

Images