CN117118986B

CN117118986B - Block chain-based fault tolerance verification method, device, equipment and medium

Info

Publication number: CN117118986B
Application number: CN202311392773.4A
Authority: CN
Inventors: 陈金龙
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-10-25
Filing date: 2023-10-25
Publication date: 2024-02-06
Anticipated expiration: 2043-10-25
Also published as: CN117118986A

Abstract

The embodiment of the application discloses a fault tolerance verification method, a device, equipment, a medium and a product based on a blockchain, wherein the method comprises the following steps: obtaining topological graph structure information of a block chain network; generating a rolling upgrade script according to the topological graph structure information, wherein the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round; the method comprises the steps that a breakpoint in the upgrading of a consensus node is identified based on a rolling upgrading script, a test case for verifying the Bayesian fault tolerance of a blockchain network is triggered and executed based on the breakpoint, and the breakpoint is used for describing the transition time of the consensus node from a historical program version to a target program version; if the rolling upgrading of the blockchain network is detected to be completed, generating a Bayesian fault-tolerant test report based on the test cases. The technical scheme of the embodiment of the application can combine the automatic test case to continuously, effectively and automatically verify the Bayesian fault tolerance characteristic of the blockchain at the breakpoint, and effectively reduce the verification cost.

Description

Block chain-based fault tolerance verification method, device, equipment and medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a blockchain-based fault-tolerant verification method, a blockchain-based fault-tolerant verification device, an electronic device, a computer-readable storage medium, and a computer program product.

Background

Currently, in the field of blockchain technology, testing for the Bayer Fault Tolerance (BFT) is critical to verifying the availability of a blockchain, and the current BFT testing method involves deliberately destroying N/3 of the nodes in a blockchain network consisting of N nodes, for example, shutting down the blockchain process or downtime the nodes, to form a blockchain network within the bayer fault tolerance range, thereby verifying the blockchain network availability. However, this conventional approach is costly to construct, requires operations such as downtime, killing procedures, disconnecting the network, etc., and cannot be continuously verified.

Disclosure of Invention

The embodiment of the application provides a fault tolerance verification method based on a blockchain, a fault tolerance verification device based on the blockchain, electronic equipment, a computer readable storage medium and a computer program product, which can be combined with an automatic test case to continuously, effectively and automatically verify the Bayesian fault tolerance characteristic of the blockchain at a breakpoint, and effectively reduce the verification cost.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned in part by the practice of the application.

According to an aspect of the embodiments of the present application, there is provided a fault-tolerant verification method based on a blockchain, including: obtaining topological graph structure information of a block chain network; generating a rolling upgrade script according to the topological graph structure information, wherein the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round; identifying a breakpoint in the upgrading of the common node based on the rolling upgrading script, and executing a test case for verifying the Bayesian fault tolerance of the blockchain network based on the breakpoint trigger, wherein the breakpoint is used for describing the transition time of the common node from a historical program version to a target program version; and if the rolling upgrading of the block chain network is detected to be completed, generating a Bayesian fault-tolerant test report based on the test case.

According to one aspect of the embodiments of the present application, there is provided a blockchain-based fault-tolerant verification apparatus, the apparatus including: the acquisition module is used for acquiring topological graph structure information of the blockchain network; the generation module is used for generating a rolling upgrade script according to the topological graph structure information, and the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round; the execution module is used for identifying a breakpoint in the upgrading of the consensus node based on the rolling upgrading script, and executing a test case for verifying the Bayesian fault tolerance of the blockchain network based on the breakpoint trigger, wherein the breakpoint is used for describing the transition position of the consensus node from a historical program version to a target program version; and the generating module is also used for generating a Bayesian fault-tolerant test report based on the test case if the rolling upgrading of the blockchain network is detected to be completed.

In an embodiment of the present application, the execution module is further configured to identify a current breakpoint in the rolling upgrade script according to a change of a service state of the consensus node during an operation process of the rolling upgrade script, and execute the test case at the current breakpoint; after the common node corresponding to the current breakpoint is upgraded, identifying the next breakpoint in the rolling upgrade script to execute the test case; and continuing to identify the next breakpoint in the rolling upgrade script until the rolling upgrade of the blockchain network is completed.

In an embodiment of the present application, the topology structure information includes node attribute information of each consensus node and a connection relationship between each consensus node; the generation module is further used for determining upgrading rounds of the consensus nodes according to the node attribute information of the consensus nodes and the connection relation; acquiring a target program version, and generating an upgrade strategy according to node attribute information of the consensus node and the target program version; and generating the rolling upgrade script based on the upgrade rounds of the consensus nodes and the upgrade strategies.

In an embodiment of the present application, the node attribute information of the consensus node includes a program path of the consensus node; the generation module is further used for backing up historical program versions of the consensus node according to a program path of the consensus node, and storing the target program versions into the program path; stopping the current running historical program version of the consensus node, and starting the target program version; and reestablishing connection between the consensus node after updating the target program version and other consensus nodes to obtain the upgrading strategy.

In an embodiment of the present application, the node attribute information of the consensus node includes configuration information of the consensus node; the generation module is further used for determining the number of the consensus nodes to be upgraded in each round according to the total number of the consensus nodes in the blockchain network; determining the upgrading priority of each consensus node according to the configuration information of each consensus node; and determining the upgrading turn of each consensus node according to the number of the consensus nodes to be upgraded in each turn and the upgrading priority of each consensus node.

In an embodiment of the present application, the generating module is further configured to sort the consensus nodes according to the node numbers of the consensus nodes to obtain an initial sorting result; and adjusting the initial sequencing result according to the performance information of each consensus node and the distance information between each consensus node so as to determine the upgrading priority of each consensus node.

In an embodiment of the present application, the execution module is further configured to obtain test cases corresponding to a plurality of test scenes, so as to obtain a plurality of test cases; in the upgrading process of the current round consensus node, selecting at least one target test case from the plurality of test cases for the current blockchain network according to a target test scene; the current blockchain network is a network formed by other consensus nodes except the current round consensus node; and automatically executing the target test case based on the breakpoint.

In an embodiment of the present application, the execution module is further configured to generate a test target for the bayer fault tolerance according to the test property and the fault tolerance degree of the bayer fault tolerance; determining a plurality of test scenes to be covered according to the test targets, wherein each test scene is used for representing a Bayesian attack; and determining data required by the test according to the plurality of test scenes to generate test cases corresponding to the plurality of test scenes respectively.

In an embodiment of the present application, the generating module is further configured to obtain a service test state corresponding to the current blockchain network according to the test case; acquiring a service expected state corresponding to the test case; and generating a Bayesian fault-tolerant subtest report of the current blockchain network according to the service test state and the service expected state.

In an embodiment of the present application, the generating module is further configured to obtain a subtest report corresponding to a test case triggered by each round of upgrade, to obtain a plurality of subtest reports, where the number of consensus nodes to be upgraded in each round is sequentially increased; traversing the plurality of sub-test reports sequentially from the sub-test report corresponding to the last round of upgrading as a base point; if the sub-test report of the last traversal does not reach the expectation, determining the maximum fault tolerance characteristic of the Bayesian fault tolerance according to the sub-test report of the current traversal so as to generate the test report of the Bayesian fault tolerance.

In an embodiment of the present application, the generating module is further configured to detect a consensus service of the blockchain network after the rolling upgrade of the blockchain network is completed, so as to obtain an operation state of the consensus service; and generating a test report of the Bayesian fault tolerance according to the test case and the running state of the consensus service.

In an embodiment of the present application, the apparatus further includes a processing module configured to determine, based on the bayer fault-tolerant test report, a target node in the consensus node in which an anomaly is repeated; if the number of the target nodes is greater than the number of the preset nodes, rollback processing is carried out on the program version of the consensus node of the blockchain network; and if the number of the target nodes is smaller than the preset number of nodes, removing the target nodes from the blockchain network.

According to one aspect of embodiments of the present application, there is provided an electronic device comprising one or more processors; and storage means for storing one or more computer programs which, when executed by the one or more processors, cause the electronic device to implement a blockchain-based fault-tolerant verification method as described above.

According to one aspect of embodiments of the present application, there is provided a computer readable storage medium having stored thereon a computer program which, when executed by a processor of an electronic device, causes the electronic device to perform a blockchain-based fault-tolerant verification method as described above.

According to one aspect of embodiments of the present application, there is provided a computer program product comprising a computer program stored in a computer readable storage medium, from which computer readable storage medium a processor of an electronic device reads and executes the computer program, causing the electronic device to perform a blockchain-based fault tolerant verification method as described above.

In the technical scheme provided by the embodiment of the application, a rolling upgrade script is generated through acquired topological graph structure information of a blockchain network, the rolling upgrade script is used for upgrading a blockchain program version of a consensus node round by round, further, break points in the upgrade of the consensus node are automatically identified based on the rolling upgrade script, and test cases are triggered and executed based on the break points so as to automatically verify the Bayesian fault tolerance characteristics of the blockchain network, wherein the break points are used for describing the transition time of the consensus node from a historical program version to a target program version, and if the rolling upgrade of the blockchain network is detected, a Bayesian fault tolerance test report is generated based on the test cases; that is, the Bayesian fault tolerance characteristic of the blockchain is continuously, effectively and automatically verified at the breakpoint by combining with the automatic test case, the safety and consistency of the system in the rolling upgrading process are effectively ensured, and after the rolling upgrading of the blockchain network is finished, the Bayesian fault tolerance test report of the blockchain network in the rolling upgrading process is automatically given, the Bayesian fault tolerance capability is ensured to be maintained in the upgrading process, and the verification cost is effectively reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application. It is evident that the figures in the following description are only some embodiments of the present application, from which other figures can be obtained without inventive effort for a person skilled in the art.

FIG. 1A is a schematic diagram of a blockchain network.

FIG. 1B is a schematic diagram of a block generation process in a blockchain.

Fig. 1C is a schematic diagram of a blockchain bayer process fault tolerance.

Fig. 2 is a schematic diagram of an implementation environment to which the present application relates.

FIG. 3 is a flow chart illustrating a blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 4 is a flow chart illustrating a blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 5 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 6 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 7 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 8 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 9 is a flow chart illustrating a blockchain-based fault-tolerant verification method in accordance with another exemplary embodiment of the present application.

FIG. 10 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with another exemplary embodiment of the present application.

FIG. 11 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 12 is a flowchart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 13 is a flow chart illustrating another blockchain-based fault-tolerant verification method in accordance with an exemplary embodiment of the present application.

FIG. 14 is a flow chart illustrating a blockchain-based fault-tolerant verification method in accordance with another exemplary embodiment of the present application.

Fig. 15 is a schematic diagram illustrating a node reconnection according to another exemplary embodiment of the present application.

Fig. 16 is a schematic diagram illustrating another node reconnection according to another exemplary embodiment of the present application.

FIG. 17 is a flow chart illustrating a blockchain-based fault-tolerant verification method in accordance with another exemplary embodiment of the present application.

FIG. 18 is a block diagram illustrating a block chain based fault tolerance verification device in accordance with another exemplary embodiment of the present application.

Fig. 19 shows a schematic diagram of a computer system suitable for use in implementing the electronic device of the embodiments of the present application.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the content and operations/, nor do they necessarily have to be performed in the order described. For example, some operations may be decomposed, and some operations may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

Also to be described is: reference to "a plurality" in this application means two or more than two. "and/or" describes an association relationship of an association object, meaning that there may be three relationships, e.g., a and/or B may represent: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.

The technical scheme of the embodiment of the application relates to the technical field of blockchain, and before the technical scheme of the embodiment of the application is introduced, the blockchain technology is briefly introduced.

Blockchain (Blockchain) is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, and the like. The blockchain is essentially a decentralised database, and is a series of data blocks which are generated by association by using a cryptography method, and each data block contains information of a batch of network transactions and is used for verifying the validity (anti-counterfeiting) of the information and generating a next block. The blockchain may include a blockchain underlying platform, a platform product services layer, and an application services layer.

Referring to fig. 1A, a blockchain network may include a plurality of nodes 101, and the plurality of nodes 101 may refer to individual clients in the blockchain. Each node 101 may receive input information while operating normally and maintain shared data within the blockchain based on the received input information. In order to ensure the information intercommunication in the blockchain, information connection can exist between every two nodes in the blockchain, and the nodes can transmit information through the information connection. For example, when any node in the blockchain receives input information, other nodes in the blockchain acquire the input information according to a consensus algorithm, and store the input information as data in shared data, so that the data stored on all nodes in the blockchain are consistent.

For each node in the blockchain, there is a node identification corresponding thereto, and each node in the blockchain may store the node identifications of other nodes in the blockchain for subsequent broadcasting of the generated block to other nodes in the blockchain based on the node identifications of the other nodes. Each node can maintain a node identification list, and the node names and the node identifications are correspondingly stored in the node identification list. The node identifier may be an IP (Internet Protocol, protocol interconnecting between networks) address, or any other information that can be used to identify the node.

It will be appreciated that each node in the blockchain network may be a server or a client. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a Cloud server providing Cloud services, cloud databases, cloud Computing (Cloud Computing), cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDNs (Content Delivery Network, content distribution networks), basic Cloud Computing services such as big data and intelligent platforms, and the like. The client may be, but not limited to, a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a client used in an automobile, an aircraft, and the like. The nodes may be directly or indirectly connected through wired or wireless communication, which is not limited herein.

When each block in the blockchain is generated, referring to fig. 1B, when the node where the blockchain is located receives input information, checking the input information, after the checking is completed, storing the input information into a memory pool, and updating a hash tree used for recording the input information; and updating the update time stamp to the time of receiving the input information, trying different random numbers, calculating the characteristic value for multiple times until a reasonable characteristic value is found, correspondingly storing the information, and generating a block head and a block main body to obtain the current block. And then, the node where the blockchain is located sends the newly generated blocks to other nodes in the blockchain where the newly generated blocks are located according to the node identifications of other nodes in the blockchain, the other nodes verify the newly generated blocks, and the newly generated blocks are added into the blockchain where the newly generated blocks are stored after the verification is completed.

In the process of generating the block, the block is packed, the external broadcast block and other nodes are verified, and the flow of the chain-in block chain is a consensus flow; in this embodiment of the present application, the consensus flow includes a bayer fault tolerance, where the bayer fault tolerance refers to a problem of allowing a small number of nodes to fail or fail to reach distributed consistency, for example, as shown in fig. 1C, a blockchain network composed of 4 consensus nodes satisfies 2f+1 fault tolerance, that is, when 1 consensus node is down, breaks down or fails, external services of the whole blockchain are not affected, and when 2 or more than 2 consensus nodes fail, the consensus of the blockchain is affected, and services cannot be provided to the outside.

The following describes the technical solution of the embodiments of the present application in detail in connection with the blockchain technology.

Based on the implementation environment shown in fig. 1A, the technical solution of the embodiment of the present application may be executed by any consensus node in the blockchain network; the technical solution of the embodiment of the present application may also be executed by the management device 210 for managing the consensus node, as shown in fig. 2, and the management device is illustrated as an example.

The management equipment is used for acquiring topological graph structure information of the blockchain network; generating a rolling upgrade script according to the topological graph structure information, wherein the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round; the method comprises the steps that a breakpoint in the upgrading of a consensus node is identified based on a rolling upgrading script, a test case for verifying the Bayesian fault tolerance of a blockchain network is triggered and executed based on the breakpoint, and the breakpoint is used for describing the transition time of the consensus node from a historical program version to a target program version; if the rolling upgrading of the blockchain network is detected to be completed, generating a Bayesian fault-tolerant test report based on the test cases.

In the distributed system, even if some nodes have faults or malicious operations, the system can still reach consensus and keep operating correctly.

It should be noted that, in the specific embodiment of the present application, if the script and the test case relate to the object, when the embodiment of the present application is applied to a specific product or technology, permission or consent of the object needs to be obtained, and collection, use and processing of the related data need to comply with the relevant regulations and standards of the relevant country and region.

Various implementation details of the technical solutions of the embodiments of the present application are set forth in detail below.

As shown in fig. 3, fig. 3 is a flowchart illustrating a blockchain-based fault-tolerant verification method according to an embodiment of the present application, which may be applied to the implementation environment shown in fig. 1A or fig. 2, and which may be performed by the consensus node shown in fig. 1A or the management device shown in fig. 2, and which may include steps S310 to S340, as described in detail below.

S310, obtaining topological graph structure information of the blockchain network.

In this embodiment, the topology map of the blockchain network includes the number of nodes in the network, the positions and connection relationships of the nodes, the topology map structure information includes node attribute information of the nodes, and the node attribute information includes the position information of the nodes.

In an example, topology information of a blockchain network may be obtained in a pre-release environment or a testing environment of the blockchain network.

In another example, the blockchain network is a simulated blockchain network, and the topology information is simulated topology information.

S320, generating a rolling upgrade script according to the topological graph structure information, wherein the rolling upgrade script is used for upgrading the blockchain program version of the consensus node round by round.

In the present embodiment, a rolling upgrade is an upgrade policy that allows a portion of the nodes of the network to be upgraded in steps without disrupting the entire network; the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round, the block chain program is used for providing consensus service for the consensus node, and the block chain program version supports forward compatibility; the round-by-round upgrading is to upgrade the consensus nodes in turn according to a preset round; wherein, in an upgrade round, there can be one consensus node, or there can be multiple consensus nodes; all consensus nodes in the rolling upgrade version are upgraded in the same way.

The current state and the components of the network can be known through the topological structure information, and then an automatically executed rolling upgrade script can be generated according to the topological structure information, so that the script knows which operations are executed on which nodes, wherein the script specifically comprises the operations required for upgrading each consensus node.

S330, identifying a breakpoint in the upgrade of the consensus node based on the rolling upgrade script, and executing a test case for verifying the ByByBryptory fault tolerance of the blockchain network based on the breakpoint trigger, wherein the breakpoint is used for describing the transition time of the consensus node from the historical program version to the target program version.

In the embodiment of the application, a breakpoint in the upgrade of the consensus node is identified based on the rolling upgrade script, the breakpoint is a key step in the upgrade, and marks the transition of the node from the historical program version to the target program version, wherein the target program version can be the latest program version or a certain historical program version, for example, the current historical program version is v3, and the target program version can be v1 or v2.

In an example, since the rolling upgrade script is used to upgrade the blockchain program version of the consensus node, during the running of the rolling upgrade script, there is a short period of time each time the consensus node switches to the target program version, i.e., a transition period from the historical program version to the target program version, so that a breakpoint in the upgrade can be identified by the rolling upgrade script.

It can be appreciated that in a blockchain network, the bayer fault tolerance is a very important characteristic, because it can ensure the security and reliability of the network, so at these break points, it is necessary to verify whether the network has the bayer fault tolerance, and then various scenes need to be simulated by the execution of pre-written automated test cases to check the states of the network and the application.

In an example, the test cases may be multiple, and execute one or more test cases based on breakpoint triggers, where the test contents of the multiple test cases are different, for example, one test case is used to check whether the transaction is correctly packed and confirmed, and there is no loss or repetition, and another test case is used to check whether the state of the account or contract is consistent with the expected state, and there is no data inconsistency or error.

And S340, if the rolling upgrading of the block chain network is detected to be completed, generating a Bayesian fault-tolerant test report based on the test case.

When the program version of each consensus node is upgraded, the rolling upgrade of the blockchain network is detected, and since the test cases are used for verifying the Bayesian fault tolerance of the blockchain network, a test report of the Bayesian fault tolerance of the blockchain network can be generated based on the test cases, and the test report provides detailed information about the fault tolerance performance of the blockchain network in the rolling upgrade process, namely whether the blockchain network has the Bayesian fault tolerance or not, and the fault tolerance degree in the Bayesian fault tolerance is not limited.

In the embodiment of the application, a rolling upgrade script is generated through acquired topological graph structure information of a blockchain network, the rolling upgrade script is used for upgrading a blockchain program version of a consensus node round by round, further, break points in the upgrade of the consensus node are automatically identified based on the rolling upgrade script, and test cases are triggered and executed based on the break points so as to automatically verify the Bayesian fault tolerance characteristics of the blockchain network, wherein the break points are used for describing the transition time of the consensus node from a historical program version to a target program version, and if the rolling upgrade of the blockchain network is detected, a Bayesian fault tolerance test report is generated based on the test cases; that is, in combination with the automatic test case, the Bayesian fault tolerance characteristic of the blockchain is continuously, effectively and automatically verified at the breakpoint, the safety and consistency of the system in the rolling upgrading process are effectively ensured, and after the rolling upgrading of the blockchain network is finished, the Bayesian fault tolerance test report of the blockchain network in the rolling upgrading process is automatically given, so that the verification cost is effectively reduced.

In one embodiment of the present application, another blockchain-based fault-tolerant verification method is provided, which can be applied to the implementation environment shown in fig. 1A or fig. 2, and the method can be performed by the consensus node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 4, and the blockchain-based fault-tolerant verification method extends step S330 to S410 to S430 on the basis of fig. 3. Steps S410 to S430 are described in detail below.

S410, in the running process of the rolling upgrade script, identifying the current breakpoint in the rolling upgrade script according to the change of the service state of the consensus node, and executing the test case at the current breakpoint.

In the embodiment of the application, the management device can implement upgrading of the consensus node by running the rolling upgrading script, the program version of the consensus node changes in the running process of the rolling upgrading script, and the service state of the corresponding consensus node also changes, so that the change of the program version of the consensus node in the rolling upgrading script can be determined by the change of the service state of the consensus node, so as to identify the current breakpoint in the rolling upgrading script, wherein the current breakpoint is the current transition time of the current upgraded consensus node from the historical program version to the target program version, and further the execution test case is automatically triggered in the transition time.

In an example, when the consensus node transits from the historical program version to the target program version, the service state of the consensus node may change briefly, and the transient change may be that the service state is stopped, for example, the service state of the consensus node 1 is switched from running to stopped, and then is switched from stopped to running, where the time between the two adjacent running may be used as the current breakpoint; the transient change may be that the state information corresponding to the service state is different, for example, the service state of the consensus node 1 is not stopped, but the corresponding state information is converted from the state 1 to the state 2, and the conversion time of converting the state 1 to the state 2 is used as the current breakpoint.

S420, after the common node corresponding to the current breakpoint is upgraded, identifying the next breakpoint in the rolling upgrade script, and executing the test case.

As described previously, the consensus nodes are upgraded in rounds, i.e., break points at different times correspond to consensus nodes of different rounds; after the update of the consensus node corresponding to the current breakpoint is finished, namely when the program version of the consensus node corresponding to the current breakpoint is the target program version, continuously identifying the next breakpoint in the rolling update script, wherein the next breakpoint is the version transition time of the consensus node in the next round; for example, the consensus node 1 and the consensus node 2 are two neighboring round-upgraded consensus nodes, the transition time corresponding to the consensus node 1 corresponds to the current breakpoint, the transition time corresponding to the consensus node 2 corresponds to the next breakpoint, and the execution of the test case is automatically triggered at the next breakpoint.

S430, continuing to identify the next breakpoint in the rolling upgrade script until the rolling upgrade of the blockchain network is completed.

In the embodiment of the application, after the upgrade of the consensus node corresponding to the next breakpoint is completed, the next breakpoint in the rolling upgrade script is continuously identified to execute the test case, until the last breakpoint in the rolling upgrade script is identified, the rolling upgrade of the blockchain network is completed, that is, the program versions of all the consensus nodes are upgraded to the target program version.

In an example, test cases executed at different breakpoints may be the same or different, and are not limited herein.

It should be noted that, for other detailed descriptions of steps S310 to S320 and S340 shown in fig. 4, please refer to steps S310 to S320 and S340 shown in fig. 3, and the detailed descriptions are omitted here.

In the embodiment of the application, the upgrade of the version of the consensus node is realized through the rolling upgrade script, in the script running process, the breakpoint is identified through the conversion of the service state of the consensus node, the accuracy of identification is ensured, and after the upgrade of the consensus node corresponding to the current breakpoint is completed, the next breakpoint in the rolling upgrade script is continuously identified, the reliability of the upgrade of the consensus node is ensured, and the omission of the upgrade is avoided.

The embodiment of the application provides another blockchain-based fault-tolerant verification method, which can be applied to the implementation environment shown in fig. 1A or fig. 2, and can be executed by the consensus node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 5, and extends step S320 to steps S510-S530 on the basis of fig. 3. The topology structure information in S310 includes node attribute information of each consensus node and a connection relationship between the consensus nodes. The steps S510 to S530 are described in detail below.

S510, determining upgrade rounds of the consensus nodes according to the node attribute information and the connection relation of the consensus nodes.

In the embodiment of the application, not all the consensus nodes can be upgraded at the same time, so that the upgrade round of each consensus node needs to be determined; the node attribute information is used for describing characteristic information belonging to the node, and comprises node type, hardware configuration, network bandwidth, performance data and geographic position information of the node; the connection relation between the consensus nodes comprises an adjacent relation and the adjacent distance, the node attribute information of each consensus node can help to determine the upgrade round, and the connection relation can determine the influence possibly caused by the upgrade round, so that the upgrade round of each consensus node can be reasonably determined through the node attribute and the connection relation, and the potential influence of the upgrade on the blockchain network is reduced to the greatest extent.

In an example, an initial upgrade round of each consensus node may be determined through node attribute information of each consensus node, and the initial upgrade round is adjusted through a connection relationship to obtain a final upgrade round of each consensus node.

S520, acquiring the target program version, and generating an upgrade strategy according to the node attribute information of the consensus node and the target program version.

In the embodiment of the application, the target program version is a latest program version, and the target program version supports forward compatibility; the management device may obtain the target program version based on the DAPP (decentralized application) of the blockchain, and may also receive the target program version sent by the third party trusted program developer.

After the target program version is acquired, the node attribute information can describe the characteristic information belonging to the node, and the management equipment can generate an upgrade plan for each consensus node according to the node attribute information of each consensus node and the target program version, so that an upgrade strategy is obtained through the upgrade plan combination of each consensus node. It should be noted that the upgrade strategy includes the operation steps necessary for the upgrade.

S530, generating a rolling upgrade script based on upgrade rounds and upgrade strategies of the consensus nodes.

In the embodiment of the application, a framework or a template of the script can be generated through an upgrade strategy, the framework comprises operation steps necessary for upgrade, and placeholders in the framework can be filled according to upgrade rounds of all consensus nodes to obtain a rolling upgrade script.

It should be noted that, for the detailed description of steps S310, S330 to S340 shown in fig. 5, please refer to steps S310, S330 to S340 shown in fig. 4, which are not described herein.

In the embodiment of the application, the upgrade turn is determined according to the node attribute information of the nodes and the connection relation between the nodes, and the upgrade strategy is generated according to the node attribute information and the target program version, so that the upgrade script is generated based on the upgrade turn and the upgrade strategy, the rationality of the upgrade script is ensured, and the nodes can be upgraded orderly and reliably.

The embodiment of the application also provides another blockchain-based fault-tolerant verification method, which can be applied to the implementation environment shown in fig. 1A or fig. 2, and can be executed by the common node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 6, and S520 is extended to S610-S630 on the basis of that shown in fig. 5. Steps S610 to S630 are described in detail below.

And S610, backing up the historical program version of the consensus node according to the program path of the consensus node, and storing the target program version into the program path.

S620, stopping the current running historical program version of the consensus node and starting the target program version.

And S630, reestablishing connection between the consensus node after updating the target program version and other consensus nodes to obtain an upgrading strategy.

In the embodiment of the application, an upgrade policy is obtained through S610 to S630, where in order to prevent a problem in an upgrade process and ensure rollback of a subsequent version, a historical program version of a consensus node needs to be backed up, and in addition, block data of the consensus node may be backed up to ensure safety of the data; when the program version is backed up, the historical program version can be extracted from the program path of the consensus node for backup, and in addition, after the target program version is acquired, the target program version and the related configuration file are stored in the program path.

And then stopping the current running historical program version, starting the target program version, and controlling the target program version to run in an expected mode so as to ensure the normal running of the target program version.

Because part of the consensus nodes are upgraded to the target program version, part of the consensus nodes are still in the history program version, and because the programs in the new version and the old version are possibly incompatible, the originally established peer-to-peer connection needs to be disconnected and reestablished, and then the consensus nodes after the program version is upgraded can communicate and synchronize with other nodes, and the peer-to-peer connection between other consensus nodes without the program version is not reestablished.

In an example, the process of disconnecting and reconnecting the consensus node after updating the target program version may also be regarded as a transition process of the consensus node from the historical program version to the target program version; the reestablishing connection between the consensus node of the updated program version and other consensus nodes can be reestablishing connection with other consensus nodes one by one, or reestablishing connection with a plurality of other consensus nodes at the same time, which can be determined according to the number of other consensus nodes, if the number of other consensus nodes is smaller than a certain threshold value, the connection is reestablished one by one, otherwise, the connection is reestablished simultaneously. The connection reestablishing can also be determined according to the number or type of the test cases required to be triggered, for example, the more the number of the test cases is, or the longer the execution time required by the test cases is, the connection is reestablished one by one, otherwise, the connection is reestablished simultaneously.

It should be noted that, for other detailed descriptions of the steps S310, S510, S530, S330 to S340 shown in fig. 6, please refer to the steps S310, S510, S530, S330 to S340 shown in fig. 5, and the detailed descriptions thereof are omitted.

In the embodiment of the application, the historical program version is backed up, the target program version is uploaded, the historical version is stopped, the program version is started, and connection is re-established, so that the version upgrading order and reliability are ensured.

In one embodiment of the present application, another blockchain-based fault-tolerant verification method is provided, which may be applied to the implementation environment shown in fig. 1A or fig. 2, and may be performed by the common node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 7, where the blockchain-based fault-tolerant verification method extends S510 to S710 to S730 on the basis of that shown in fig. 5, and steps S710 to S730 are described in detail below.

S710, determining the number of the consensus nodes to be upgraded in each round according to the total number of the consensus nodes in the blockchain network.

In the embodiment of the application, the more the total number of the consensus nodes in the blockchain network is, the more the number of the consensus nodes to be upgraded is in each round, and the fault tolerance of the Bayesian fault tolerance can be determined through the number of the consensus nodes to be upgraded in each round. In an example, if the total number of consensus nodes in the blockchain network is less than a preset number threshold, the number of consensus nodes to be upgraded in each round may be determined to be one; if the total number of the consensus nodes in the blockchain network is smaller than the preset number threshold, the number of the consensus nodes to be upgraded in each round can be determined to be at least two, for example, the number of the consensus nodes to be upgraded in each round is sequentially increased, the total number of the consensus nodes to be upgraded in the first round is assumed to be 10, the number of the consensus nodes to be upgraded in the second round is assumed to be 2, the number of the consensus nodes to be upgraded in the second round is assumed to be 3, the number of the consensus nodes to be upgraded in the third round is assumed to be 4, and the like.

S720, determining the upgrading priority of each consensus node according to the configuration information of each consensus node.

In the embodiment of the application, the node attribute information comprises configuration information, and the configuration information of different consensus nodes is different; in one example, the configuration information includes hardware configuration and network bandwidth, and the higher the corresponding upgrade priority, the consensus node with high performance hardware and network bandwidth, in order to improve overall network performance.

And S730, determining the upgrade turn of each consensus node according to the number of the consensus nodes to be upgraded in each turn and the upgrade priority of each consensus node.

In the embodiment of the present application, after determining the number of the to-be-upgraded consensus nodes in each round, each round of to-be-upgraded consensus nodes may be selected according to the upgrade priority of each consensus node, so as to determine the upgrade round of each consensus node, and it may be understood that the higher the upgrade priority of the consensus node, the earlier the corresponding upgrade round. For example, the consensus nodes 1-6 correspond to the upgrade priorities of 1-6, the number of the consensus nodes to be upgraded in each round is 2, the consensus nodes of the first round of upgrade are nodes 1-2, the consensus nodes of the second round of upgrade are nodes 3-4, and the consensus nodes of the third round of upgrade are nodes 5-6.

It should be noted that, for other detailed descriptions of steps S310, S520 to S530, S330 to S340 shown in fig. 7, please refer to steps S310, S520 to S530, S330 to S340 shown in fig. 5, and the detailed descriptions thereof are omitted.

According to the method and the device for upgrading the shared nodes, the number of the shared nodes to be upgraded in each round is determined through the total number of the shared nodes in the blockchain network, and the determined upgrading priority of each shared node is combined, so that the determined upgrading rounds of the shared nodes accord with the actual situation of the blockchain network, and the stabilization of the blockchain network is facilitated.

The embodiment of the application provides a blockchain-based fault-tolerant verification method, which can be applied to an implementation environment shown in fig. 1A or fig. 2, and can be executed by a common node shown in fig. 1A or a management device shown in fig. 2, as shown in fig. 8, and is extended to S720 to S810-S820 on the basis of that shown in fig. 7. Steps S810 to S820 are described in detail below.

And S810, sorting the consensus nodes according to the node numbers of the consensus nodes to obtain an initial sorting result.

Each consensus node is respectively corresponding to a unique node number, and different consensus nodes can be distinguished through the node numbers, so that in the embodiment of the application, the initial sequencing result can be obtained by sequencing the consensus nodes according to the size of the node numbers of the consensus nodes.

In an example, the node number of each consensus node may be related to the order in which the consensus node joined the blockchain network, i.e., the earlier the blockchain network was accessed, the smaller the node number.

In other embodiments, the consensus nodes may also be randomly ranked to obtain an initial ranking result.

S820, adjusting the initial sequencing result according to the performance information of each consensus node and the distance information between the consensus nodes to determine the upgrading priority of each consensus node.

In the embodiment of the application, the configuration information of the node comprises performance information of the node, the performance information is determined based on the hardware configuration of the node and the network bandwidth, and the node priority upgrading of the high-performance information is beneficial to the overall network performance; the configuration information of the nodes further comprises the geographical positions of the nodes, the distance information among the nodes can be obtained through the geographical positions of the nodes, and other nodes with relatively close distances are preferentially considered after one common node is determined because the geographical positions of the nodes possibly influence data transmission delay.

For example, the initial sorting result is that the node 1-6 is the node 2, the performance of the node 2 is optimal, the node 2 is sorted to the first, the performance of the node 1 and the node 3 is better, the performance difference is smaller than a preset threshold, but the distance between the node 3 and the node 2 is equal to the distance between the node 1 and the node 2, the node 3 is sorted to the second, and the node 1 is sorted to the third; however, if the difference between the node 1 and the node 3 is greater than the preset threshold, and the performance of the node 1 is better than that of the node 3, the node 1 can be directly ranked second and the node 3 can be ranked third without considering the distance; assuming that the performances of the nodes 4-6 are the same, and the difference of the distances from the nodes 2 is smaller than a preset distance value, the ordering among the nodes 4-6 does not need to be adjusted, and finally the upgrading priority of each consensus node is obtained as the node 2, the node 3, the node 1 and the node 4-6.

In one example, when the initial ranking result is adjusted, the primary consensus nodes may be ranked first directly without regard to performance to ensure continuity of the primary consensus function.

It should be noted that, for other detailed descriptions of steps S310, S710, S730, S520 to S530, S330 to S340 shown in fig. 8, please refer to steps S310, S710, S730, S520 to S530, S330 to S340 shown in fig. 7, and the detailed descriptions thereof are omitted herein.

In the embodiment of the application, the nodes are sequenced through the node numbers to obtain the initial sequencing result, and the sequencing result is adjusted through the performance information of the nodes and the distance information between the nodes, so that the upgrading priority of the consensus node is determined to conform to the attribute of the node, and the reliability of the upgrading priority determination is ensured.

The embodiment of the application provides another blockchain-based fault-tolerant verification method, which can be applied to the implementation environments shown in fig. 1A or fig. 2, and can be executed by the common node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 9, and S330 is extended to S910 to S930 on the basis of fig. 3. The steps S910 to S930 are described in detail below.

S910, obtaining test cases corresponding to the test scenes respectively, and obtaining the test cases.

S920, recognizing a breakpoint in the upgrade of the consensus node based on the rolling upgrade script, and selecting at least one target test case from a plurality of test cases for the current blockchain network according to the target test scene in the upgrade process of the current round of the consensus node.

S930, automatically executing the target test case based on the breakpoint.

In the embodiment of the application, a plurality of test cases exist, each test case corresponds to a different test scene, and in one example, one test scene represents one possible Bayesian attack or network fault; a test scenario may also represent a blockchain operation, such as a contract read, write operation; block packing and validation operations, etc. The test cases are pre-written according to the test scene, and can be written by block chain points or other third-party equipment.

In the upgrading process of the current round consensus node, the current breakpoint is identified, namely when the current round consensus node transits from the historical program version to the target program version, at least one target test case is required to be selected for the current blockchain network according to the target test scene, wherein the current blockchain network is a network formed by other consensus nodes except the current round consensus node.

The target test scene can be any test scene, can be an unused test scene, can also be a test scene corresponding to the node performance level of the current round consensus node, wherein the node performance level is the average value of the current round consensus node performance, the test scenes corresponding to different node performance levels are different, and the higher the node performance level is, the more the scenes of the corresponding target test scene are, and the more the content of the corresponding test cases are. For example, if the performance level of the current round consensus node is medium, the corresponding target test scene is a basic block operation scene; and if the performance level of the current consensus node is high, the corresponding target test scene is a block consensus scene.

If at least two target test cases are automatically executed at the breakpoint, the execution sequence of the at least two target test cases may be executed one by one, and if the execution of the at least two target test cases does not conflict, the execution may also be executed simultaneously, which is not limited herein.

It should be noted that, for other detailed descriptions of the steps S310 to S320 and S340 shown in fig. 9, please refer to the steps S310 to S320 and S340 shown in fig. 3, and the detailed descriptions are omitted here.

In the embodiment of the application, a plurality of test cases respectively corresponding to the test scenes are provided, so that in the upgrading process of the consensus node in each round, the corresponding test case is selected, and the test case is automatically executed at the breakpoint, so that the test case meets various scenes, and the test is more comprehensive and reliable.

The embodiment of the application provides another blockchain-based fault-tolerant verification method, which can be applied to the implementation environments shown in fig. 1A or fig. 2, and can be executed by the common node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 10, and S910 is extended to steps S1010-S1030 on the basis of that shown in fig. 9. The steps S1010 to S1030 are described in detail below.

S1010, generating a test target aiming at the Bayesian fault tolerance according to the test property and the fault tolerance degree of the Bayesian fault tolerance.

S1020, determining a plurality of test scenes to be covered according to the test targets.

S1030, determining data required by the test according to the plurality of test scenes to generate test cases corresponding to the plurality of test scenes respectively.

In the embodiment of the application, the test property of the bayer fault tolerance is used for describing a test direction and fault types of the fault tolerance, wherein the test direction comprises the fault tolerance of node operation, message transmission and a consensus algorithm, and the fault types of the fault tolerance comprise whether the fault tolerance is tested for the bayer attack or not or the recovery capability of a network when the node is down; the degree of tolerance of the bayer fault tolerance is used to describe the maximum degree of fault tolerance that can be tolerated, i.e. how many bayer nodes or erroneous operations are tolerated; based on the defined test properties and fault tolerance levels, specific test targets are generated, which can be targets for different fault tolerance scenarios, such as testing the fault tolerance performance when multiple nodes in the network simultaneously appear in the Bayesian operation, or testing the influence of single node Bayesian operation on the system.

According to the test targets, different test scenes needing to be covered are determined, wherein the test scenes comprise various possible Bayesian fault-tolerant conditions, for example, the scenes can comprise node downtime, message tampering, double-flower attack and the like; for each test scenario, required test data needs to be defined, wherein the data required for testing comprises case preparation data, including initializing a blockchain network, preparing an attack tool, configuring node states and the like, and case execution data, including input data, node states, message passing conditions and the like. It will be appreciated that the test data should be sufficiently complex and diverse to simulate a real bayer pattern.

And generating a test case based on the test scene and the defined test data. In an example, each test case should include the following: inputting data and parameters; expected test results or operations; testing the steps and sequence of execution; an expected fault tolerance performance indicator (e.g., whether the network is able to properly detect and handle the bayer node).

It should be noted that, for other detailed descriptions of steps S310 to S320, S920 to S930, and S340 shown in fig. 10, please refer to steps S310 to S320, S920 to S930, and S340 shown in fig. 9, and the detailed descriptions thereof are omitted herein.

In the embodiment of the application, the plurality of test scenes to be covered are determined through the Bayesian fault-tolerant test targets, and further, data required by the test are determined through the test scenes, so that test cases aiming at the Bayesian fault tolerance can be effectively generated, and the fault-tolerant performance of the blockchain can be comprehensively tested and verified.

It should be noted that, another blockchain-based fault-tolerant verification method is provided in the embodiments of the present application, and the blockchain-based fault-tolerant verification method may be applied to the implementation environment shown in fig. 1A or fig. 2, and the method may be performed by the consensus node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 11, and steps S1110 to S1130 are added after S330 on the basis of the method shown in fig. 3, which is described in detail below.

S1110, obtaining a service test state corresponding to the current blockchain network according to the test case.

S1120, acquiring a service expected state corresponding to the test case.

S1130, generating a Bayesian fault-tolerant subtest report of the current blockchain network according to the service test state and the service expected state.

In the embodiment of the application, when the test case is automatically executed, the functions and the performances of the blockchain network can be tested; the service test state corresponding to the current blockchain network is used for describing the operation or response actually generated by the consensus node under the test case; the test cases correspond to service expected states for describing operations or responses expected to occur under the test cases at the consensus nodes. For example, the test case is used to verify whether each case key step in the upgrade process is performed as expected, and it is assumed that the test case is a response that some transactions can be properly packaged and confirmed, and whether the test case can be properly packaged and confirmed is checked.

The service test state is a response of the common node in practice according to the test case, and the service test state and the service expected state are compared to generate a sub-test report of the Bayesian fault tolerance of the current blockchain network. If the service test state is the same as the service expected state, a subtest report with Bayesian fault tolerance of the current blockchain network can be generated; if the service test state and the service expected state are different, a subtest report that the current blockchain network may not have the Bayesian fault tolerance can be directly generated, and the Bayesian fault tolerance subtest report can be further determined based on the number of nodes of the current blockchain network.

It should be noted that, in each round of the upgrade process of the consensus node, a wheel test report is generated.

It should be noted that, for other detailed descriptions of the steps S310 to S340 shown in fig. 11, please refer to the steps S310 to S340 shown in fig. 3, and the detailed descriptions are omitted here.

According to the method and the device for testing the Byzantine fault tolerance of the current block chain network, the service testing state and the service expected state corresponding to the testing case can be used for effectively generating the Byzantine fault tolerance testing report of the current block chain network, so that the relevant performance condition of the current block chain network can be conveniently obtained.

The embodiment of the application provides another blockchain-based fault-tolerant verification method, which can be applied to the implementation environments shown in fig. 1A or fig. 2, and can be executed by the common node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 12, and extends S340 to steps S1210-S1230 on the basis of the one shown in fig. 3. Steps S1210 to S1230 are described in detail below.

S1210, obtaining subtest reports corresponding to the test cases triggered by each round of upgrading, and obtaining a plurality of subtest reports, wherein the number of the consensus nodes to be upgraded in each round is sequentially increased.

In the embodiment of the application, each round of upgrading can trigger a test case, each round of upgrading can generate a sub-test report, and after the rolling upgrading of the block chain network is completed, a plurality of sub-test reports respectively corresponding to the rounds of upgrading can be obtained; the number of the consensus nodes to be upgraded in each round of upgrading is sequentially increased, for example, 1 consensus node to be upgraded in the first round of upgrading, 2 consensus nodes to be upgraded in the second round of upgrading, and the like.

S1220, traversing the plurality of sub-test reports sequentially from the sub-test report corresponding to the last round of upgrading as a base point.

S1230, if the sub-test report of the last traversal does not reach the expectation, the sub-test report of the current traversal reaches the expectation, and the maximum fault tolerance characteristic of the Bayesian fault tolerance is determined according to the sub-test report of the current traversal, so as to generate a test report of the Bayesian fault tolerance.

As the number of the consensus nodes to be upgraded in each round is sequentially increased, the nodes of the blockchain network in each round are sequentially reduced, the nodes in the blockchain network in the last round of upgrading are minimum, and the performance of the Bayesian fault tolerance of the blockchain network containing all the consensus nodes can be determined through the performances of the blockchain networks in different rounds, such as the maximum fault tolerance of the blockchain network in the first round of upgrading and the minimum fault tolerance of the blockchain network in the last round of upgrading.

For a plurality of sub-test reports, traversing the sub-test reports in sequence from the sub-test report corresponding to the last round of upgrading as a base point, and if the sub-test report traversed last time does not reach the expectation, indicating that the blockchain network corresponding to the sub-test report traversed last time does not have Bayesian fault tolerance; and if the currently traversed sub-test report reaches the expectation, the block chain network corresponding to the currently traversed sub-test report has the Bayesian fault tolerance, and at the moment, the maximum fault tolerance characteristic of the Bayesian fault tolerance can be determined according to the currently traversed sub-test report, so that the Bayesian fault tolerance test report is generated.

For example, if the sub-test report traversed last time does not reach the expectation, the number of nodes in the blockchain network corresponding to the sub-test report traversed last time is 4, and the number of nodes in the blockchain network corresponding to the sub-test report traversed currently is 3, the maximum fault tolerance of the blockchain network including 5 common nodes is 2, and then the test report of the Bayesian fault tolerance is generated.

It should be noted that, for other detailed descriptions of the steps S310 to S330 shown in fig. 12, please refer to the steps S310 to S330 shown in fig. 3, and the detailed descriptions are omitted here.

In the embodiment of the application, after the subtest report corresponding to the test case triggered by each round of upgrading is obtained, the subtest report corresponding to the last round of upgrading is traversed, so that the maximum fault tolerance characteristic of the Bayesian fault tolerance can be fast generated, and further the Bayesian fault tolerance test report can be effectively generated in time.

The embodiment of the application provides another fault-tolerant verification method based on the blockchain, which can be applied to the implementation environment shown in fig. 1A or fig. 2, and can be executed by the common node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 13, and S340 is extended to S1310-S1320 based on fig. 3, which is described in detail below.

S1310, after the rolling upgrade of the block chain network is completed, detecting the consensus service of the block chain network to obtain the running state of the consensus service.

In the embodiment of the application, after the rolling upgrade of the blockchain network is completed, some comprehensive tests and verification are performed to check whether the blockchain network can normally operate and whether the target program version is reliable, specifically, the consensus service of the blockchain network is detected, for example, whether all nodes can normally participate in consensus is checked, and the state of the blockchain is agreed, so that the running state of the consensus service is obtained, and the running state of the consensus service comprises that the consensus service is normal, namely, all nodes can normally participate in consensus and agree; the operational state of the consensus service includes a consensus service exception, i.e., a blockchain state where some nodes cannot normally participate in the consensus or cannot agree.

In an example, it is also possible to detect whether the versions of all nodes are consistent first and consistent with the expected target program version, and detect the consensus service after the version detection is passed; in addition, it is also possible to check whether the throughput and delay of the network meet expectations without significant degradation or fluctuations occurring; checking whether the security and reliability of the network meet expectations can resist a certain proportion of faults or attacks.

S1320, generating a Bayesian fault-tolerant test report according to the test cases and the running states of the consensus service.

In the embodiment of the application, the Bayesian fault tolerance characteristic of the blockchain network of each round can be obtained through the test case triggered by each round of upgrading, the Bayesian fault tolerance characteristic of the blockchain network containing all the consensus nodes can be obtained through the running state of the consensus service, and further the Bayesian fault tolerance test report generated based on the test case and the running state of the consensus service comprises the test report of the Bayesian fault tolerance of the local blockchain network and the global blockchain network.

It should be noted that, for other detailed descriptions of the steps S310 to S330 shown in fig. 13, please refer to the steps S310 to S330 shown in fig. 3, and the detailed descriptions are omitted here.

In the embodiment of the application, after the rolling upgrade of the blockchain network is finished, comprehensive testing and verification are performed to check whether the blockchain network can normally operate, and then the Bayesian fault tolerance characteristics of the blockchain network including global and local are generated by combining the test cases, so that the reliability and the comprehensiveness of the verification are ensured.

It should be noted that, the embodiment of the present application provides another blockchain-based fault-tolerant verification method, which may be applied to the implementation environment shown in fig. 1A or fig. 2, and may be performed by the consensus node shown in fig. 1A or the management device shown in fig. 2, as shown in fig. 14, and the blockchain-based fault-tolerant verification method extends S340 in fig. 3 to S1410-S1430 on the basis of that shown in fig. 3. Steps S1410 to S1430 are described in detail below.

S1410, determining a target node with repeated abnormality in the consensus nodes based on the Bayesian fault-tolerant test report.

In the embodiment of the application, the number of the Bayesian fault-tolerant test reports can be multiple, namely, each round of the Bayesian fault-tolerant test report of the corresponding blockchain network is upgraded, and each round of abnormal nodes can be obtained through each round of the Bayesian fault-tolerant test report, wherein the abnormal nodes comprise nodes which are down, disconnected or wrongly; for example, the test case triggered by each round of upgrading comprises the steps of carrying out consensus on the simulated blocks through the consensus nodes in the corresponding block chain network, and taking the consensus nodes which are not verified by the consensus as abnormal nodes; therefore, the consensus node in which the abnormality repeatedly occurs is extracted from the test report of each round of the bayer busy fault tolerance as the target node.

In an example, the determination of the target node in which the abnormality repeatedly occurs in the consensus nodes may be that the consensus node with the repetition number greater than the preset threshold is used as the target node, for example, the node 1 is repeated 2 times to generate the abnormality, the node 2 is repeated 3 times to generate the abnormality, and the repetition number of the abnormality of the node 1 and the node 2 is greater than the threshold 1, that is, the node 1 and the node 2 are both used as the target nodes.

S1420, if the number of the target nodes is greater than the number of the preset nodes, rolling back the program version of the consensus node of the blockchain network.

S1430, removing the target node from the blockchain network if the number of the target nodes is less than the preset number of nodes.

In this embodiment of the present application, if the number of target nodes is greater than the number of preset nodes, it indicates that after the target program version is updated, the entire blockchain network is more unstable, and a rollback process needs to be performed on the program versions of all the consensus nodes in the blockchain network, that is, the program versions of the consensus nodes are rolled back from the target program version to the history program version.

If the number of the target nodes is smaller than the number of the preset nodes, only a few consensus nodes are unstable after the target program version is updated, and the consensus service of the whole blockchain network is not influenced, and at the moment, the target nodes can be removed from the blockchain network; in an example, if the number of target nodes is greater than the preset number of nodes, no processing may be performed on the target nodes.

It should be noted that, the detailed description of steps S310 to S330 shown in fig. 14 is please refer to steps S310 to S330 shown in fig. 3, and the detailed description is omitted herein.

In the embodiment of the application, the stability of the blockchain network formed after the version is upgraded is determined by determining the comparison between the number of the target nodes with the abnormal repeated occurrence of the common node and the number of the preset nodes, so that different treatments are performed, and the stable availability of the blockchain network is ensured.

For ease of understanding, the block chain-based fault tolerance verification method provided in the embodiments of the present application is described in detail below based on the implementation environment shown in fig. 1A or fig. 2.

In the fault tolerance verification method based on the blockchain, in the rolling upgrading of the analog blockchain, the Bayesian fault tolerance characteristic of the blockchain is continuously, effectively and automatically verified at the breakpoint by combining the automatic use case.

Because the distributed consensus of the blockchain has certain fault tolerance, the updating of the consensus nodes by the DAPP based on the blockchain usually adopts rolling release, and certainly, an application program is required to support forward compatibility, and in the rolling release process, the Bayesian fault tolerance characteristics of the blockchain are just verified by combining with the automatic use cases due to the phenomena of network disconnection, process restarting and the like. The upgrade process of the consensus node includes.

Suppose that a blockchain network consisting of 5 v1 blockchain program version consensus nodes (nodes a-E) is now required to be upgraded to a v2 program version, the rolling upgrade steps are as follows.

(1) The A node v1 program version and the configuration file are backed up, and the A node v2 version blockchain executable program is prepared. The step is to prevent problems in the upgrading process, so that the node A cannot be restored to the original state; at the same time, a new version of the program is prepared for fast switching.

(2) Stopping the V1 program version of the A node, starting the V2 program version, and connecting the original peer-to-peer connection to be reconnected, wherein as shown in FIG. 15, the DAPP client can be connected with the consensus node cluster through the SPV cluster or the synchronous node cluster of the node end, so that the DAPP client sends the V2 program version to the consensus node cluster; for the consensus node cluster, the nodes B-E are all v1 versions, the peer-to-peer connection is established with the v1 version of the node A originally, and after the connection is disconnected, the peer-to-peer connection is re-established with the node A of the v2 version. The step is to let the node A run the new version program and re-join the network; because the programs of the new version and the old version may be incompatible, the originally established peer-to-peer connection needs to be disconnected and reestablished, so that the A node can communicate and synchronize with other nodes.

(3) During the process stop, process restart, connection disconnection, connection reconnection, the availability of the DAPP application is checked, especially if the front-end operation involving on-chain interactions is affected. This step is to check whether the DAPP application is affected during the upgrade process. In an example, if the DAPP application relies on the service or data provided by the a node, then a service disruption or data inconsistency may occur during the a node upgrade process; therefore, the problems need to be detected and repaired in time so as to ensure the normal operation of the DAPP application end; in another example, if during an upgrade, front-end operations that interact on the chain, such as generating blocks, block uplinks, etc., are affected, it is determined that the DAPP application is not available.

(4) Stopping the node B v1 program version, starting the v2 program version, and re-connecting the originally established peer-to-peer connection, wherein as shown in FIG. 16, for the consensus node cluster, the node A is upgraded to the v2 version, the nodes C-E are all v1 versions, the peer-to-peer connection is established with the v1 version of the node B, and after the connection is required to be disconnected, the peer-to-peer connection is re-established with the node B of the v2 version.

(5) With this reciprocation, all consensus nodes are scrolled up until all blockchain programs are updated to v2 version, again looking at the chunking situation of the blockchain bottom layer, the stability of the peer-to-peer connection and the availability of DAPP front-end interactions. The method comprises the steps of upgrading all the consensus nodes in the same way, and checking whether the network and the application run normally after the upgrading is finished.

It should be noted that, at the above steps (2), (4) and (5), that is, at the break point of the bayer fault tolerance, the execution of the automation use case may be automatically triggered in the scroll upgrade script, so as to verify the bayer fault tolerance characteristic.

In the rolling upgrading process, when one node is switched to a new version, a short time period exists, namely, a breakpoint is needed to verify whether the network can still normally output blocks, synchronize data and process transactions or not, and the problems of bifurcation or attack and the like do not occur at the breakpoint, so that the Bayesian fault tolerance of the blockchain is verified, and the availability of the blockchain is determined. This requires modeling of various scenarios by automating use cases and checking the status of the network and applications. If all break points pass the test and no abnormality or error is found, the blockchain network is indicated to have good Bayesian fault tolerance and version update can be carried out in a manner supporting rolling upgrade.

In the embodiment of the application, the fault tolerance verification method based on the blockchain comprises continuously, effectively and automatically verifying the Bayesian fault tolerance characteristic of the blockchain at a breakpoint in combination with an automatic use case in the rolling upgrade of the analog blockchain, and particularly shown in fig. 17.

S1701, obtaining a topological graph structure of the blockchain network.

In a test environment or a pre-release environment, a topological graph structure of the blockchain network is obtained, wherein the topological graph structure comprises the number of nodes, the ip, the blockchain program path and the like. The topology may learn the structure and configuration of the blockchain network in preparation for rolling upgrades. The topology of a blockchain network refers to the location and connection relationships of the various nodes in the network, e.g., how many consensus nodes are, what their ip addresses are, what paths they run the blockchain program to deposit on, etc. This information may be obtained through the management interface of the access node or using some network scanning tool.

S1702, automatically generating a rolling upgrade script of the consensus node based on the network topology structure.

In the embodiment of the application, an automatic script is generated according to the network topology structure and is used for upgrading the consensus nodes round by round. The script contains operations required for upgrading each consensus node, such as backing up data and programs, uploading new program versions, stopping node services, starting new version services, and the like; these operations may be implemented by invoking some system commands or interfaces provided by the blockchain program. Specifically, the scroll upgrade script should include the following key steps.

Backup data and programs: before upgrading, the data and the program of the node are copied to a safe position so as to prevent the upgrade from failing or recovering when abnormal conditions occur.

Uploading a new program version: and uploading the new version of the blockchain program to a server where the node is located, and covering or replacing the old version of the program.

Stopping node service: before updating the program, the service of the node is stopped, the connection with other nodes is disconnected, and data inconsistency or consensus errors are avoided.

Starting a new program version: and starting a new version of blockchain program, reconnecting to the network, and adding to the consensus process.

S1703, automatically identifying a breakpoint in the rolling upgrading script, triggering execution of the block chain automation use case, and performing assertion to verify the Bayesian fault tolerance.

In the embodiment of the application, the breakpoint is between the service of stopping the old version and the service of starting the new version, and in the process of disconnection and reconnection; to verify the Bayesian fault tolerance, breakpoints need to be set in the rolling upgrade script, such as triggering some automated test cases to test the functionality and performance of the blockchain network between stopping one old version service and starting one new version service at a time; these use cases can simulate various scenarios, such as sending transactions, querying data, checking out block conditions, etc., and declaring the results to determine whether they meet expectations. If all assertions pass, then this indicates that no exception or error has occurred at the breakpoint, otherwise, a problem has occurred and that investigation and repair is required to determine the Bayesian fault tolerance capability. For testing, for example: send some transactions into the network and check if they can be properly packaged and confirmed. The status of some accounts or contracts is queried and checked for compliance with expectations. Simulate some fault or attack scenarios and check if the network can recover normally.

S1704, based on the rolling upgrade script, identifying the next breakpoint, triggering the automatic use case to execute, and asserting and judging the expected result.

The rolling upgrade script continues to be executed and testing and verification is performed at each breakpoint. Based on the rolling upgrade script, the next node to be upgraded can be identified, and the steps S1702 and S1703 are repeated until all nodes are upgraded; after each triggering of the automatic use case execution, assertion is needed to judge whether the test result meets the expectations.

S1705, the process is repeated until the rolling upgrade is finished, all programs are upgraded to a new version, and the performance verification of the Bayesian fault tolerance is finished.

And upgrading all the consensus nodes in the same way, and performing automatic use case execution and assertion judgment at each breakpoint until all the nodes are upgraded to a new version, and ending the characteristic verification of the Bayesian fault tolerance.

After the rolling upgrade is finished, some comprehensive tests and verification are performed to check whether the blockchain network can normally operate or not, and the blockchain network has the Bayesian fault tolerance characteristic. For example: it is checked whether the versions of all nodes are consistent and match the expected new version. It is checked whether all nodes can normally participate in the consensus and agree on a blockchain state. It is checked whether the throughput and delay of the network are in line with expectations and no significant degradation or fluctuations occur. Checking whether the security and reliability of the network meet expectations can resist a certain proportion of faults or attacks. If no problem occurs, it is indicated that the rolling upgrade completed successfully and the blockchain network has good Bayesian fault tolerance.

The embodiments of the apparatus of the present application are described herein as being used to perform the blockchain-based fault-tolerant verification method of the above embodiments of the present application. For details not disclosed in the embodiments of the apparatus of the present application, please refer to the embodiments of the blockchain-based fault-tolerant verification method described in the present application.

The embodiment of the application provides a fault-tolerant verification device based on a blockchain, as shown in fig. 18, which can be configured in a blockchain node or a management device, and the device comprises.

An obtaining module 1810 is configured to obtain topology information of the blockchain network.

And the generating module 1820 is configured to generate a rolling upgrade script according to the topology structure information, where the rolling upgrade script is used to upgrade the blockchain program version of the consensus node round by round.

And an execution module 1830, configured to identify a breakpoint in the upgrade of the consensus node based on the rolling upgrade script, and execute a test case for verifying a bayesian fault tolerance of a blockchain network based on the breakpoint trigger, where the breakpoint is used to describe a transition position of the consensus node from a historical program version to a target program version.

The generating module 1820 is further configured to generate a test report of the bayer process fault tolerance based on the test case if the blockchain network rolling upgrade is detected to be completed.

In one embodiment of the present application, based on the foregoing solution, the execution module is further configured to identify, during running of the rolling upgrade script, a current breakpoint in the rolling upgrade script according to a change in a service state of the common node, and execute the test case at the current breakpoint; after the common node corresponding to the current breakpoint is upgraded, identifying the next breakpoint in the rolling upgrade script to execute the test case; and continuing to identify the next breakpoint in the rolling upgrade script until the rolling upgrade of the blockchain network is completed.

In one embodiment of the present application, based on the foregoing scheme, the topology structure information includes node attribute information of each consensus node and a connection relationship between each consensus node; the generation module is further used for determining upgrading rounds of the consensus nodes according to the node attribute information of the consensus nodes and the connection relation; acquiring a target program version, and generating an upgrade strategy according to node attribute information of the consensus node and the target program version; and generating the rolling upgrade script based on the upgrade rounds of the consensus nodes and the upgrade strategies.

In one embodiment of the present application, based on the foregoing scheme, the node attribute information of the consensus node includes a program path of the consensus node; the generation module is further used for backing up historical program versions of the consensus node according to a program path of the consensus node, and storing the target program versions into the program path; stopping the current running historical program version of the consensus node, and starting the target program version; and reestablishing connection between the consensus node after updating the target program version and other consensus nodes to obtain the upgrading strategy.

In one embodiment of the present application, based on the foregoing scheme, the node attribute information of the consensus node includes configuration information of the consensus node; the generation module is further used for determining the number of the consensus nodes to be upgraded in each round according to the total number of the consensus nodes in the blockchain network; determining the upgrading priority of each consensus node according to the configuration information of each consensus node; and determining the upgrading turn of each consensus node according to the number of the consensus nodes to be upgraded in each turn and the upgrading priority of each consensus node.

In one embodiment of the present application, based on the foregoing solution, the generating module is further configured to sort the consensus nodes according to the node numbers of the consensus nodes to obtain an initial sorting result; and adjusting the initial sequencing result according to the performance information of each consensus node and the distance information between each consensus node so as to determine the upgrading priority of each consensus node.

In an embodiment of the present application, based on the foregoing solution, the execution module is further configured to obtain test cases corresponding to multiple test scenes, to obtain multiple test cases; in the upgrading process of the current round consensus node, selecting at least one target test case from the plurality of test cases for the current blockchain network according to a target test scene; the current blockchain network is a network formed by other consensus nodes except the current round consensus node; and automatically executing the target test case based on the breakpoint.

In one embodiment of the present application, based on the foregoing solution, the execution module is further configured to generate a test target for the bayer fault tolerance according to the test property and the fault tolerance degree of the bayer fault tolerance; determining a plurality of test scenes to be covered according to the test targets, wherein each test scene is used for representing a Bayesian attack; and determining data required by the test according to the plurality of test scenes to generate test cases corresponding to the plurality of test scenes respectively.

In one embodiment of the present application, based on the foregoing solution, the generating module is further configured to obtain a service test state corresponding to the current blockchain network according to the test case; acquiring a service expected state corresponding to the test case; and generating a Bayesian fault-tolerant subtest report of the current blockchain network according to the service test state and the service expected state.

In one embodiment of the present application, based on the foregoing solution, the generating module is further configured to obtain a subtest report corresponding to a test case triggered by each round of upgrade, to obtain a plurality of subtest reports, where the number of consensus nodes to be upgraded in each round is sequentially increased; traversing the plurality of sub-test reports sequentially from the sub-test report corresponding to the last round of upgrading as a base point; if the sub-test report of the last traversal does not reach the expectation, determining the maximum fault tolerance characteristic of the Bayesian fault tolerance according to the sub-test report of the current traversal so as to generate the test report of the Bayesian fault tolerance.

In one embodiment of the present application, based on the foregoing solution, the generating module is further configured to detect a consensus service of the blockchain network after the rolling upgrade of the blockchain network is completed, so as to obtain an operation state of the consensus service; and generating a test report of the Bayesian fault tolerance according to the test case and the running state of the consensus service.

In one embodiment of the present application, based on the foregoing solution, the apparatus further includes a processing module configured to determine, based on the bayer fault-tolerant test report, a target node in the consensus node in which an anomaly repeatedly occurs; if the number of the target nodes is greater than the number of the preset nodes, rollback processing is carried out on the program version of the consensus node of the blockchain network; and if the number of the target nodes is smaller than the preset number of nodes, removing the target nodes from the blockchain network.

It should be noted that, the apparatus provided in the foregoing embodiments and the method provided in the foregoing embodiments belong to the same concept, and the specific manner in which each module and unit perform the operation has been described in detail in the method embodiments, which is not repeated herein.

Embodiments of the present application also provide an electronic device including one or more processors, and a storage device, where the storage device is configured to store one or more computer programs that, when executed by the one or more processors, cause the electronic device to implement a blockchain-based fault-tolerant verification method as described above.

It should be noted that, the computer system 1900 of the electronic device shown in fig. 19 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application, where the electronic device may be a client or a server.

As shown in fig. 19, the computer system 1900 includes a processor (Central Processing Unit, CPU) 1901 that can perform various appropriate actions and processes, such as performing the methods in the above-described embodiments, according to a program stored in a Read-Only Memory (ROM) 1902 or a program loaded from a storage section 1908 into a random access Memory (Random Access Memory, RAM) 1903. In the RAM 1903, various programs and data required for system operation are also stored. The CPU 1901, ROM 1902, and RAM 1903 are connected to each other via a bus 1904. An Input/Output (I/O) interface 1905 is also connected to bus 1904.

In some embodiments, the following components are connected to I/O interface 1905: an input section 1906 including a keyboard, a mouse, and the like; an output portion 1907 including a Cathode Ray Tube (CRT), a liquid crystal display (Liquid Crystal Display, LCD), and a speaker; a storage portion 1908 including a hard disk or the like; and a communication section 1909 including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section 1909 performs communication processing via a network such as the internet. The driver 1910 is also connected to the I/O interface 1905 as needed. Removable media 1911, such as magnetic disks, optical disks, magneto-optical disks, semiconductor memories, and the like, are installed on drive 1910 as needed so that a computer program read therefrom is installed into storage portion 1908 as needed.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 1909, and/or installed from the removable media 1911. The computer program, when executed by a processor (CPU) 1901, performs the various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory), a flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer programs.

The units or modules described in the embodiments of the present application may be implemented by software, or may be implemented by hardware, where the described units or modules may also be provided in a processor. Where the names of the units or modules do not in some way constitute a limitation of the units or modules themselves.

Another aspect of the present application also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method as described above. The computer-readable storage medium may be included in the electronic device described in the above embodiment or may exist alone without being incorporated in the electronic device.

Another aspect of the present application also provides a computer program product comprising a computer program stored in a computer readable storage medium. The processor of the electronic device reads the computer program from the computer readable storage medium and executes the computer program to cause the electronic device to perform the methods provided in the various embodiments described above.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit, in accordance with embodiments of the present application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains.

The foregoing is merely a preferred exemplary embodiment of the present application and is not intended to limit the embodiments of the present application, and those skilled in the art may make various changes and modifications with great convenience according to the main concept and spirit of the present application, so that the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A blockchain-based fault-tolerant verification method, comprising:

obtaining topological graph structure information of a block chain network;

generating an automatically executed rolling upgrade script according to the topological graph structure information, wherein the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round;

identifying a breakpoint in the upgrading of the common node based on the rolling upgrading script, and executing a test case for verifying the Bayesian fault tolerance of the blockchain network based on the breakpoint trigger, wherein the breakpoint is used for describing the transition time of the common node from a historical program version to a target program version;

If the rolling upgrading of the blockchain network is detected to be finished, generating a Bayesian fault-tolerant test report based on the test case, wherein the test report comprises detailed information about the Bayesian fault-tolerant performance of the blockchain network in the rolling upgrading process.

2. The method of claim 1, wherein the identifying a breakpoint in the consensus node upgrade based on the rolling upgrade script and executing a test case for verifying a bayer pattern fault tolerance of a blockchain network based on the breakpoint trigger comprises:

during the running process of the rolling upgrade script, identifying a current breakpoint in the rolling upgrade script according to the change of the service state of the consensus node, and executing the test case at the current breakpoint;

after the common node corresponding to the current breakpoint is upgraded, identifying the next breakpoint in the rolling upgrade script to execute the test case;

and continuing to identify the next breakpoint in the rolling upgrade script until the rolling upgrade of the blockchain network is completed.

3. The method according to claim 1, wherein the topology structure information includes node attribute information of each consensus node and a connection relationship between each consensus node; the step of generating the automatically executed rolling upgrade script according to the topological graph structure information comprises the following steps:

Determining upgrade rounds of the consensus nodes according to the node attribute information of the consensus nodes and the connection relation;

acquiring a target program version, and generating an upgrade strategy according to node attribute information of the consensus node and the target program version;

and generating the rolling upgrade script based on the upgrade rounds of the consensus nodes and the upgrade strategies.

4. A method according to claim 3, wherein the node attribute information of the consensus node comprises a program path of the consensus node; the generating an upgrade policy according to the node attribute information of the consensus node and the target program version includes:

backing up historical program versions of the consensus node according to a program path of the consensus node, and storing the target program version into the program path;

stopping the current running historical program version of the consensus node, and starting the target program version;

and reestablishing connection between the consensus node after updating the target program version and other consensus nodes to obtain the upgrading strategy.

5. A method according to claim 3, wherein the node attribute information of the consensus node comprises configuration information of the consensus node; the step of determining the upgrade round of each consensus node according to the node attribute information of each consensus node and the connection relation comprises the following steps:

Determining the number of consensus nodes to be upgraded in each round according to the total number of the consensus nodes in the blockchain network;

determining the upgrading priority of each consensus node according to the configuration information of each consensus node;

and determining the upgrading turn of each consensus node according to the number of the consensus nodes to be upgraded in each turn and the upgrading priority of each consensus node.

6. The method of claim 5, wherein determining the upgrade priority level of each consensus node based on configuration information of each consensus node comprises:

according to the node numbers of the consensus nodes, sequencing the consensus nodes to obtain an initial sequencing result;

and adjusting the initial sequencing result according to the performance information of each consensus node and the distance information between each consensus node so as to determine the upgrading priority of each consensus node.

7. The method of claim 1, wherein the executing test cases for verifying a bayer process fault tolerance of a blockchain network based on the breakpoint trigger comprises:

obtaining test cases corresponding to the test scenes respectively, and obtaining a plurality of test cases;

in the upgrading process of the current round consensus node, selecting at least one target test case from the plurality of test cases for the current blockchain network according to a target test scene; the current blockchain network is a network formed by other consensus nodes except the current round consensus node;

And automatically executing the target test case based on the breakpoint.

8. The method of claim 7, wherein the obtaining test cases corresponding to the plurality of test scenarios respectively comprises:

generating a test target aiming at the Bayesian fault tolerance according to the test property and the fault tolerance degree of the Bayesian fault tolerance;

determining a plurality of test scenes to be covered according to the test targets, wherein each test scene is used for representing a Bayesian attack;

and determining data required by the test according to the plurality of test scenes to generate test cases corresponding to the plurality of test scenes respectively.

9. The method of claim 1, wherein after the executing the test case for verifying the bayer pattern fault tolerance of the blockchain network based on the breakpoint trigger, the method further comprises:

acquiring a service test state corresponding to the current blockchain network according to the test case;

acquiring a service expected state corresponding to the test case;

and generating a Bayesian fault-tolerant subtest report of the current blockchain network according to the service test state and the service expected state.

10. The method of claim 1, wherein the generating a test report for bayer fault tolerance based on the test case comprises:

Obtaining subtest reports corresponding to test cases triggered by each round of upgrading to obtain a plurality of subtest reports, wherein the number of the consensus nodes to be upgraded in each round is sequentially increased;

traversing the plurality of sub-test reports sequentially from the sub-test report corresponding to the last round of upgrading as a base point;

if the sub-test report of the last traversal does not reach the expectation, determining the maximum fault tolerance characteristic of the Bayesian fault tolerance according to the sub-test report of the current traversal so as to generate the test report of the Bayesian fault tolerance.

11. The method of claim 1, wherein the generating a test report for bayer fault tolerance based on the test case comprises:

after the rolling upgrading of the block chain network is finished, detecting the consensus service of the block chain network to obtain the running state of the consensus service;

and generating a test report of the Bayesian fault tolerance according to the test case and the running state of the consensus service.

12. The method according to any one of claims 1 to 11, wherein after the generating of the test report for bayer fault tolerance based on the test case, the method further comprises:

Determining a target node in which abnormality occurs repeatedly in the consensus node based on the Bayesian fault-tolerant test report;

if the number of the target nodes is greater than the number of the preset nodes, rollback processing is carried out on the program version of the consensus node of the blockchain network;

and if the number of the target nodes is smaller than the preset number of nodes, removing the target nodes from the blockchain network.

13. A blockchain-based fault-tolerant verification device, comprising:

the acquisition module is used for acquiring topological graph structure information of the blockchain network;

the generation module is used for generating an automatically executed rolling upgrade script according to the topological graph structure information, and the rolling upgrade script is used for upgrading the block chain program version of the consensus node round by round;

the execution module is used for identifying a breakpoint in the upgrading of the consensus node based on the rolling upgrading script, and executing a test case for verifying the Bayesian fault tolerance of the blockchain network based on the breakpoint trigger, wherein the breakpoint is used for describing the transition position of the consensus node from a historical program version to a target program version;

and the generation module is also used for generating a Bayesian fault-tolerant test report based on the test case if the rolling upgrading of the blockchain network is detected to be completed, wherein the test report comprises detailed information about the fault-tolerant performance of the Bayesian fault-tolerant in the rolling upgrading process of the blockchain network.

14. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs that, when executed by the one or more processors, cause the electronic device to perform the method of any of claims 1-12.

15. A computer readable storage medium, having stored thereon a computer program which, when executed by a processor of an electronic device, causes the electronic device to perform the method of any of claims 1 to 12.