TW202145116A - Consensus method, device and equipment of blockchain system and medium - Google Patents

Abstract

The invention discloses a consensus method, device and equipment of a blockchain system, and a medium. The consensus method of the blockchain system comprises the following steps: receiving a consensus cluster routing request sent by a target peer node; analyzing the consensus cluster routing request to obtain routing request information, wherein the routing request information comprises a node position of the target peer node; determining the target consensus cluster in the at least one available consensus cluster according to the node position, wherein the available consensus cluster is a consensus cluster in a normal working state in the blockchain system; and sending the target cluster address of the target consensus cluster to the target peer node. According to the embodiment of the invention, the problem that a conventional consensus mechanism is not enough to meet the requirement of the blockchain system on high throughput can be solved.

Description

Consensus method, device, equipment and medium for blockchain system

The invention belongs to the technical field of blockchain, and in particular relates to a consensus method, device, equipment and medium of a blockchain system.

The consensus mechanism is a mechanism for each node in the blockchain system to reach a consensus of the entire network on block information, which can ensure that the latest block is accurately added to the blockchain and the blockchain information stored by each node is consistent and does not fork. It can even defend against malicious attacks.

With the continuous increase of the number of nodes in the blockchain system, the existing consensus mechanism is no longer sufficient to meet the demand for high throughput of the blockchain system.

The embodiments of the present invention provide a consensus method, device, equipment and medium for a blockchain system, which can solve the problem that the existing consensus mechanism is insufficient to meet the demand for high throughput of the blockchain system.

In a first aspect, an embodiment of the present invention provides a consensus method for a blockchain system, including:

Receive the consensus cluster routing request sent by the target peer node;

Parse the consensus cluster routing request to obtain routing request information; wherein, the routing request information includes the node location of the target peer node;

According to the node location, in at least one available consensus cluster, determine the target consensus cluster; wherein, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

Send the target cluster address of the target consensus cluster to the target peer.

In a second aspect, an embodiment of the present invention provides a consensus method for a blockchain system, including:

Receive the transaction request sent by the target peer node; wherein, the target peer node sends the transaction request based on the target cluster address, and the target cluster address is determined in at least one available consensus cluster according to the node position of the target peer node, and the available consensus cluster is A consensus cluster in a normal working state in the blockchain system;

Parse the transaction request to obtain transaction request information; wherein, the transaction request information includes transaction information;

Initiate consensus on transaction information;

In the case of a successful consensus, the transaction corresponding to the transaction information is executed.

In terms of third-party manufacturers, the embodiments of the present invention provide a consensus method for a blockchain system, including:

Receive the address query request sent by the target consensus cluster; wherein, the address query request is generated according to the target channel information carried in the transaction request received by the target consensus cluster;

Parse the address query request to obtain address query request information; wherein, the address query request information includes target channel information;

In the distributed database, query the cluster address corresponding to the target channel information;

When the address query request information further includes the node address, the cluster address corresponding to the target channel information is sent to the peer node corresponding to the node address.

In a fourth aspect, an embodiment of the present invention provides a consensus method for a blockchain system, including:

Send a consensus cluster routing request to the cluster scheduling node, so that the cluster scheduling node responds to the consensus cluster routing request, and determines the target consensus cluster in at least one available consensus cluster according to the node location included in the routing request information of the consensus cluster routing request, and gives back The target cluster address corresponding to the target consensus cluster; among them, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

Receive the target cluster address returned by the cluster scheduling node;

Based on the target cluster address, send a transaction request to the target consensus cluster.

In a fifth aspect, an embodiment of the present invention provides a consensus device for a blockchain system, including:

The first receiving module is used to receive the consensus cluster routing request sent by the target peer node;

The first parsing module is used for parsing the consensus cluster routing request to obtain routing request information; wherein, the routing request information includes the node location of the target peer node;

The first determination module is used to determine a target consensus cluster in at least one available consensus cluster according to the node position; wherein, the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

The first sending module is used for sending the target cluster address of the target consensus cluster to the target peer node.

In a sixth aspect, an embodiment of the present invention provides a consensus device for a blockchain system, including:

The second receiving module is used to receive the transaction request sent by the target peer node; wherein, the target peer node sends the transaction request based on the target cluster address, and the target cluster address is based on the node position of the target peer node in at least one available consensus Determined in the cluster, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

The second parsing module is used for parsing the transaction request to obtain transaction request information; wherein, the transaction request information includes transaction information;

Information consensus module, used to initiate consensus on transaction information;

The transaction execution module is used to execute the transaction corresponding to the transaction information when the consensus is successful.

In a seventh aspect, an embodiment of the present invention provides a consensus device for a blockchain system, including:

The third receiving module is used to receive the address query sent by the target consensus cluster request; wherein, the address query request is generated according to the target channel information carried in the transaction request received by the target consensus cluster;

The third parsing module is used for parsing the address query request to obtain address query request information; wherein, the address query request information includes target channel information;

The address query module is used to query the cluster address corresponding to the target channel information in the distributed database;

The second sending module is configured to send the cluster address corresponding to the target channel information to the peer node corresponding to the node address when the address query request information further includes the node address.

In an eighth aspect, an embodiment of the present invention provides a consensus device for a blockchain system, including:

The third sending module is used to send a consensus cluster routing request to the cluster scheduling node, so that the cluster scheduling node responds to the consensus cluster routing request, according to the node position included in the routing request information of the consensus cluster routing request, in at least one available consensus cluster Determine the target consensus cluster and return the target cluster address corresponding to the target consensus cluster; among them, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

The fourth receiving module is used for receiving the target cluster address fed back by the cluster scheduling node;

The fourth sending module is used to send a transaction request to the target consensus cluster based on the target cluster address.

In a ninth aspect, an embodiment of the present invention provides a consensus device for a blockchain system, the device comprising: a processor and a memory storing computer program instructions;

When the processor executes the computer program instructions, the consensus method of the blockchain system as described in the first aspect, the second aspect, the third party aspect or the fourth aspect is implemented.

In a tenth aspect, an embodiment of the present invention provides a computer-readable storage medium, where computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, the first aspect, the second aspect, the third-party manufacturer blockchain as described in aspect or fourth aspect The consensus method of the system.

The consensus method, device, device, and medium of the blockchain system according to the embodiments of the present invention can be based on the node position of the target peer node carried in the consensus cluster routing request sent by the target peer node, which is at least one in the blockchain system. In an available consensus cluster that is in normal working state, assign the target consensus cluster to the target peer node, and send the target cluster address of the target consensus cluster to the target corresponding node, so as to realize the shunting of the peer nodes by the node location, so that different Peer nodes can match different consensus clusters based on their node positions, so that multiple consensus clusters can be used to perform consensus on a large number of peer nodes in parallel, which improves the transmission capacity of the blockchain system and can meet the high demand of the blockchain system. delivery volume requirements.

OC, OC-1, OC-2, OC-3: Consensus Cluster

PC1, PC2: peer-to-peer cluster

CC: User Cluster

201,301: Certificate Authority (CA) layer

202: Consensus Layer

203,305: Peer Layer

302: Channel coordination layer

303: Consensus cluster layer

304: Cluster scheduling layer

A, C: Region

B: Manufacturing company

D: Distributors

O1: Consensus cluster

E: channel

910: The first receiving module

920: The first analysis module

930: The first confirmed module

940: The first sending module

1010: Second receiving module

1020: Second Analysis Module

1030: Information Consensus Module

1040: Transaction Execution Module

1110: The third receiving module

1120: The third parsing module

1130: Address query module

1140: The second sending module

1210: The third sending module

1220: Fourth receiving module

1230: Fourth sending module

1300: Consensus Device

1301: Input Device

1302: Input interface

1303: CPU

1304: Memory

1305: Output interface

1306: Output device

1310: Busbar

BC-1, BC-2, BC-3, BC-4, BC-5, BC-6: Blockchain Ledger

S510, S520, S530, S540, S610, S620, S630, S640, S710, S720, S730, S740, S810, S820, S830: Process

In order to illustrate the technical solutions of the embodiments of the present invention more clearly, the following briefly introduces the accompanying drawings that need to be used in the embodiments of the present invention. For those of ordinary skill in the art, without creative work, the Additional drawings can be obtained from these drawings.

1 is a schematic structural diagram of a blockchain system in the prior art;

Fig. 2 is a system architecture diagram of the blockchain system in Fig. 1;

3 is a system architecture diagram of a blockchain system provided by an embodiment of the present invention;

FIG. 4 is a schematic structural diagram of a blockchain system under the system architecture shown in FIG. 3;

5 is a schematic flowchart of a consensus method of a blockchain system provided by an embodiment of the present invention;

6 is a schematic flowchart of a consensus method of a blockchain system provided by another embodiment of the present invention;

7 is a schematic flowchart of a consensus method for a blockchain system provided by another embodiment of the present invention;

8 is a schematic flowchart of a consensus method of a blockchain system provided by another embodiment of the present invention;

FIG. 9 is a schematic structural diagram of a consensus device of a blockchain system provided by an embodiment of the present invention picture;

10 is a schematic structural diagram of a consensus device of a blockchain system provided by another embodiment of the present invention;

11 is a schematic structural diagram of a consensus device of a blockchain system provided by another embodiment of the present invention;

12 is a schematic structural diagram of a consensus device of a blockchain system provided by another embodiment of the present invention;

FIG. 13 is a schematic structural diagram of a consensus device of a blockchain system provided by an embodiment of the present invention.

The features and exemplary embodiments of various aspects of the present invention will be described in detail below. In order to make the objectives, technical solutions and advantages of the present invention more clear, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only configured to explain the present invention, and are not configured to limit the present invention. It will be apparent to those skilled in the art that the present invention may be practiced without some of these specific details. The following description of the embodiments is only intended to provide a better understanding of the present invention by illustrating examples of the invention.

It should be noted that, in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any relationship between these entities or operations. any such actual relationship or sequence exists. Moreover, the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device that includes a list of elements includes not only those elements, but also includes not explicitly listed or other elements inherent to such a process, method, article or apparatus. Without further limitation, an element defined by the phrase "comprising..." does not preclude the presence of additional identical elements in a process, method, article, or device that includes the element.

The consensus mechanism is that each node in the blockchain system reaches a consensus on the block information. The consensus mechanism of the network can ensure that the latest block is accurately added to the blockchain and the blockchain information stored by each node is consistent and non-forked, and it can even resist malicious attacks.

FIG. 1 shows a schematic structural diagram of a blockchain system in the prior art.

As shown in Figure 1, the blockchain system includes a consensus cluster OC, a peer-to-peer cluster PC1, a peer-to-peer cluster PC2, and a user cluster CC. The consensus cluster OC includes at least one consensus node. The peer-to-peer cluster PC1 and the peer-to-peer cluster PC2 respectively include at least one peer node, and the peer nodes can be divided into different peer clusters according to node positions. The blockchain ledger BC-1, BC-2, BC-3, BC-4, BC-5, and BC-6 are the different channels (such as sub-blockchains) formed by the consensus cluster OC and different peer nodes, respectively. The corresponding blockchain ledger. The user cluster CC includes at least one user node.

FIG. 2 shows a system architecture diagram of the blockchain system in FIG. 1 .

As shown in FIG. 2 , the blockchain system is a Hyperledger Fabric architecture, and the Hyperledger Fabric architecture includes a Certificate Authority (CA) layer 201 , a consensus layer 202 and a peer layer 203 . Among them, the CA layer 201 includes a CA management node, which is responsible for certificate distribution, revocation and other permission control operations related to blockchain transactions for all level nodes. The consensus layer 202 includes the consensus cluster OC shown in FIG. 1 , and the peer layer 203 includes the peer cluster PC1 and the peer cluster PC2 shown in FIG. 1 .

In the blockchain systems shown in Figures 1 and 2, each user node can communicate with peer nodes in the corresponding peer-to-peer cluster, send service requests to peer nodes or receive request results returned by peer nodes . Each peer node can also communicate with the consensus cluster OC, send transaction requests to the consensus cluster OC based on the received service request, or receive the request results returned by the consensus cluster OC.

However, with the continuous increase in the number of nodes in the blockchain system, especially the number of peer nodes, the existing consensus mechanism is no longer sufficient to meet the blockchain system's demand for high throughput.

The existing methods for increasing the throughput of the blockchain system are generally not changing In the case of the system architecture of the blockchain system, the consensus algorithm of the consensus cluster is improved to increase the throughput of the blockchain system.

However, the applicant found that with the increase in the number of connected user nodes, the transaction volume that can be processed per second on the user side will drop rapidly, and only relying on the improvement of the consensus algorithm to meet the high transmission volume demand of the blockchain system The difficulty of the blockchain system is relatively high, resulting in a still low transmission volume of the blockchain system.

In order to solve the above problems, an embodiment of the present invention provides a new system architecture applied to a blockchain system and a blockchain system corresponding to the system architecture.

FIG. 3 shows a system architecture diagram of a blockchain system provided by an embodiment of the present invention.

As shown in FIG. 3 , the system architecture diagram includes a CA layer 301 , a channel coordination layer 302 , a consensus cluster layer 303 , a cluster scheduling layer 304 and a peer layer 305 . Among them, the CA layer 301 includes a CA management node, which is responsible for certificate distribution, revocation and other permission control operations related to blockchain transactions for all level nodes. The consensus cluster layer 303 may include one or more consensus clusters, which are used to perform consensus based on transaction requests and realize a unified ordering of blockchain transactions. The channel coordination layer 302 includes channel coordination nodes, which are used for channel coordination routing for transaction requests across consensus clusters, so as to improve the system's cross-regional service capability. The peer layer 305 includes at least one peer cluster for initiating transaction requests to the consensus cluster layer. The cluster scheduling layer 304 includes a cluster scheduling node for allocating consensus clusters to each peer node in the peer-to-peer cluster to achieve dynamic allocation of consensus clusters.

In some embodiments of the present invention, the system architecture may be a Hyperledger Fabric architecture. In other embodiments of the present invention, the system architecture may also be other architectures similar to the Hyperledger Fabric architecture.

FIG. 4 shows a schematic structural diagram of a blockchain system under the system architecture shown in FIG. 3 .

As shown in Figure 4, the blockchain system includes a channel coordination layer, a consensus cluster OC-1, a consensus cluster OC-2, a consensus cluster OC-3, a peer-to-peer cluster PC1, a cluster scheduling layer, and a peer-to-peer cluster. etc. Cluster PC2 and User Cluster CC. The channel coordination layer includes channel coordination nodes located in each consensus cluster. The consensus cluster OC-1, the consensus cluster OC-2 and the consensus cluster OC-3 respectively include at least one consensus node, and different consensus clusters correspond to different location areas. The peer-to-peer cluster PC1 and the peer-to-peer cluster PC2 respectively include at least one peer node, and the peer nodes can be divided into different peer clusters according to node positions. The cluster scheduling layer includes at least one cluster scheduling node. The blockchain ledgers BC-1, BC-2, BC-3, and BC-4 are the blockchain ledgers corresponding to different channels (such as sub-blockchains) established by different consensus clusters for different peer nodes. The user cluster CC includes at least one user node.

In the blockchain systems shown in Figures 3 and 4, each user node can communicate with peer nodes in the corresponding peer-to-peer cluster, send service requests to peer nodes or receive request results returned by peer nodes . Each peer node can also communicate with the cluster scheduling node, and send a consensus cluster routing request to the cluster scheduling node based on the received service request, so that the cluster scheduling node is based on the node location of the peer node carried by the consensus cluster routing request. Peer nodes assign consensus clusters. Each peer node can also communicate with the consensus cluster assigned by the cluster scheduling node, send transaction requests to the consensus cluster based on the received service request or receive the request result returned by the consensus cluster. When the consensus cluster receives a transaction request across consensus clusters, it can also perform channel coordination routing for the transaction request through the channel coordination node, and find the consensus cluster to which the channel corresponding to the transaction request belongs, so that the pair that sends the transaction request belongs to the consensus cluster. The other node can re-send the transaction request to the consensus cluster to which the channel corresponding to the transaction request belongs.

Therefore, the blockchain system provided by the embodiment of the present invention can realize the distribution of peer nodes according to the node position, so that different peer nodes can match different consensus clusters based on their node positions, so that multiple consensus clusters can be used in parallel Consensus on a large number of peer nodes improves the transmission volume of the blockchain system, which in turn can meet the demand for high transmission volume of the blockchain system, and can adapt to the needs of efficient and secure business.

It should be noted that, in the blockchain system shown in Figure 4, the channel coordination nodes are respectively embedded in the corresponding consensus clusters. In other embodiments, the channel coordination node may also be set separately from the corresponding consensus cluster, which is not limited here.

Based on the blockchain system provided by the embodiments of the present invention, the embodiments of the present invention provide a consensus method, apparatus, device, and medium for a blockchain system. The following first introduces the consensus method of the blockchain system provided by the embodiment of the present invention.

FIG. 5 shows a schematic flowchart of a consensus method of a blockchain system provided by an embodiment of the present invention.

In some embodiments of the present invention, the method shown in FIG. 5 may be executed by the cluster scheduling node shown in FIG. 4 . The cluster scheduling node may be a server or a server cluster.

As shown in Figure 5, the consensus method of the blockchain system can include:

S510. Receive a consensus cluster routing request sent by the target peer node.

In some embodiments of the present invention, the target peer node may be any peer node in the blockchain system. For example, the target peer node can be any peer node in the blockchain system shown in FIG. 4 .

In some embodiments of the present invention, the routing request type of the consensus cluster routing request received by the cluster scheduling node may include a first routing type and a second routing type. The first routing type can be used to represent that the routing request is a consensus cluster routing request sent by the peer node when the channel is first established, and the second routing type can be used to represent that the routing request is the peer node joining the existing channel. Consensus cluster routing request sent when .

In some embodiments of the present invention, a channel may be a sub-blockchain.

S520. Parse the consensus cluster routing request to obtain routing request information, wherein the routing request information includes the node location of the target peer node.

In some embodiments of the present invention, the cluster scheduling node may perform request analysis processing on the received consensus cluster routing request to obtain routing request information contained in the consensus cluster routing request.

In some embodiments, the routing request information may include the node location of the target peer node, wherein the node location includes the geographic location of the target peer node. in other real In an embodiment, the routing request information may further include a routing request type. In still other embodiments, the routing request information may also include node verification information, wherein the node verification information includes information for verifying the validity of the certificate of the target peer node. In still other embodiments, the routing request information may further include a node address of the target peer node, wherein the node address includes a node Internet Protocol (IP) address of the target peer node.

It should be noted that the routing request information may also include other information for assisting the cluster scheduling node to allocate the target consensus cluster to the target peer node, which is not limited here.

S530: Determine a target consensus cluster in at least one available consensus cluster according to the position of the node; wherein, the available consensus cluster is a consensus cluster in a normal working state in the blockchain system.

In some embodiments of the present invention, the cluster scheduling node may allocate the target consensus cluster to the target peer node based on the shortest time principle and according to the node location and the cluster location of each available consensus cluster.

Specifically, the cluster scheduling node can continuously monitor the heartbeat of each consensus cluster in the consensus cluster layer, and calculate the response time of each consensus cluster. After receiving the consensus cluster routing request, it can be based on the target peer carried in the consensus cluster routing request. The node position of the node, select the consensus cluster located within the preset distance range corresponding to the node position from multiple consensus clusters, and select the consensus cluster with the shortest response time among the selected consensus clusters as the target consensus cluster. The shortest time principle assigns target consensus clusters to target peers.

The preset distance range can be set as required, and is not limited here.

Therefore, in the embodiment of the present invention, the cluster scheduling node can allocate the target consensus cluster with the shortest response time to the target peer node, thereby improving the efficiency of transaction processing and improving the user experience.

In other embodiments of the present invention, the cluster scheduling node may also be based on the shortest distance principle, according to the node location and the cluster location of each available consensus cluster, as the target peer Nodes assign target consensus clusters.

The cluster location may include the geographic location of the consensus cluster.

Specifically, after receiving the consensus cluster routing request, the cluster scheduling node may select a consensus among multiple consensus clusters with the closest distance between the cluster location and the node location based on the node location of the target peer node carried in the consensus cluster routing request The cluster, as the target consensus cluster, assigns the target consensus cluster to the target peer nodes based on the shortest distance principle.

Therefore, in the embodiment of the present invention, the cluster scheduling node can allocate the target consensus cluster with the closest distance to the target peer node, thereby improving the efficiency of transaction processing and improving the user experience.

In some embodiments of the present invention, each consensus cluster may include at least one consensus node, and the consensus node may be a server or a server cluster.

In some embodiments of the present invention, the normal working state is a working state of normal operation.

S540. Send the target cluster address of the target consensus cluster to the target peer node.

In some embodiments of the present invention, after determining the target consensus cluster, the cluster scheduling node may query the target cluster address of the target consensus cluster, and send the target cluster address of the target consensus cluster to the target peer node.

In some embodiments of the present invention, the routing request information may include the node address of the target peer node, and the cluster scheduling node may send the target cluster address of the target consensus cluster to the target peer node through the node address.

In the embodiment of the present invention, the node location of the target peer node carried in the consensus cluster routing request sent by the target peer node is in at least one available consensus cluster in the normal working state of the blockchain system, and is The target peer node assigns the target consensus cluster, and sends the target cluster address of the target consensus cluster to the target corresponding node, so as to realize the shunting of the peer nodes through the node location, so that different peer nodes can match different consensus based on their node location. cluster, so that multiple consensus clusters can be used in parallel on a large number of peer nodes Consensus increases the transmission volume of the blockchain system, which in turn can meet the demand for high transmission volume of the blockchain system.

The specific implementation of the S530 will be described in detail below.

In some embodiments of the present invention, in order to improve the security of the blockchain system, the routing request information may also include node verification information;

Before the cluster scheduling node executes S530, the node verification information may also be verified.

Correspondingly, the specific method of S530 may include:

In the case that the node verification information is verified, according to the node location, in at least one available consensus cluster, determine the target consensus cluster.

In some embodiments, the node authentication information may be generated by the target peer node based on a certificate issued to it by the credential authority node. For example, the credential authorization node may be a node in the CA layer 301 shown in FIG. 3 . The node verification information can be used to verify the validity of the certificate of the target peer node, so that the cluster scheduling node can determine whether the target peer node is a legal node of the blockchain system.

In these embodiments, if the node verification information passes the verification, it means that the target peer node is a legitimate node of the blockchain system, and the cluster scheduling node can determine the target consensus cluster in at least one available consensus cluster according to the node location; if If the node verification information fails to pass the verification, it means that the target peer node is not a legal node of the blockchain system, and the cluster scheduling node stops responding to the consensus cluster routing request and does not allocate any consensus cluster to the target peer node.

Therefore, in the embodiment of the present invention, the cluster scheduling node can first verify the legitimacy of the node verification information of the target peer node, and in the case that the node verification information passes the verification, assign the target consensus cluster to the target peer node, and then Improve the security of the blockchain system.

In some embodiments of the present invention, in order to improve the reliability of the blockchain system, before S530, the consensus method of the blockchain system may further include:

Receive the cluster registration request sent by the consensus cluster;

Parse the cluster registration request to obtain cluster registration request information; wherein, the cluster registration request information includes cluster verification information;

If the cluster verification information is verified, monitor the consensus cluster;

In the case of monitoring that the consensus cluster is in a normal working state, the consensus cluster is used as the available consensus cluster.

Specifically, when each consensus cluster is first started, it will send a cluster registration request to the cluster scheduling node to register in the cluster registration request. After receiving the cluster registration request sent by the consensus cluster, the cluster scheduling node can parse the cluster registration request, obtain the cluster verification information, and then verify the legitimacy of the consensus cluster based on the cluster verification information. The consensus cluster is successfully registered, and the cluster scheduling node can continue to monitor the consensus cluster. If it is monitored that the consensus cluster is in a normal working state, the consensus cluster is regarded as an available consensus cluster and added to the dynamic network map of the consensus cluster; if it is monitored that the consensus cluster is not in a normal working state, the consensus cluster is regarded as an unavailable consensus cluster. And remove the consensus cluster from the consensus cluster dynamic network map.

The cluster verification information includes information for verifying the validity of the certificate of the consensus cluster. The cluster verification information can be generated by the consensus cluster according to the certificate issued by the certificate authority node. For example, the credential authorization node may be a node in the CA layer 301 shown in FIG. 3 . The cluster verification information can be used to verify the validity of the certificate of the consensus cluster, so that the cluster scheduling node can determine whether the consensus cluster is a legitimate cluster of the blockchain system.

In some embodiments of the present invention, after the consensus cluster is successfully registered, it may send the heartbeat of the consensus cluster to the cluster scheduling node, and the cluster scheduling node may monitor the consensus cluster based on the heartbeat of the consensus cluster to determine whether the consensus cluster is working normally state.

In these embodiments, optionally, the specific method of S530 may include:

According to the node location, among at least one available consensus cluster in the dynamic network map of consensus clusters, the target consensus cluster is determined.

Since the available consensus clusters in the dynamic network map of consensus clusters change dynamically based on the working status of each consensus cluster, the cluster scheduling node can be the target peer Nodes dynamically allocate target consensus clusters that are in normal working state to improve the reliability of the blockchain system.

In other embodiments of the present invention, the cluster registration request information may further include cluster configuration information. The cluster configuration information may include a cluster identification (Identity document, ID) of the consensus cluster, the cluster IP address, and the cluster location equal to the information related to the configuration of the consensus cluster.

In these embodiments, optionally, before S540, the consensus method of the blockchain system may further include:

Query the target cluster configuration information corresponding to the target consensus cluster;

In the target cluster configuration information, extract the target cluster address.

Specifically, the cluster scheduling node can query the target cluster configuration information corresponding to the target consensus cluster based on the target cluster ID of the target consensus cluster in the cluster configuration information of each registered consensus cluster, and extract the target cluster configuration information from the target cluster configuration information. The cluster address to send the target peer node's assigned target consensus cluster's target cluster address.

In some embodiments of the present invention, in order to improve the transaction processing efficiency of the blockchain system, before using the available consensus cluster with the shortest response time as the target consensus cluster, the consensus method of the blockchain system may further include:

Determine whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition.

Among them, the cluster performance parameters can include parameters such as the transmission volume of the consensus cluster and the average transaction delay. The average transaction delay can be obtained from the peer node that communicates with the consensus cluster. After the peer node sends a transaction request to the consensus cluster, it can send the average transaction delay of the consensus cluster communication to the cluster scheduling node at regular intervals.

In these embodiments, optionally, the specific method for using the available consensus cluster with the shortest response time as the target consensus cluster may include:

In the case that the cluster performance parameter does not meet the first preset condition, the available consensus cluster with the shortest response time is used as the target consensus set.

Specifically, after determining the available consensus cluster with the shortest response time to the target peer node, the cluster scheduling node can determine whether the cluster performance parameter of the available consensus cluster satisfies the first preset condition, and determine whether the available consensus cluster has reached the saturated state. If it is determined that the cluster performance parameter does not meet the first preset condition, that is, the available consensus cluster has not reached the saturation state, the available consensus cluster with the shortest response time may be used as the target consensus cluster.

In other embodiments, after judging whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition, the consensus method of the blockchain system may further include:

When the cluster performance parameter satisfies the first preset condition, the available consensus cluster with the second shortest response time is used as the target consensus cluster.

Specifically, after judging whether the cluster performance parameter of the available consensus cluster satisfies the first preset condition, the cluster scheduling node can also determine that the cluster performance parameter satisfies the first preset condition, that is, the available consensus cluster has reached the saturation state, then Use the available consensus cluster with the second shortest response time as the target consensus cluster.

Therefore, in the embodiment of the present invention, a comprehensive judgment can be further made based on the saturation of the available consensus clusters and the response time, so as to dynamically allocate the target consensus cluster in a normal working state for the target peer node, and further improve the blockchain system's performance. reliability.

In some embodiments of the present invention, it is also possible to judge the saturation situation of the available consensus cluster with the second shortest response time, and determine whether to use the available consensus cluster with the second shortest response time as the target consensus cluster.

It should be noted that the method of judging the saturation situation of the available consensus cluster with the shortest response time is similar to the method of judging the saturation situation of the available consensus cluster with the shortest response time. The method of serving as the target consensus cluster is similar to the method of determining whether to use the available consensus cluster with the shortest response time as the target consensus cluster, and will not be repeated here.

In some embodiments of the present invention, in order to further improve the transaction processing efficiency of the blockchain system, the routing request information may further include a routing request type;

In these embodiments, the specific method for judging whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition may further include:

When the route request type is the first route type, it is determined whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition.

Specifically, before determining whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition, the routing request type of the routing request of the consensus cluster may also be determined. If the routing request type is the first routing type, that is, the routing request type is the consensus cluster routing request sent by the peer node when the channel is first established, then determine whether the cluster performance parameters of the available consensus cluster with the shortest response time satisfy the first preset condition, and no longer consider a consensus cluster that is already saturated. If the routing request type is the second routing type, that is, the routing request type is the consensus cluster routing request sent by the peer node when joining the existing channel, it is not necessary to judge whether the cluster performance parameters of the available consensus cluster with the shortest response time meet the first requirement. Pre-set conditions, consensus clusters that are already saturated can still be considered.

In some embodiments of the present invention, the first preset condition may include at least one of the following:

The delivery volume in the cluster performance parameter is greater than or equal to the preset delivery volume threshold;

The first duration of the delivery volume greater than or equal to the preset delivery volume threshold is greater than or equal to the first preset duration;

The average transaction delay in the cluster performance parameters is greater than or equal to the preset delay threshold;

The second time period when the average transaction delay is greater than or equal to the preset delay threshold is greater than or equal to the second preset time period.

Specifically, the preset delivery volume threshold may correspond to the critical level of the reference technical index, for example, the preset delivery volume threshold may be 90%, or may be other thresholds set as required. The average transaction delay can also correspond to the critical level of the benchmark technical indicators. For example, the preset delay threshold can be 10%, or it can be other thresholds set according to needs. The first preset duration and the second preset duration may respectively be durations set as required, which are not limited herein.

In some embodiments, the average transaction delay is greater than or equal to a preset delay threshold The value can be that the average transaction delay of all consensus nodes in the consensus cluster is greater than or equal to the preset delay threshold. In other embodiments, the average transaction delay greater than or equal to the preset delay threshold may be that the average transaction delay of a predetermined number of consensus nodes in the consensus cluster is greater than or equal to the preset delay threshold.

Among them, the predetermined number can be 10% of the total number of consensus nodes in the consensus cluster, or can be other numbers set as required.

In some embodiments of the present invention, the cluster scheduling node may directly determine whether the cluster performance parameter of the available consensus cluster satisfies the first preset condition based on the cluster performance parameter.

In other embodiments, in order to reduce the data processing amount of the cluster scheduling node, the specific method for judging whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition further includes:

Detect whether the available consensus cluster with the shortest response time has a saturation status flag;

In the case of detecting the saturation state flag, determine that the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition;

In the case that it is detected that there is no saturation state flag, it is determined that the cluster performance parameter of the available consensus cluster with the shortest response time does not satisfy the first preset condition.

Specifically, the cluster scheduling node may determine whether the cluster performance parameter of each available consensus cluster meets the first preset condition at regular intervals, and add a saturation status flag to the available consensus cluster whose cluster performance parameter meets the first preset condition.

After the cluster scheduling node obtains the available consensus cluster with the shortest response time, it can judge whether the cluster performance parameter of the available consensus cluster with the shortest response time meets the first preset condition through the saturation status flag, thereby reducing the data processing of the cluster scheduling node to improve data processing efficiency.

In some embodiments of the present invention, one consensus cluster may correspond to one location area (ie, geographic area), one location area may correspond to at least one consensus cluster, and the cluster scheduling nodes may be based on different location areas due to different degrees of economic development. close Connect the differences in the activity level of the blockchain business, realize the load balancing mechanism, and reasonably allocate the consensus cluster for each peer node, so as to realize the regional division of the peer node, so as to solve the performance limitation of the consensus algorithm of a single consensus cluster. A situation that saturates the transaction consensus processing capacity of the location area.

FIG. 6 shows a schematic flowchart of a consensus method for a blockchain system provided by another embodiment of the present invention.

In some embodiments of the present invention, the method shown in FIG. 6 may be performed by any one of the consensus clusters shown in FIG. 4 . The consensus cluster may include at least one consensus node, and the consensus node may be a server or a server cluster.

As shown in Figure 6, the consensus method of the blockchain system can include:

S610. Receive a transaction request sent by the target peer node; wherein, the target peer node sends the transaction request based on the target cluster address, and the target cluster address is determined in at least one available consensus cluster according to the node location of the target peer node, and the available consensus The cluster is a consensus cluster in a normal working state in the blockchain system;

In some embodiments of the present invention, the target peer node may be any peer node in the blockchain system. For example, the target peer node can be any peer node in the blockchain system shown in FIG. 4 .

In some embodiments of the present invention, the transaction request types of the transaction requests received by the consensus cluster may include a first transaction type, a second transaction type, and a third transaction type. The first transaction type can be used to represent that the transaction request is a channel establishment transaction request, the second transaction type can be used to represent that the transaction request is a transaction request to join an existing channel, and the third transaction type can be used to represent that the transaction request is an initiation A transaction request for a transaction in an existing channel.

S620, parse the transaction request, and obtain transaction request information; wherein, the transaction request information includes transaction information;

In some embodiments of the present invention, the consensus cluster may perform request analysis processing on the received transaction request to obtain transaction request information included in the transaction request.

In some embodiments, the transaction request information may include transaction information, which , transaction information is the information used to initiate consensus. In other embodiments, the transaction request information may include the transaction request type. In still other embodiments, the transaction request information may also include target channel information. In still other embodiments, the transaction request information may further include the node address of the target peer node, wherein the node address includes the node IP address of the target peer node. In still other embodiments, the transaction request information may further include node verification information, wherein the node verification information includes information for verifying the validity of the certificate of the target peer node.

It should be noted that the transaction request information may also include other information used to assist the consensus cluster to conduct transaction consensus for the target peer node, which is not limited here.

S630. Initiate a consensus on transaction information;

In some embodiments of the present invention, the consensus cluster may initiate consensus on transaction information based on a single zookeeper consensus algorithm. In other embodiments of the present invention, the consensus cluster can also initiate consensus on transaction information based on a supported raft consensus algorithm. In other embodiments of the present invention, the consensus cluster may also initiate consensus on transaction information based on other consensus algorithms, which is not limited herein.

S640. In the case that the consensus is successful, execute the transaction corresponding to the transaction information.

In the embodiment of the present invention, the consensus cluster can receive transaction requests sent by target peer nodes based on node location allocation, so as to realize the distribution of peer nodes based on node locations, so that different peer nodes can match different peer nodes based on their node locations. Consensus clustering, so that multiple consensus clusters can be used to achieve consensus on a large number of peer nodes in parallel, which improves the transmission capacity of the blockchain system, and thus can meet the demand for high transmission capacity of the blockchain system when a large number of nodes are connected. At the same time, even if the number of participating nodes increases, the scalability of the blockchain system can continue to be maintained.

The specific implementation of the S630 will be described in detail below.

In some embodiments of the present invention, in order to improve the data processing efficiency of the consensus cluster, the transaction request information may further include a transaction request type.

In these embodiments, optionally, a specific method for initiating consensus on transaction information may include:

When the transaction request type is the first transaction type, a consensus is initiated for transaction information.

Specifically, before initiating a consensus on the transaction information, the transaction request type of the transaction request can be determined first. If the transaction request type is the first transaction type, that is, the transaction request can be a transaction request representing the establishment of a channel, it can be directly initiated on the transaction information. consensus, thereby improving the data processing efficiency of the consensus cluster.

In other embodiments of the present invention, in order to improve the reliability of the consensus cluster, the transaction request information may further include target channel information.

In these embodiments, optionally, after parsing the transaction request to obtain the transaction request information, the consensus method of the blockchain system may further include:

If the transaction request type is not the first transaction type, obtain the target channel information;

Query the target channel information in the target channel list; wherein, the target channel list is the channel list in the local storage area, the target channel list can include multiple first channel information, and each first channel information can be based on a locally established channel. Attribute information is generated.

In these embodiments, optionally, a specific method for initiating consensus on the transaction information may include:

When the target channel information is queried, a consensus is initiated for the transaction information.

Specifically, before initiating a consensus on the transaction information, after parsing the transaction request to obtain the transaction request information, the transaction request type of the transaction request can be determined first. If the transaction request type is not the first transaction type, but the second transaction type or the third transaction type The transaction type, that is, the transaction request is a transaction request for joining an existing channel or a transaction request for initiating a transaction in an existing channel, then further attribute information of multiple locally established channels in the target channel list in the local storage area is required. Query the target channel information in the generated first channel information. If the target channel information is queried from multiple first channel information in the target channel list, a consensus can be initiated on the transaction information, thereby preventing the consensus cluster from processing other consensus clusters. transaction requests, improving the reliability of the consensus cluster.

In these embodiments, the local repository's channel list refers to the target set The list of channels stored in the consensus cluster corresponding to the group address. The locally established channel refers to the channel established by the consensus cluster corresponding to the target cluster address. When the target peer node wants to join an existing channel or initiate a transaction in the existing channel, it can only initiate consensus through the consensus cluster that established the existing channel. Therefore, the transaction request type is not the first transaction type, but the first transaction type. For the second transaction type or the third transaction type, it is necessary to determine whether the existing channel targeted by the target peer node is the channel established by the consensus cluster through the target channel information in the transaction request information, because the target channel information will only store the channel. Channel information corresponding to the channel established by the consensus cluster. If the target channel information is queried in the target channel list, it means that the existing channel targeted by the target peer node is the channel established by the consensus cluster, and a consensus can be initiated for transaction information. .

In other embodiments, after querying the target channel information in the target channel list, the consensus method of the blockchain system may further include:

If the target channel information is not queried, generate an address query request according to the target channel information;

Send an address query request to the channel coordination node; wherein, the address query request is used to enable the channel coordination node to query the cluster address corresponding to the target channel information.

Specifically, after the consensus cluster queries the target channel information in the preset channel list, if the target channel information is not queried in the preset channel list, it can be determined that the transaction request is a transaction request corresponding to other consensus clusters, and the transaction request can be generated. The address query request corresponding to the target channel information is sent to the channel coordination node, so that the channel coordination node queries the cluster address corresponding to the target channel information in response to the address query request.

In some embodiments of the present invention, after sending the address query request to the channel coordination node, the consensus method of the blockchain system may further include:

Receive the cluster address corresponding to the target channel information returned by the channel coordination node;

Send the cluster address corresponding to the target channel information to the target peer node.

In these embodiments, after querying the cluster address corresponding to the target channel information, the channel coordination node may return the cluster address corresponding to the target channel information to the consensus cluster that sent the address query request. The consensus cluster receives the target channel information returned by the channel coordination node. After the cluster address corresponding to the target channel information, the cluster address corresponding to the target channel information can be sent to the target peer node, so that the target peer node can resend the transaction request to the correct consensus cluster based on the cluster address corresponding to the target channel information, and then Ensure the reliability of the blockchain system.

In other embodiments of the present invention, the address query request may also carry the node address of the target peer node, and the channel coordination node may directly base on the node address after querying the cluster address corresponding to the target channel information. The cluster address corresponding to the target channel information returned to the target peer node, thereby reducing the number of information forwarding and improving the response speed to the transaction request of the target peer node.

It should be noted that the specific method for the channel coordination node to return the cluster address corresponding to the target channel information in response to the address query request will be described in detail below, and will not be repeated here.

In these embodiments, since only the channel information corresponding to the channel established by the consensus cluster is stored in the target channel information, if the target channel information is not queried in the target channel list, it indicates the existing channel targeted by the target peer node If it is not the channel established by the consensus cluster, the channel coordination node needs to find the cluster address of the consensus cluster that established the existing channel for it.

In some embodiments of the present invention, the target channel information is a target hash value, and the target hash value is generated according to attribute information of the target channel corresponding to the transaction request; the target channel list is a target hash table, and the target hash table includes a plurality of first hash values, Each first hash value is generated based on attribute information of a locally established channel.

Specifically, each time the consensus cluster creates a channel, the consensus cluster can convert the attribute information of the created channel into a unique hash value through a preset hash algorithm, and store it as the first hash value in the target of the consensus cluster in the hash table.

Before the consensus cluster initiates a consensus on the transaction information, after parsing the transaction request to obtain the transaction request information, if the transaction request type is not the first transaction type, it is necessary to further query the target hash value among the multiple first hash values in the target hash table. If the target hash value is queried, a consensus can be initiated for transaction information; if the target hash value is not queried, then It can be determined that the transaction request is a transaction request corresponding to other consensus clusters.

Therefore, in the embodiment of the present invention, the channel information corresponding to each channel may correspond to a hash value, which can improve the security of using the channel information, thereby improving the security of the blockchain system.

In some embodiments of the present invention, the attribute information includes at least one of the following:

Channel name, channel creator, channel creation time.

In some embodiments, the attribute information may include any one of channel name, channel creator, and channel creation time. In other embodiments, the attribute information may further include any two of channel name, channel creator and channel creation time. In still other embodiments, the attribute information may also include channel name, channel creator and channel creation time.

In some embodiments, the channel creator may be represented by the node IP address of the peer node requesting to create the channel. In other embodiments, the channel creator may also request the public key representation of the peer node that creates the channel, which is not limited herein.

In some embodiments, the channel creation time may be the timestamp of the channel creation.

FIG. 7 shows a schematic flowchart of a consensus method of a blockchain system provided by another embodiment of the present invention.

In some embodiments of the present invention, the method shown in FIG. 7 may be executed by any one of the channel coordination nodes shown in FIG. 4 . The channel coordination node may be a server or a server cluster.

As shown in Figure 7, the consensus method of the blockchain system can include:

S710. Receive an address query request sent by the target consensus cluster; wherein, the address query request is generated according to the target channel information carried in the transaction request received by the target consensus cluster.

In some embodiments of the present invention, the target consensus cluster may be any consensus cluster in the blockchain system. For example, the target consensus cluster can be the blockchain system shown in Figure 4 Any of the consensus clusters in the .

S720. Parse the address query request to obtain address query request information, wherein the address query request information includes target channel information.

In some embodiments, the address query request information may include target channel information. In other embodiments, the address query request information may further include a node address, where the node address may be the node address of the peer node that sends the transaction request to the target consensus cluster, and the node address may include the peer node the node IP address. In still other embodiments, the address query request information may further include the cluster address of the target consensus cluster, wherein the cluster address of the target consensus cluster may include the cluster IP address of the target consensus cluster.

It should be noted that, the address query request information may also include other information for the secondary channel cooperating node to query the cluster address, which is not limited here.

S730. In the distributed database, query the cluster address corresponding to the target channel information;

In some embodiments of the present invention, the distributed database may store at least one second channel information in the blockchain system, and each sub-database in the distributed database is stored in a preset channel corresponding to a consensus cluster for coordination In the node, each preset channel coordination node can query the target channel coordination node storing the target channel information in the distributed database based on the agreement of the distributed database, and set the cluster bit of the consensus cluster corresponding to the target channel coordination node. address as the cluster address corresponding to the target channel information.

Among them, a second channel information corresponds to an existing channel in the blockchain system. A preset channel coordination node is a node in the blockchain system for maintaining a distributed database, and a preset channel coordination node corresponds to a consensus cluster.

It should be noted that after each consensus cluster establishes a new channel, the routing information of the channel will be sent to the preset channel coordination node corresponding to the consensus cluster, and each preset channel coordination node can be stored in a distributed database. Belonging to the sub-database of the preset channel coordination node, the method for each preset channel coordination node to search for the target channel coordination node storing the target channel information based on the distributed database can be realized by using the query method of the existing distributed database. Now, the address query request is forwarded between the preset channel cooperating nodes corresponding to the adjacent consensus clusters, so that the preset channel cooperating node that receives the address query request can query the target in the sub-database of the local storage area. Channel information, in order to realize the query of the target channel cooperative node, which will not be repeated here.

S740. If the address query request information further includes the node address, send the cluster address corresponding to the target channel information to the peer node corresponding to the node address.

Specifically, the address query request may also be generated according to the node address, so that the address query request carries the node address, and then the address query request information includes the node address. At this time, after querying the cluster address corresponding to the target channel information, the channel coordination node can directly send the cluster address corresponding to the target channel information to the peer node corresponding to the node address based on the node address, so as to make the peer The node resends the transaction request to the correct consensus cluster based on the cluster address corresponding to the target channel information.

Therefore, the channel coordination node can directly send the cluster address corresponding to the target channel information to the peer node, thereby improving the response speed to the peer node.

In the embodiment of the present invention, for a transaction request across consensus clusters, the cluster address of the consensus cluster corresponding to the transaction request can be inquired through the channel coordination node, thereby ensuring the orderly progress of transaction requests across consensus clusters and improving the blockchain system. reliability.

The specific implementation of the S730 will be described in detail below.

In some embodiments of the present invention, the target channel information is a target hash value, and the target hash value is generated according to attribute information of the target channel corresponding to the transaction request; the distributed database includes a distributed hash table, and the distributed hash table includes a plurality of second Hash value, each second hash value is generated according to the attribute information of a channel in the blockchain system.

In these embodiments, optionally, the specific method of S730 may include:

Based on the distributed hash table, among multiple preset channel coordination nodes, query the target channel coordination node that stores the target hash value; wherein, the preset channel coordination node is a node used to maintain the distributed hash table in the blockchain system , a preset channel coordination node corresponds to a consensus cluster;

Use the cluster address of the consensus cluster corresponding to the target channel coordination node as the cluster address corresponding to the target channel information.

Specifically, a second hash value corresponds to a channel. After each consensus cluster establishes a new channel, it can use the attribute information of the channel to generate the hash value corresponding to the channel, and then send the hash value corresponding to the channel to the consensus cluster. The corresponding preset channel coordination node, the preset channel coordination node will store the received hash value as the second hash value in the distributed hash table.

Each preset channel coordination node can store a hash sub-table belonging to the preset channel coordination node in the distributed hash table, and each preset channel coordination node searches for the target channel coordination node that stores the target channel information based on the distributed hash table. The method can be implemented by using the existing distributed hash table query method, that is, since the channel coordination node corresponding to the target consensus cluster starts, the address query request is forwarded between the preset channel coordination nodes corresponding to the adjacent consensus clusters, so as to After the preset channel cooperating node that receives the address query request parses the target hash value in the address query request, the target hash value obtained by parsing is compared with each second hash value in the hash sub-table in the local storage area. Compare, and then determine whether the target hash value exists in the hash sub-table of the local storage area, and if it exists in the hash sub-table of the local storage area, the preset channel coordination node can determine that it is the target channel coordination node, and The cluster address of the corresponding consensus cluster is fed back to the channel coordination node that sent the address query request to it, and finally returned to the channel coordination node that needs to query the cluster address corresponding to the target channel information, that is, the channel coordination node corresponding to the target consensus cluster. Channel cooperating node. After the channel coordination node corresponding to the target consensus cluster receives the cluster address of the consensus cluster corresponding to the target channel coordination node, it can be used as the cluster address corresponding to the target channel information.

In this embodiment of the present invention, the distributed hash table may be a distributed hash table based on the Kademlia protocol, or may be a distributed hash table based on other protocols, which is not limited herein.

In some embodiments of the present invention, the attribute information includes at least one of the following:

Channel name, channel creator, channel creation time.

The attribute information has been described above and will not be repeated here. The above is the specific implementation manner of the S730.

In some embodiments of the present invention, after S730, the consensus method of the blockchain system may further include:

If the address query request information does not include the node address, send the cluster address corresponding to the target channel information to the target consensus cluster.

Specifically, the address query request may not be generated according to the node address, so that the address query request does not carry the node address, and thus the address query request information does not include the node address. At this time, after querying the cluster address corresponding to the target channel information, the channel coordination node can send the cluster address corresponding to the target channel information to the target consensus cluster based on the cluster address of the target consensus cluster, so that the target consensus cluster can transfer the target channel information to the target consensus cluster. The cluster address corresponding to the channel information is forwarded to the peer node that sent the transaction request carrying the target channel information, so that the peer node resends the transaction request to the correct consensus cluster based on the cluster address corresponding to the target channel information.

Therefore, the channel coordination node can forward the cluster address corresponding to the target channel information to the peer node through the target consensus cluster, so as to reduce the amount of data carried by the address query request.

Taking the supply chain traceability scenario based on the blockchain system as an example, suppose that the production company B in region A needs to distribute the produced products to the distribution company D in region C, and the goods need to be tracked on the blockchain. Without loss of generality, it is assumed that the consensus cluster allocated by production enterprise A is consensus cluster O1, and channel E is first established through consensus cluster O1. Thereafter, the distribution enterprise B initiates a transaction request to join the channel E to the consensus cluster O2 allocated by the cluster scheduling node. Since the consensus cluster O2 does not contain information related to channel E, it cannot process the transaction request. Therefore, an address query request is sent to the channel cooperating node. The channel coordination node forwards the address query request (finally to the consensus cluster O1) between the channel coordination nodes of the channel coordination layer, finds the cluster address of the consensus cluster O1 corresponding to the channel, and finally returns the corresponding cluster address to the distribution company. B, B updates the cluster address corresponding to channel E. After that, production enterprise A and distribution enterprise B can The cluster address corresponding to Road E communicates normally to create a specific smart contract that meets the business needs and interests of both parties, and collaborates to carry out the supply chain traceability business.

To sum up, the channel coordination node can realize a channel-oriented consensus cluster dynamic switching mechanism, which can ensure the existence and circulation of blockchain transactions in any available consensus cluster in the whole domain on the basis of multi-consensus cluster scheduling, and finally go to the chain. Ensure the security and completeness of the blockchain system.

FIG. 8 shows a schematic flowchart of a consensus method for a blockchain system provided by yet another embodiment of the present invention.

In some embodiments of the present invention, the method shown in FIG. 8 may be performed by any of the peer nodes shown in FIG. 4 . The peer node may be a server or a server cluster.

As shown in Figure 8, the consensus method of the blockchain system can include:

S810. Send a consensus cluster routing request to the cluster scheduling node, so that the cluster scheduling node responds to the consensus cluster routing request, and determines the target consensus cluster in at least one available consensus cluster according to the node location included in the routing request information of the consensus cluster routing request, And return the target cluster address corresponding to the target consensus cluster; among them, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

S820. Receive the target cluster address returned by the cluster scheduling node;

S830. Based on the target cluster address, send a transaction request to the target consensus cluster.

In the embodiment of the present invention, the distribution of peer nodes can be realized by the node location, so that different peer nodes can match different consensus clusters based on their node locations, so that a large number of peer nodes can be processed in parallel by using multiple consensus clusters. Consensus increases the transmission volume of the blockchain system, which in turn can meet the demand for high transmission volume of the blockchain system.

In some embodiments of the present invention, when the transaction request type of the transaction request is the first transaction type, the target consensus cluster may initiate consensus directly based on the transaction request.

In other embodiments of the present invention, the transaction request may carry the target channel information of the target channel corresponding to the transaction request. After S830, the total number of the blockchain system Recognition methods can also include:

If the transaction request type of the transaction request is not the first transaction type, receive the cluster address corresponding to the target channel information returned by the target consensus cluster or channel coordination node;

Based on the cluster address corresponding to the target channel information, a transaction request is sent to the consensus cluster to which the target channel corresponding to the transaction request belongs.

To sum up, the embodiment of the present invention can meet the high throughput demand of the blockchain system when a large number of blockchain nodes are connected, and the performance of the blockchain system can be parallelized through the consensus architecture and consensus scheduling mechanism of the multi-consensus cluster. The improvement of the conveying capacity is greatly improved.

FIG. 9 shows a schematic structural diagram of a consensus apparatus of a blockchain system provided by an embodiment of the present invention.

In some embodiments of the present invention, the apparatus shown in FIG. 9 may be set in the cluster scheduling node shown in FIG. 4 . The cluster scheduling node may be a server or a server cluster.

As shown in Figure 9, the consensus device of the blockchain system may include:

The first receiving module 910 is configured to receive the consensus cluster routing request sent by the target peer node;

The first parsing module 920 is used for parsing the consensus cluster routing request to obtain routing request information; wherein, the routing request information includes the node location of the target peer node;

The first determination module 930 is used for determining a target consensus cluster in at least one available consensus cluster according to the position of the node; wherein, the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

The first sending module 940 is configured to send the target cluster address of the target consensus cluster to the target peer node.

In the embodiment of the present invention, the node location of the target peer node carried in the consensus cluster routing request sent by the target peer node is in at least one available consensus cluster in the normal working state of the blockchain system, and is Target peers assign target consensus cluster, and send the target cluster address of the target consensus cluster to the target corresponding node, so as to realize the shunting of peer nodes by node location, so that different peer nodes can match different consensus clusters based on their node locations, so that multiple The consensus cluster performs consensus on a large number of peer nodes in parallel, which improves the transmission capacity of the blockchain system, which in turn can meet the demand for high transmission capacity of the blockchain system.

In some embodiments of the present invention, the first determination module 930 is specifically used for:

Get the cluster location of each available consensus cluster;

Determine the response time of each available consensus cluster to the target peer node according to the node location and the cluster location;

Use the available consensus cluster with the shortest response time as the target consensus cluster.

In some embodiments of the present invention, the consensus device of the blockchain system may further include:

a first judging module for judging whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition;

Wherein, the first determination module 930 is further used for:

In the case that the cluster performance parameter does not meet the first preset condition, the available consensus cluster with the shortest response time is used as the target consensus set.

In some embodiments of the present invention, the first determining module 930 is further configured to:

When the cluster performance parameter satisfies the first preset condition, the available consensus cluster with the second shortest response time is used as the target consensus cluster.

In some embodiments of the present invention, the routing request information further includes a routing request type;

Among them, the first judgment module is specifically used for:

When the route request type is the first route type, it is determined whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition.

In some embodiments of the present invention, the first judgment module is further used for:

Detect whether the available consensus cluster with the shortest response time has a saturation status flag;

In the case of detecting the saturation state flag, determine that the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition;

In the case that it is detected that there is no saturation state flag, it is determined that the cluster performance parameter of the available consensus cluster with the shortest response time does not satisfy the first preset condition.

In some embodiments of the present invention, the first preset condition includes at least one of the following:

The delivery volume in the cluster performance parameter is greater than or equal to the preset delivery volume threshold;

The first duration of the delivery volume greater than or equal to the preset delivery volume threshold is greater than or equal to the first preset duration;

The average transaction delay in the cluster performance parameters is greater than or equal to the preset delay threshold;

The second time period when the average transaction delay is greater than or equal to the preset delay threshold is greater than or equal to the second preset time period.

In some embodiments of the present invention, the consensus device of the blockchain system may further include:

The fifth receiving module is used to receive the cluster registration request sent by the consensus cluster;

a fourth parsing module, used for parsing the cluster registration request to obtain cluster registration request information; wherein the cluster registration request information includes cluster verification information;

The cluster monitoring module is used to monitor the consensus cluster when the cluster verification information passes the verification;

The first processing module is used to use the consensus cluster as an available consensus cluster when monitoring that the consensus cluster is in a normal working state.

In some embodiments of the present invention, the cluster registration request information further includes cluster configuration information;

Wherein, before the sending the target cluster address of the target consensus cluster to the target peer node, the consensus device of the blockchain system may further include:

Information query module, used to query the target cluster corresponding to the target consensus cluster configuration information;

The address extraction module is used to extract the target cluster address from the target cluster configuration information.

In some embodiments of the present invention, the routing request information further includes node verification information;

Wherein, the first determination module 930 is also specifically used for:

In the case that the node verification information is verified, according to the node location, in at least one available consensus cluster, determine the target consensus cluster.

FIG. 10 shows a schematic structural diagram of a consensus apparatus of a blockchain system provided by another embodiment of the present invention.

In some embodiments of the present invention, the apparatus shown in FIG. 10 may be set in any consensus cluster shown in FIG. 4 . The consensus cluster may include at least one consensus node, and the consensus node may be a server or a server cluster.

3 As shown in Figure 10, the consensus device of the blockchain system may include:

The second receiving module 1010 is configured to receive the transaction request sent by the target peer node; wherein, the target peer node sends the transaction request based on the target cluster address, and the target cluster address is at least one available according to the node position of the target peer node. Determined in the consensus cluster, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

The second parsing module 1020 is used for parsing the transaction request to obtain transaction request information, wherein the transaction request information includes transaction information;

The information consensus module 1030 is used to initiate consensus on transaction information;

The transaction execution module 1040 is configured to execute the transaction corresponding to the transaction information when the consensus is successful.

In the embodiment of the present invention, the consensus cluster can receive transaction requests sent by target peer nodes based on node location allocation, so as to realize the distribution of peer nodes based on node locations, so that different peer nodes can match different peer nodes based on their node locations. Consensus cluster, so that multiple consensus clusters can be used to perform consensus on a large number of peer nodes in parallel, which improves the blockchain system It can meet the demand for high transmission volume of the blockchain system when a large number of nodes are connected. At the same time, even if the number of participating nodes increases, the scalability of the blockchain system can continue to be maintained.

In some embodiments of the present invention, the transaction request information further includes a transaction request type;

Among them, the information consensus module 1030 is specifically used for:

When the transaction request type is the first transaction type, a consensus is initiated for transaction information.

In some embodiments of the present invention, the transaction request information further includes target channel information;

Wherein, in some embodiments of the present invention, the consensus device of the blockchain system may further include:

The first acquisition module is used to acquire target channel information when the transaction request type is not the first transaction type;

The channel query module is used to query the target channel information in the target channel list; wherein, the target channel list is the channel list in the local storage area;

Among them, the information consensus module 1030 is further used for:

When the target channel information is queried, a consensus is initiated for the transaction information.

In some embodiments of the present invention, the consensus device of the blockchain system may further include:

The first generation module is used to generate an address query request according to the target channel information without querying the target channel information;

The fifth sending module is used for sending an address query request to the channel coordination node; wherein, the address query request is used for the channel coordination node to query the cluster address corresponding to the target channel information.

In some embodiments of the present invention, the consensus device of the blockchain system may further include:

The sixth receiving module is used for receiving the cluster address corresponding to the target channel information fed back by the channel coordination node;

The sixth sending module is used to send the cluster bit corresponding to the target channel information to the target peer node site.

In some embodiments of the present invention, the target channel information is a target hash value, and the target hash value is generated according to attribute information of the target channel corresponding to the transaction request; the target channel list is a target hash table, and the target hash table includes a plurality of first hash values, Each first hash value is generated based on attribute information of a locally established channel.

In some embodiments of the present invention, the attribute information includes at least one of the following:

Channel name, channel creator, channel creation time.

FIG. 11 shows a schematic structural diagram of a consensus apparatus of a blockchain system provided by another embodiment of the present invention. 3

In some embodiments of the present invention, the apparatus shown in FIG. 11 may be set in any one of the channel coordination nodes shown in FIG. 4 . The channel coordination node may be a server or a server cluster.

As shown in Figure 11, the consensus device of the blockchain system may include:

The third receiving module 1110 is configured to receive the address query request sent by the target consensus cluster; wherein, the address query request is generated according to the target channel information carried in the transaction request received by the target consensus cluster;

The third parsing module 1120 is used for parsing the address query request to obtain address query request information; wherein, the address query request information includes target channel information;

The address query module 1130 is used to query the cluster address corresponding to the target channel information in the distributed database;

The second sending module 1140 is configured to send the cluster address corresponding to the target channel information to the peer node corresponding to the node address when the address query request information further includes the node address.

In the embodiment of the present invention, for a transaction request across consensus clusters, the cluster address of the consensus cluster corresponding to the transaction request can be inquired through the channel coordination node, thereby ensuring the orderly progress of transaction requests across consensus clusters and improving the blockchain system. reliability.

In some embodiments of the present invention, the target channel information is a target hash value, The target hash value is generated according to the attribute information of the target channel corresponding to the transaction request; the distributed database includes a distributed hash table, and the distributed hash table includes a plurality of second hash values, and each second hash value is based on the block chain system. The attribute information of a channel is generated;

Among them, the address query module 1130 is specifically used for:

Based on the distributed hash table, among multiple preset channel coordination nodes, query the target channel coordination node that stores the target hash value; wherein, the preset channel coordination node is a node used to maintain the distributed hash table in the blockchain system , a preset channel coordination node corresponds to a consensus cluster;

Use the cluster address of the consensus cluster corresponding to the target channel coordination node as the cluster address corresponding to the target channel information.

In some embodiments of the present invention, the attribute information includes at least one of the following:

Channel name, channel creator, channel creation time.

In some embodiments of the present invention, the consensus device of the blockchain system may further include:

The seventh sending module is configured to send the cluster address corresponding to the target channel information to the target consensus cluster when the address query request information does not include the node address.

FIG. 12 shows a schematic structural diagram of a consensus apparatus of a blockchain system provided by yet another embodiment of the present invention.

In some embodiments of the present invention, the apparatus shown in FIG. 12 may be set in any of the peer nodes shown in FIG. 4 . The peer node may be a server or a server cluster.

As shown in Figure 12, the consensus device of the blockchain system may include:

The third sending module 1210 is configured to send a consensus cluster routing request to the cluster scheduling node, so that the cluster scheduling node responds to the consensus cluster routing request, according to the node position included in the routing request information of the consensus cluster routing request, at least one available consensus The target consensus cluster is determined in the cluster, and the target cluster address corresponding to the target consensus cluster is returned; among them, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

The fourth receiving module 1220 is used for receiving the target cluster address fed back by the cluster scheduling node;

The fourth sending module 1230 is configured to send a transaction request to the target consensus cluster based on the target cluster address.

In the embodiment of the present invention, the distribution of peer nodes can be realized by the node location, so that different peer nodes can match different consensus clusters based on their node locations, so that a large number of peer nodes can be processed in parallel by using multiple consensus clusters. Consensus increases the transmission volume of the blockchain system, which in turn can meet the demand for high transmission volume of the blockchain system.

In some embodiments of the present invention, the transaction request carries target channel information;

Wherein, the consensus device of the blockchain system may also include:

The seventh receiving module is used to receive the cluster address corresponding to the target channel information returned by the target consensus cluster or channel coordination node when the transaction request type of the transaction request is not the first transaction type;

The eighth sending module is configured to send a transaction request to the consensus cluster to which the target channel corresponding to the transaction request belongs, based on the cluster address corresponding to the target channel information.

FIG. 13 shows a schematic structural diagram of a consensus device of a blockchain system provided by an embodiment of the present invention.

As shown in FIG. 13 , the consensus device 1300 of the blockchain system includes an input device 1301 , an input interface 1302 , a central processing unit 1303 , a memory 1304 , an output interface 1305 , and an output device 1306 . The input interface 1302, the central processing unit 1303, the memory 1304, and the output interface 1305 are connected to each other through the bus bar 1310, and the input device 1301 and the output device 1306 are respectively connected to the bus bar 1310 through the input interface 1302 and the output interface 1305, and then to the bus bar 1310. Other elements of the consensus device 1300 of the blockchain system are connected.

Specifically, the input device 1301 receives input information from the outside, and transmits the input information to the central processing unit 1303 through the input interface 1302 ; the central processing unit 1303 processes the input information based on the computer-executable instructions stored in the memory 1304 to generate Output information, temporarily or permanently store the output information in the memory 1304, and then pass the output interface 1305 transmits the output information to the output device 1306; the output device 1306 outputs the output information to the outside of the consensus device 1300 of the blockchain system for the user to use.

That is to say, the consensus device of the blockchain system shown in FIG. 13 can also be implemented to include: a memory storing computer-executable instructions; and a processor, which can implement the present invention when executing the computer-executable instructions. The consensus method and device of the blockchain system described in the embodiments of the invention.

Embodiments of the present invention further provide a computer-readable storage medium, where computer program instructions are stored thereon; when the computer program instructions are executed by a processor, the consensus method of the blockchain system provided by the embodiments of the present invention is implemented.

The functional blocks shown in the above structural block diagrams can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, it can be, for example, electronic circuits, application specific integrated circuits (ASICs), suitable firmware, plug-ins, function cards, and the like. When implemented in software, elements of the invention are programs or code segments that are used to perform the required tasks. The program, or segments of program code, can be stored on a machine-readable medium or transmitted over a transmission medium or communication link by a data signal carried in a carrier wave. A "machine-readable medium" may include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, Erasable Read-Only Memory (EROM), floppy disks, CD-ROMs, optical disks, hard disks, and optical fiber media , Radio Frequency (RF) link, and so on. The code snippets may be downloaded via a computer network such as the Internet, an intranet, or the like.

It should also be noted that the above describes specific embodiments of the present invention. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in the order in which they are described and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multiplexing and parallel processing are also possible or may be advantageous.

The above descriptions are only specific implementations of the present invention, and those skilled in the art Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, module and unit described above can be referred to the corresponding process in the foregoing method embodiments, which will not be repeated here. It should be understood that the protection scope of the present invention is not limited to this. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be covered in within the protection scope of the present invention.

S510, S520, S530, S540: Process

Claims (29)

A consensus method for a blockchain system, including: Receive the consensus cluster routing request sent by the target peer node; Parsing the consensus cluster routing request to obtain routing request information; wherein the routing request information includes the node location of the target peer node; According to the position of the node, in at least one available consensus cluster, a target consensus cluster is determined; wherein, the available consensus cluster is a consensus cluster in a normal working state in the blockchain system; The target cluster address of the target consensus cluster is sent to the target peer node. The method according to claim 1, wherein the determining a target consensus cluster in at least one available consensus cluster according to the node position includes: Get the cluster location of each of the available consensus clusters; determining the response time of each of the available consensus clusters to the target peer node according to the node location and the cluster location; The available consensus cluster with the shortest response time is taken as the target consensus cluster. The method according to claim 2, wherein, before the available consensus cluster with the shortest response time is used as the target consensus cluster, the method further comprises: Determine whether the cluster performance parameter of the available consensus cluster with the shortest response time meets the first preset condition; Wherein, the available consensus cluster with the shortest response time is used as the target consensus cluster, including: In the case that the cluster performance parameter does not meet the first preset condition, the available consensus cluster with the shortest response time is used as the target consensus set. The method according to claim 3, wherein after judging whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition, the method further includes: In the case that the cluster performance parameter satisfies the first preset condition, the response time will be The shortest available consensus cluster is used as the target consensus cluster. The method according to claim 3, wherein the routing request information further includes a routing request type; Wherein, determining whether the cluster performance parameter of the available consensus cluster with the shortest response time meets the first preset condition includes: In the case that the route request type is the first route type, it is judged whether the cluster performance parameter of the available consensus cluster with the shortest response time meets the first preset condition. The method according to any one of request items 3-5, wherein the judging whether the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition includes: Detecting whether the available consensus cluster with the shortest response time has a saturation status flag; In the case of detecting the saturation state flag, determining that the cluster performance parameter of the available consensus cluster with the shortest response time satisfies the first preset condition; In the case of detecting that it does not have the saturation state flag, it is determined that the cluster performance parameter of the available consensus cluster with the shortest response time does not meet the first preset condition. The method according to any one of claims 3-5, wherein the first preset condition includes at least one of the following: The delivery volume in the cluster performance parameter is greater than or equal to the preset delivery volume threshold; The first duration of the delivery volume greater than or equal to the preset delivery volume threshold is greater than or equal to the first preset duration; The average transaction delay in the cluster performance parameter is greater than or equal to the preset delay threshold; The second time period in which the average transaction delay is greater than or equal to the preset delay threshold is greater than or equal to a second preset time period. The method according to claim 1, wherein, before the target consensus cluster is determined in at least one available consensus cluster according to the node position, the method further comprises: receiving a cluster registration request sent by the consensus cluster; Parsing the cluster registration request to obtain cluster registration request information; wherein the cluster registration request information includes cluster verification information; In the case that the cluster verification information is verified, monitor the consensus cluster; In the case of monitoring that the consensus cluster is in a normal working state, the consensus cluster is used as the available consensus cluster. The method according to claim 8, wherein the cluster registration request information further includes cluster configuration information; Wherein, before the sending the target cluster address of the target consensus cluster to the target peer node, the method further includes: query the target cluster configuration information corresponding to the target consensus cluster; In the target cluster configuration information, the target cluster address is extracted. The method according to claim 1, wherein the routing request information further includes node verification information; Wherein, determining a target consensus cluster in at least one available consensus cluster according to the node location includes: In the case that the node verification information is verified, the target consensus cluster is determined in at least one of the available consensus clusters according to the node position. A consensus method for a blockchain system, including: Receive a transaction request sent by a target peer node; wherein, the target peer node sends the transaction request based on a target cluster address, and the target cluster address is in at least one available consensus according to the node location of the target peer node It is determined in the cluster that the available consensus cluster is the consensus cluster in the normal working state in the blockchain system; Parse the transaction request to obtain transaction request information; wherein, the transaction request information includes transaction information; Initiate a consensus on the transaction information; If the consensus is successful, the transaction corresponding to the transaction information is executed. The method according to claim 11, wherein the transaction request information further includes a transaction request type; Wherein, the initiating a consensus on the transaction information includes: When the transaction request type is the first transaction type, a consensus is initiated for the transaction information. The method according to claim 12, wherein the transaction request information further includes target channel information; Wherein, after parsing the transaction request to obtain transaction request information, the method further includes: In the case that the transaction request type is not the first transaction type, obtain the target channel information; Query the target channel information in the target channel list; wherein, the target channel list is the channel list of the local storage area; Wherein, the initiating a consensus on the transaction information includes: When the target channel information is queried, a consensus is initiated for the transaction information. The method according to claim 13, wherein after querying the target channel information in the target channel list, the method further comprises: In the case that the target channel information is not queried, generate an address query request according to the target channel information; The address query request is sent to the channel coordination node, wherein the address query request is used to enable the channel coordination node to query the cluster address corresponding to the target channel information. The method according to claim 14, wherein after the address query request is sent to the channel coordination node, the method further includes: receiving the cluster address corresponding to the target channel information returned by the channel coordination node; Send the cluster address corresponding to the target channel information to the target peer node. The method according to any one of request items 13-15, wherein the target channel information is a target hash value, and the target hash value is generated according to attribute information of the target channel corresponding to the transaction request; the target channel list It is a target hash table, the target hash table includes a plurality of first hash values, and each of the first hash values is generated according to attribute information of a locally established channel. The method according to claim 16, wherein the attribute information includes at least one of the following: Channel name, channel creator, channel creation time. A consensus method for a blockchain system, including: Receive an address query request sent by the target consensus cluster; wherein, the address query request is generated according to the target channel information carried in the transaction request received by the target consensus cluster; Parsing the address query request to obtain address query request information; wherein the address query request information includes the target channel information; In the distributed database, query the cluster address corresponding to the target channel information; When the address query request information further includes a node address, the cluster address corresponding to the target channel information is sent to the peer node corresponding to the node address. The method according to claim 18, wherein the target channel information is a target hash value, and the target hash value is generated according to attribute information of the target channel corresponding to the transaction request; the distributed database includes a distributed hash value table, the distributed hash table includes a plurality of second hash values, each of which is generated according to attribute information of a channel in the blockchain system; Wherein, querying the cluster address corresponding to the target channel information in the distributed database includes: Based on the distributed hash table, among a plurality of preset channel coordination nodes, query the target channel coordination node that stores the target hash value; wherein, the preset channel coordination node is used in the blockchain system. For the node maintaining the distributed hash table, one of the preset channel coordination nodes corresponds to one consensus cluster; The cluster address of the consensus cluster corresponding to the target channel coordination node is used as the cluster address corresponding to the target channel information. The method according to claim 19, wherein the attribute information includes at least one of the following: Channel name, channel creator, channel creation time. The method according to claim 18, wherein after querying the cluster address corresponding to the target channel information in the distributed database, the method further comprises: In the case that the address query request information does not include the node address, the cluster address corresponding to the target channel information is sent to the target consensus cluster. A consensus method for a blockchain system, including: Send a consensus cluster routing request to the cluster scheduling node, so that the cluster scheduling node responds to the consensus cluster routing request, and determines in at least one available consensus cluster according to the node location included in the routing request information of the consensus cluster routing request target consensus cluster, and return the target cluster address corresponding to the target consensus cluster; wherein, the available consensus cluster is the consensus cluster in the normal working state in the blockchain system; receiving the target cluster address returned by the cluster scheduling node; Based on the target cluster address, a transaction request is sent to the target consensus cluster. The method according to claim 22, wherein the transaction request carries target channel information; Wherein, after the transaction request is sent to the target consensus cluster based on the target cluster address, the method further includes: If the transaction request type of the transaction request is not the first transaction type, receive the cluster address corresponding to the target channel information returned by the target consensus cluster or channel coordination node; Based on the cluster address corresponding to the target channel information, the transaction request is sent to the consensus cluster to which the target channel corresponding to the transaction request belongs. A consensus device for a blockchain system, including: The first receiving module is used to receive the consensus cluster routing request sent by the target peer node; a first parsing module for parsing the consensus cluster routing request to obtain routing request information; wherein the routing request information includes the node location of the target peer node; A first determination module is used to determine a target consensus cluster in at least one available consensus cluster according to the node position; wherein, the available consensus cluster is a location in the blockchain system. Consensus cluster in normal working state; The first sending module is configured to send the target cluster address of the target consensus cluster to the target peer node. A consensus device for a blockchain system, including: The second receiving module is configured to receive the transaction request sent by the target peer node; wherein, the target peer node sends the transaction request based on the target cluster address, and the target cluster address is based on the target peer node. The position of the node is determined in at least one available consensus cluster, and the available consensus cluster is the consensus cluster in the normal working state in the blockchain system; The second parsing module is used for parsing the transaction request to obtain transaction request information; wherein, the transaction request information includes transaction information; An information consensus module for initiating consensus on the transaction information; The transaction execution module is used to execute the transaction corresponding to the transaction information when the consensus is successful. A consensus device for a blockchain system, including: The third receiving module is configured to receive the address query request sent by the target consensus cluster; wherein, the address query request is generated according to the target channel information carried in the transaction request received by the target consensus cluster; a third parsing module for parsing the address query request to obtain address query request information; wherein the address query request information includes the target channel information; The address query module is used to query the cluster address corresponding to the target channel information in the distributed database; The second sending module is configured to send the cluster address corresponding to the target channel information to the peer node corresponding to the node address when the address query request information further includes a node address. A consensus device for a blockchain system, including: The third sending module is used to send a consensus cluster routing request to the cluster scheduling node, so that the cluster scheduling node responds to the consensus cluster routing request, according to the consensus cluster routing request The node location included in the routing request information, determine the target consensus cluster in at least one available consensus cluster, and return the target cluster address corresponding to the target consensus cluster; wherein, the available consensus cluster is the blockchain system A consensus cluster in normal working state; a fourth receiving module, configured to receive the target cluster address fed back by the cluster scheduling node; The fourth sending module is configured to send a transaction request to the target consensus cluster based on the target cluster address. A consensus device for a blockchain system, characterized in that the device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the consensus method of the blockchain system described in any one of claim items 1-10, claim items 11-17, claim items 18-21 or claim items 22-23 is implemented . A computer-readable storage medium, characterized in that, computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, requirements such as request items 1-10, request items 11-17, request items 1-10, request items 11-17, and A consensus method for a blockchain system as described in any of items 18-21 or claim items 22-23.

Images