WO2021238298A1

WO2021238298A1 - Consensus method, apparatus and device for blockchain system, and medium

Info

Publication number: WO2021238298A1
Application number: PCT/CN2021/075339
Authority: WO
Inventors: 黄彦; 周钰; 胡庆林; 刘为怀; 朱涛; 胡景秀; 刘苏林; 许玉壮; 王贺贺
Original assignee: 中国银联股份有限公司
Priority date: 2020-05-29
Filing date: 2021-02-04
Publication date: 2021-12-02
Also published as: TWI790611B; CN111786952B; TW202145116A; CN111786952A

Abstract

Disclosed are a consensus method, apparatus and device for a blockchain system, and a medium. A consensus method for a blockchain system comprises: receiving a consensus cluster routing request sent by a target peer node; parsing the consensus cluster routing request to obtain routing request information, the routing request information comprising the node position of the target peer node; determining a target consensus cluster from at least one available consensus cluster according to the node position, the available consensus cluster being 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. The embodiments of the present invention are able to solve the problem of the existing consensus mechanism being unable to satisfy the high throughput requirement of blockchain systems.

Description

Consensus method, device, equipment and medium of blockchain system

Cross-references to related applications

This application claims the priority of Chinese Patent Application No. 202010478177.8 filed in China on May 29, 2020, the entire content of which is incorporated herein by reference.

Technical field

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

Background technique

The consensus mechanism is a mechanism by which each node in the blockchain system reaches a consensus on block information throughout the network. It 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 resist malicious attacks.

However, with the continuous increase of the number of nodes in the blockchain system, the existing consensus mechanism is no longer sufficient to meet the high throughput requirements of the blockchain system.

Summary of the invention

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

In the 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;

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

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

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

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

Receive a transaction request sent by a target peer node, where the target peer node sends a 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 cluster is a block The consensus cluster in the normal working state of the chain system;

Analyze the transaction request to obtain transaction request information, which includes transaction information;

Initiate a consensus on transaction information;

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

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

Receive an address query request sent by the target consensus cluster, and the address query request is generated based on 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, which includes target channel information;

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

When the address query request information also 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 the 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 feeds it back The target cluster address corresponding to the target consensus cluster, where the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

Receive the target cluster address fed back by the cluster scheduling node;

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

In the 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 to parse the consensus cluster routing request to obtain routing request information, and the routing request information includes the node location of the target peer node;

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

The first sending module is used to send 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, where 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 , The available consensus cluster is the consensus cluster in the normal working state of the blockchain system;

The second analysis module is used to analyze the transaction request to obtain transaction request information, the transaction request information including 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 request sent by the target consensus cluster, and 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 to parse the address query request to obtain address query request information, and 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 also 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 feed back the target cluster address corresponding to the target consensus cluster, where the available consensus cluster is the consensus cluster in the blockchain system that is in a normal working state;

The fourth receiving module is used to receive 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 of a blockchain system, the device including: a processor and a memory storing computer program instructions;

The processor implements the consensus method of the blockchain system as described in the first aspect, the second aspect, the third aspect, or the fourth aspect when the processor executes the computer program instructions.

In a tenth aspect, an embodiment of the present invention provides a computer-readable storage medium with computer program instructions stored on the computer-readable storage medium. When the computer program instructions are executed by a processor, the The consensus method of the blockchain system described in the third aspect or the fourth aspect.

The consensus method, device, equipment, and medium of the blockchain system in the embodiment 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, in at least one of the blockchain systems In the available consensus clusters in a 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 peer node, so as to realize the distribution of peer nodes through the node location, so that different pairs The peer nodes can match different consensus clusters based on their node positions, so that multiple consensus clusters can be used to consensus on a large number of peer nodes in parallel, which improves the throughput of the blockchain system and can meet the high throughput of the blockchain system. The amount of demand.

Description of the drawings

In order to explain the technical solutions of the embodiments of the present invention more clearly, the following will briefly introduce the drawings needed in the embodiments of the present invention. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative work, other drawings can be obtained from these drawings.

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

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

Figure 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;

FIG. 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;

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

FIG. 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;

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

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

FIG. 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.

Detailed ways

The features and exemplary embodiments of each aspect of the present invention will be described in detail below. In order to make the objectives, technical solutions, and advantages of the present invention clearer, the following further describes the present invention in detail 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. For those skilled in the art, the present invention can be implemented without some of these specific details. The following description of the embodiments is only to provide a better understanding of the present invention by showing examples of the present invention.

It should be noted that in this article, 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 one of these entities or operations. There is any such actual relationship or order between. Moreover, the terms "including", "including" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device that includes a series of elements includes not only those elements, but also those that are not explicitly listed Other elements of, or also include elements inherent to this process, method, article or equipment. If there are no more restrictions, the element defined by the sentence "including..." does not exclude the existence of other same elements in the process, method, article, or equipment that includes the element.

Figure 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 PC-1, a peer-to-peer cluster PC-2, and a user cluster CC. Among them, 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 may be divided into different peer clusters according to node locations. Blockchain ledgers BC-1, BC-2, BC-3, BC-4, BC-5, BC-6 respectively correspond to different channels (such as sub-blockchains) formed by the consensus cluster OC and different peer nodes Blockchain ledger. The user cluster CC includes at least one user node.

Figure 2 shows the system architecture diagram of the blockchain system in Figure 1.

As shown in Figure 2, the blockchain system is a Hyperledger (Hyperledger Fabric) architecture. 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 authority 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 system shown in Figures 1 and 2, each user node can communicate with a peer node in a corresponding peer-to-peer cluster, and send a service request to the peer node or receive the request result fed back by the peer node. Each peer node can also communicate with the consensus cluster OC, and send a transaction request to the consensus cluster OC based on the received service request or receive the request result fed back by the consensus cluster OC.

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

Existing methods for improving the throughput of the blockchain system are generally to improve the consensus algorithm of the consensus cluster without changing the system architecture of the blockchain system to increase the throughput of the blockchain system.

However, the applicant found that as the number of connected user nodes increases, the amount of transactions that can be processed per second on the user side will drop rapidly. It only relies on the improvement of the consensus algorithm to meet the high throughput requirements of the blockchain system. The difficulty is great, resulting in the low throughput of the blockchain system.

In order to solve the above-mentioned problems, the embodiments of the present invention provide a new system architecture applied to a blockchain system and a blockchain system corresponding to the system architecture.

Figure 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 authority 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 achieve uniform sequencing of blockchain transactions. The channel coordination layer 302 includes channel coordination nodes, which are used for channel coordination routing of transaction requests across consensus clusters, so as to improve the system's cross-regional service capabilities. The peer-to-peer layer 305 includes at least one peer-to-peer cluster, which is used to initiate a transaction request to the consensus cluster layer. The cluster scheduling layer 304 includes a cluster scheduling node, which is used to allocate a consensus cluster to each peer node in the peer cluster, so as to realize the dynamic allocation of the consensus cluster.

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 PC-1, a cluster scheduling layer, and a peer-to-peer cluster PC- 2 and user cluster CC. Among them, 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 each 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 may be divided into different peer clusters according to node locations. The cluster scheduling layer includes at least one cluster scheduling node. Blockchain ledgers BC-1, BC-2, BC-3, and BC-4 are respectively 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 a peer node in a corresponding peer-to-peer cluster, and send a service request to the peer node or receive a request result fed back by the peer node. 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 in the consensus cluster routing request. The peer nodes allocate consensus clusters. Each peer node can also communicate with the consensus cluster allocated by the cluster scheduling node, and send a transaction request to the consensus cluster based on the received service request or receive the request result fed back by the consensus cluster. When the consensus cluster receives a cross-consensus cluster transaction request, 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 sending the transaction request Waiting for the node to be able to 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 through 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 throughput of the blockchain system, which in turn can meet the needs of the blockchain system for high throughput, and can adapt to efficient and secure business requirements.

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

Based on the blockchain system provided by the embodiment of the present invention, the embodiment of the present invention provides a consensus method, device, equipment, and medium of the 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. Among them, 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 may 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. Among them, the first routing type can be used to characterize 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 characterize that the routing request is that the peer node is joining an existing channel. The consensus cluster routing request sent at the time.

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, where 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 the routing request information contained in the consensus cluster routing request.

In some embodiments, the route request information may include the node location of the target peer node, and the node location includes the geographic location of the target peer node. In other embodiments, the routing request information may also include the routing request type. In still other embodiments, the routing request information may also include node verification information, and the node verification information includes information used to verify the validity of the certificate of the target peer node. In some embodiments, the routing request information may further include the node address of the target peer node, and the node address includes the node Internet Protocol (IP) address of the target peer node.

It should be noted that the routing request information may also include other information used to assist 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 location of the node, where 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 a target consensus cluster to the target peer node based on the shortest time principle, 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 peering carried in the consensus cluster routing request For the node position of the node, select the consensus cluster within the preset distance corresponding to the node position from multiple consensus clusters, and select the consensus cluster with the shortest response time from the selected consensus clusters as the target consensus cluster, based on The shortest time principle allocates the target consensus cluster to the target peer node.

Among them, the preset distance range can be set as required, and there is no limitation 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 some other embodiments of the present invention, the cluster scheduling node can also allocate a target consensus cluster to the target peer node based on the shortest distance principle, according to the node location and the cluster location of each available consensus cluster.

Among them, the cluster location may include the geographic location of the consensus cluster.

Specifically, after the cluster scheduling node receives the consensus cluster routing request, based on the node location of the target peer node carried in the consensus cluster routing request, the consensus cluster with the cluster location closest to the node location can be selected from multiple consensus clusters The cluster, as the target consensus cluster, allocates 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 closest target consensus cluster 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 can 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, based on the node position of the target peer node carried in the consensus cluster routing request sent by the target peer node, in at least one available consensus cluster in the normal working state of the blockchain system, it is the target The peer node allocates the target consensus cluster, and sends the target cluster address of the target consensus cluster to the target peer node to realize the distribution of peer nodes through the node location, so that different peer nodes can match different consensus clusters based on their node locations In this way, multiple consensus clusters can be used to perform consensus on a large number of peer nodes in parallel, which improves the throughput of the blockchain system, and thus can meet the demand for high throughput of the blockchain system.

The specific implementation of 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 can also be verified.

Correspondingly, the specific method of S530 may include:

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

In some embodiments, the node verification information may be generated by the target peer node according to the certificate distributed by the certificate authority node. For example, the certificate authority 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 is verified, 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 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 consensus cluster routing requests, 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 if the node verification information passes the verification, allocate 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. The cluster registration request information includes cluster verification information;

When 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 regarded as an 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 the cluster scheduling node receives the cluster registration request sent by the consensus cluster, it can parse the cluster registration request to obtain the cluster verification information, and then verify the legitimacy of the consensus cluster based on the cluster verification information, and if the cluster verification information is verified, The consensus cluster is successfully registered, and the cluster scheduling node can continuously 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 consensus cluster dynamic network map; 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.

Wherein, the cluster verification information includes information used to verify the validity of the certificate of the consensus cluster. The cluster verification information can be generated by the consensus cluster according to the certificate distributed by the certificate authority node. For example, the certificate authority 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 legal cluster of the blockchain system.

In some embodiments of the present invention, after the consensus cluster is successfully registered, it can send the heartbeat of the consensus cluster to the cluster scheduling node, and the cluster scheduling node can 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 position of the node, the target consensus cluster is determined in at least one available consensus cluster in the consensus cluster dynamic network map.

Since the available consensus clusters in the consensus cluster dynamic network map are dynamically changed based on the working status of each consensus cluster, the cluster scheduling node can dynamically allocate the target consensus cluster in the normal working state to the target peer node to improve the block The reliability of the chain system.

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

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 in the cluster configuration information of each registered consensus cluster based on the target cluster ID of the target consensus cluster, and extract the target from the target cluster configuration information The cluster address is used to send the target cluster address of the target consensus cluster allocated to the target peer node.

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

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

Among them, the cluster performance parameters may include parameters such as the throughput of the consensus cluster and the average transaction delay. The average transaction delay can be obtained from the peer node communicating 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 with the cluster scheduling node to the cluster scheduling node at regular intervals. Time.

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

In the case that the cluster performance parameters do not meet the first preset condition, the available consensus cluster with the shortest response time is taken as the target consensus cluster.

Specifically, the cluster scheduling node may determine whether the cluster performance parameters of the available consensus cluster meet the first preset condition after determining the available consensus cluster with the shortest response time to the target peer node, and determine whether the available consensus cluster has reached Saturated state. If it is determined that the cluster performance parameters do 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 determining whether the cluster performance parameters of the available consensus cluster with the shortest response time meet the first preset condition, the consensus method of the blockchain system may further include:

When the cluster performance parameters meet the first preset condition, the available consensus cluster with the second shortest response time is taken as the target consensus cluster.

Specifically, the cluster scheduling node may also determine whether the cluster performance parameters of the available consensus cluster meet the first preset condition, and if it is determined that the cluster performance parameters meet the first preset condition, that is, the available consensus cluster reaches a saturated state, then The available consensus cluster with the shortest response time is taken as the target consensus cluster.

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

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

It should be noted that the method for judging the saturation of the available consensus cluster with the shortest response time is similar to the method for judging the saturation of the available consensus cluster with the shortest response time. Determine whether the available consensus cluster with the shortest response time is determined. The method for the target consensus cluster is similar to the method for determining whether the available consensus cluster with the shortest response time is used 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 also include the 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 meets the first preset condition may further include:

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

Specifically, before determining whether the cluster performance parameter of the available consensus cluster with the shortest response time meets the first preset condition, the routing request type of the consensus cluster routing request can 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 meet the first preset Conditions, and no longer consider the consensus cluster that has been 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 an existing channel, there is no need to determine whether the cluster performance parameters of the available consensus cluster with the shortest response time meet the first With preset 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 throughput in the cluster performance parameter is greater than or equal to the preset throughput threshold;

The first duration for which the throughput is greater than or equal to the preset throughput 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 throughput threshold may correspond to the critical level of the benchmark technical indicator. For example, the preset throughput threshold may be 90%, or may be other thresholds set as needed. The average transaction delay can also correspond to the critical level of the benchmark technical indicator. For example, the preset delay threshold can be 10%, or other thresholds set as needed. The first preset duration and the second preset duration may be durations set according to needs, respectively, and there is no limitation here.

In some embodiments, the average transaction delay greater than or equal to the preset delay threshold may 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 is greater than or equal to the preset delay threshold may be that the average transaction delay of the 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 other numbers set as needed.

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

In other embodiments, in order to reduce the data processing volume 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 meets the first preset condition further includes:

Check whether the available consensus cluster with the shortest response time has a saturation status mark;

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

In the case where it is detected that it does not have a saturation state mark, 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.

Specifically, the cluster scheduling node may determine whether the cluster performance parameters of each available consensus cluster meet the first preset condition at regular intervals, and add a saturation state mark to the available consensus clusters whose cluster performance parameters meet the first preset condition.

After the cluster scheduling node obtains the available consensus cluster with the shortest response time, the saturation status flag can be used to determine whether the cluster performance parameters of the available consensus cluster with the shortest response time meet the first preset condition, thereby reducing the data processing of the cluster scheduling node Increase the efficiency of data processing.

In some embodiments of the present invention, a consensus cluster can correspond to a location area (ie a geographic area), and a location area can correspond to at least one consensus cluster. The cluster scheduling node can be based on different location areas that may cause problems due to different economic development levels. Associate the difference in the degree of activity of the blockchain business, implement a load balancing mechanism, and reasonably allocate consensus clusters for each peer node, so as to realize the regional division of peer nodes to solve the performance limitation of the consensus algorithm of a single consensus cluster. The situation where the transaction consensus processing capacity of the location area is saturated.

FIG. 6 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. 6 may be executed by any consensus cluster shown in FIG. 4. Among them, 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, where 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. 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 transaction request type of the transaction request received by the consensus cluster may include a first transaction type, a second transaction type, and a third transaction type. Among them, the first transaction type can be used to indicate that the transaction request is a transaction request to establish a channel, the second transaction type can be used to indicate that the transaction request is a transaction request to join an existing channel, and the third transaction type can be used to indicate that the transaction request is an initiation A transaction request for a transaction in an existing channel.

S620: Parse the transaction request to obtain transaction request information, where 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, and obtain the transaction request information contained in the transaction request.

In some embodiments, the transaction request information may include transaction information, and the transaction information is information used to initiate a 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, and the node address includes the node IP address of the target peer node. In some embodiments, the transaction request information may further include node verification information, and the node verification information includes information used to verify 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 a consensus on transaction information based on a single zookeeper consensus algorithm. In other embodiments of the present invention, the consensus cluster may also initiate a consensus on transaction information based on the supported raft consensus algorithm. In other embodiments of the present invention, the consensus cluster may also initiate a consensus on transaction information based on other consensus algorithms, which is not limited here.

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 through node locations, so that different peer nodes can match different nodes based on their node locations. Consensus clusters can use multiple consensus clusters to perform consensus on a large number of peer nodes in parallel, which improves the throughput of the blockchain system, and thus can meet the high throughput requirements 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 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 also include the transaction request type.

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

In the case where the transaction request type is the first transaction type, a consensus is initiated for the transaction information.

Specifically, before initiating a consensus on transaction information, you can first determine the transaction request type of the transaction request. If the transaction request type is the first transaction type, that is, the transaction request can be a transaction request that characterizes the establishment of a channel, and the transaction information can be directly initiated. 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 also 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:

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, where the target channel list is a channel list stored locally. The target channel list can include multiple first channel information, and each first channel information can be based on the attributes of a locally established channel Information generation.

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. Transaction type, that is, if the transaction request is a transaction request to join an existing channel or a transaction request to initiate a transaction in an existing channel, it needs to be further generated in the target channel list stored locally based on the attribute information of the locally established channel The target channel information is queried in the 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, which can prevent the consensus cluster from processing transactions corresponding to other consensus clusters Request to improve the reliability of the consensus cluster.

In these embodiments, the locally stored channel list refers to the channel list stored in the consensus cluster corresponding to the target cluster address, and 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 an existing channel, it can only initiate a consensus by establishing the consensus cluster of 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, the target channel information in the transaction request information needs to be used to determine whether the existing channel targeted by the target peer node is the channel established by the consensus cluster, because only the target channel information will be stored The 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 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 based on the target channel information;

An address query request is sent to the channel coordination node, and 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. An address query request corresponding to the target channel information is sent, and an address query request is sent to the channel cooperation node, so that the channel cooperation 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 an 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 fed back by the channel cooperative node;

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

In these embodiments, the channel cooperation node may, after querying the cluster address corresponding to the target channel information, feed back the cluster address corresponding to the target channel information to the consensus cluster that sent the address query request. After the consensus cluster receives the cluster address corresponding to the target channel information fed back by the channel cooperative node, it can send the cluster address corresponding to the target channel information to the target peer node, so that the target peer node sends the correct cluster address based on the target channel information. The consensus cluster resends the transaction request to 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 coordinating node may query the cluster address corresponding to the target channel information directly based on the node address to send the target peer node address. The cluster address corresponding to the target channel information fed back by the 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 feed back 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 the channel is not 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, which is generated according to the 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 A hash value, each first hash value is generated according to the attribute information of a locally established channel.

Specifically, when a 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 in the consensus cluster as the first hash value In the target 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, you need to further query the target hash value in the multiple first hash values of the target hash table. Hope value. If the target hash value is queried, a consensus can be initiated for the transaction information; if the target hash value is not queried, 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 can 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 the channel name, channel creator, and channel creation time. In other embodiments, the attribute information may also include any two of the channel name, channel creator, and channel creation time. In still other embodiments, the attribute information may also include the 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 indicate the public key of the peer node requesting to create the channel, which is not limited here.

In some embodiments, the channel creation time may be the timestamp of 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 channel coordination node shown in FIG. 4. Among them, the channel cooperation 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, and 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 may be any consensus cluster in the blockchain system shown in FIG. 4.

S720. Parse the address query request to obtain address query request information, where 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, which may be the node address of a peer node that sends a transaction request to the target consensus cluster, and the node address may include the node IP address of the peer node. In still other embodiments, the address query request information may further include the cluster address of the target consensus cluster, and 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 used to assist the channel coordination node to query the cluster address, which is not limited here.

S730. Query the cluster address corresponding to the target channel information in the distributed database;

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 coordination node corresponding to a consensus cluster, Makes each preset channel coordination node can query the target channel coordination node storing the target channel information in the distributed database based on the protocol of the distributed database, and use the cluster address of the consensus cluster corresponding to the target channel coordination node as the target channel information correspondence The cluster address.

Among them, a second channel information corresponds to an existing channel in the blockchain system. The preset channel collaboration node is a node used to maintain a distributed database in the blockchain system, and a preset channel collaboration 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 collaboration node corresponding to the consensus cluster, and each preset channel collaboration node can store the distributed database belonging to In the sub-database of the preset channel cooperative node, the method for each preset channel cooperative node to find the target channel cooperative node that stores the target channel information based on the distributed database can be implemented by the existing distributed database query method, that is, in the adjacent The preset channel coordination node corresponding to the consensus cluster forwards the address query request, so that the preset channel coordination node that receives the address query request queries the target channel information in the locally stored sub-database, so as to achieve the target channel coordination node For the query, I won’t repeat it here.

S740: If the address query request information also 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 the address query request information includes the node address. At this time, after the channel coordinating node has inquired about the cluster address corresponding to the target channel information, it 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 that the peer node is based on the target channel The cluster address corresponding to the information resends the transaction request to the correct consensus cluster.

In this way, the channel cooperation 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 cross-consensus cluster transaction requests, the cluster address of the consensus cluster corresponding to the transaction request can be queried through the channel collaboration node, so as to ensure the orderly progress of cross-consensus cluster transaction requests and improve the performance of the blockchain system. reliability.

The specific implementation of 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 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 multiple 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 collaboration nodes, query the target channel collaboration node that stores the target hash value, where the preset channel collaboration node is used to maintain the distributed hash in the blockchain system Table node, a preset channel collaboration node corresponds to a consensus cluster;

The cluster address of the consensus cluster corresponding to the target channel cooperative node is used 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, the attribute information of the channel can be used to generate the hash value corresponding to the channel, and then the hash value corresponding to the channel is sent to The preset channel collaboration node corresponding to the consensus cluster, and the preset channel collaboration node will store the received hash value as the second hash value in the distributed hash table.

Each preset channel collaboration node can store a hash sub-table belonging to the preset channel collaboration node in the distributed hash table, and each preset channel collaboration node searches for the target channel collaboration that stores the target channel information based on the distributed hash table. The node method can be realized 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 that the preset channel cooperation node that received the address query request parses the target hash value in the address query request, and then compares the parsed target hash value with each second hash in the locally stored hash sub-table The value is compared to determine whether the target hash value exists in the locally stored hash sub-table. If it exists in the locally stored hash sub-table, the preset channel coordination node can determine that it is the target channel coordination node, and The cluster address of its 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. 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 the embodiment of the present invention, the distributed hash table may be a distributed hash table based on the Kademlia protocol, or a distributed hash table based on other protocols, which is not limited here.

Channel name, channel creator, channel creation time.

Among them, the attribute information has been described above, and will not be repeated here.

The above is the specific implementation of S730.

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

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.

Specifically, the address query request may not be generated based on the node address, so that the address query request does not carry the node address, and the address query request information does not include the node address. At this point, after the channel cooperative node has inquired about the cluster address corresponding to the target channel information, it 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 corresponds to the target channel information The cluster address of is forwarded to the peer node that sends 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 cooperation 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 in 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 area A needs to distribute the products produced to the distribution company D in area C, and the goods need to be tracked on the blockchain. For the sake of generality, suppose that the consensus cluster allocated by the production enterprise A is the consensus cluster O1, and the channel E is first established through the consensus cluster O1. Thereafter, the distribution company B initiates a transaction request to join the channel E to the consensus cluster O2 assigned by the cluster scheduling node. Since the consensus cluster O2 does not contain channel E-related information and cannot process the transaction request, it sends an address query request to the channel cooperative node. The channel coordination node forwards the address query request between each channel coordination node in the channel coordination layer (eventually to the consensus cluster O1) and finds the cluster address of the consensus cluster O1 corresponding to the channel, and finally returns the corresponding cluster address to the distribution enterprise B, B Update the cluster address corresponding to channel E. After that, the production company A and the distribution company B can communicate normally based on the cluster address corresponding to the channel E to create a specific smart contract that meets the business needs and interests of both parties, and coordinate the supply chain traceability business.

In summary, the channel collaboration node can implement a channel-oriented consensus cluster dynamic switching mechanism, which can ensure the existence and circulation of blockchain transactions in any globally available consensus cluster based on multi-consensus cluster scheduling, and finally go on the chain. Ensure the security and completeness of the blockchain system.

FIG. 8 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. 8 may be executed by any peer node shown in FIG. 4. Among them, 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 position included in the routing request information of the consensus cluster routing request. And feedback the target cluster address corresponding to the target consensus cluster, where the available consensus cluster is the consensus cluster in the normal working state in the blockchain system;

S820: Receive the target cluster address fed back by the cluster scheduling node;

S830. 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 node positions, 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 parallel operations on a large number of peer nodes. Consensus improves the throughput of the blockchain system, which in turn can meet the demand for high throughput of the blockchain system.

In some embodiments of the present invention, in the case that the transaction request type of the transaction request is the first transaction type, the target consensus cluster may directly initiate a consensus 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 consensus method of the blockchain system may also include:

In the case that the transaction request type of the transaction request is not the first transaction type, receive the cluster address corresponding to the target channel information fed back by the target consensus cluster or channel collaboration 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.

In summary, the embodiments of the present invention can meet the high throughput requirements of the blockchain system when a large number of blockchain nodes are connected. Through the consensus architecture and consensus scheduling mechanism of multi-consensus clusters, the performance of the blockchain system can be parallelized. The increase in throughput greatly improves the throughput.

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

In some embodiments of the present invention, the device shown in FIG. 9 may be set in the cluster scheduling node shown in FIG. 4, and 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 a consensus cluster routing request sent by the target peer node;

The first parsing module 920 is configured to parse the consensus cluster routing request to obtain routing request information, where the routing request information includes the node location of the target peer node;

The first determination module 930 is used to determine the target consensus cluster in at least one available consensus cluster according to the position of the node, where 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 some embodiments of the present invention, the first determining module 930 is specifically configured to:

Obtain the cluster location of each available consensus cluster;

According to the node location and cluster location, determine the response time of each available consensus cluster to the target peer node;

The available consensus cluster with the shortest response time is taken as the target consensus cluster.

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

The first judgment module is used to judge whether the cluster performance parameters of the available consensus cluster with the shortest response time meet the first preset condition;

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

In the case that the cluster performance parameters do not meet the first preset condition, the available consensus cluster with the shortest response time is taken as the target consensus set.

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

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

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

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

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

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

The fourth parsing module is used to parse the cluster registration request to obtain cluster registration request information, where 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 is verified;

The first processing module is used to treat the consensus cluster as an available consensus cluster when it is monitored 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 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:

The information query module is used to query the target cluster configuration information corresponding to the target consensus cluster;

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 determining module 930 is also specifically used for:

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

In some embodiments of the present invention, the device 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.

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

The second receiving module 1010 is configured to receive a transaction request sent by a target peer node, where the target peer node sends the transaction request based on the target cluster address, and the target cluster address is in at least one available consensus cluster based on the node location of the target peer node Confirm that the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

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

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

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

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

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

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

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

The first obtaining module is used to obtain 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, where the target channel list is a channel list stored locally;

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

The first generation module is used to generate an address query request according to the target channel information when the target channel information is not queried;

The fifth sending module is used to send an address query request to the channel cooperation node, and the address query request is used to make the channel cooperation node query the cluster address corresponding to the target channel information.

The sixth receiving module is configured to receive the cluster address corresponding to the target channel information fed back by the channel cooperation node;

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

Channel name, channel creator, channel creation time.

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

In some embodiments of the present invention, the device shown in FIG. 11 may be set in any channel cooperation node shown in FIG. 4. Among them, the channel cooperation 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 an address query request sent by the target consensus cluster, and 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 configured to parse the address query request to obtain address query request information, where 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 also includes the node address.

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 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 multiple Two second hash values, each second hash value is generated according to the attribute information of a channel in the blockchain system;

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

Channel name, channel creator, channel creation time.

The seventh sending module is used 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 device of a blockchain system provided by another embodiment of the present invention.

In some embodiments of the present invention, the device shown in FIG. 12 may be set in any peer node shown in FIG. 4, and 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 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 in the process, and feed 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 of the blockchain system;

The fourth receiving module 1220 is configured to receive the target cluster address fed back by the cluster scheduling node;

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

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

Among them, 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 fed back by the target consensus cluster or the channel collaboration node when the transaction request type of the transaction request is not the first transaction type;

The eighth sending module is used 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. Among them, 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 1310, and the input device 1301 and the output device 1306 are connected to the bus 1310 through the input interface 1302 and the output interface 1305, respectively, and then connected to the blockchain The other components of the consensus device 1300 of the 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, the output information is temporarily or permanently stored in the memory 1304, and then the output information is transmitted to the output device 1306 through the output interface 1305; the output device 1306 outputs the output information to the outside of the consensus device 1300 of the blockchain system for users to use .

In other words, the consensus device of the blockchain system shown in FIG. 13 can also be implemented as including: a memory storing computer-executable instructions; and a processor, which can implement the present invention when executing computer-executable instructions The embodiment describes the consensus method and device of the blockchain system.

The embodiment of the present invention also provides a computer-readable storage medium on which computer program instructions are stored; 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 realized . Examples of computer-readable storage media include non-transitory computer-readable storage media, such as Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disks, or optical disks.

The functional blocks shown in the above structural block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, plug-ins, function cards, and so on. When implemented in software, the elements of the present invention are programs or code segments used to perform required tasks. The program or code segment may be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link through a data signal carried in a carrier wave. "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 Programmable Read-Only Memory (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, and radio frequency (Radio Frequency). , RF) link, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, and so on.

The various aspects of the present disclosure have been described above with reference to the flowcharts and/or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present invention. It should be understood that each block in the flowcharts and/or block diagrams and combinations of blocks in the flowcharts and/or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine that enables the execution of these instructions via the processor of the computer or other programmable data processing device Implementation of functions/actions specified in one or more blocks of the flowchart and/or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic array. It can also be understood that each block in the block diagram and/or flowchart and the combination of the blocks in the block diagram and/or flowchart can also be implemented by dedicated hardware that performs the specified function or action, or can be implemented by dedicated hardware and A combination of computer instructions.

It should also be noted that the specific embodiments of the present invention are described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be executed in the order in different embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The above are only specific implementations of the present invention. Those skilled in the art can clearly understand that for the convenience and conciseness of description, the specific working process of the above-described systems, modules and units can be referred to the foregoing method embodiments. The corresponding process in, I will not repeat it here. It should be understood that the protection scope of the present invention is not limited to this, and any person skilled in the art can easily think of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should cover Within the protection scope of the present invention.

Claims

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, where the routing request information includes the node location of the target peer node;

According to the position of the node, determine a target consensus cluster in at least one available consensus cluster, where the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

Send the target cluster address of the target consensus cluster 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 position of the node comprises:

Acquiring the cluster location of each of the available consensus clusters;

Determine the response time of each available consensus cluster 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 use of the available consensus cluster with the shortest response time as the target consensus cluster, the method further comprises:

Judging 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 as the target consensus cluster includes:

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 determining whether the cluster performance parameters of the available consensus cluster with the shortest response time satisfy a first preset condition, the method further comprises:

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.
The method according to claim 3, wherein the routing request information further includes a routing request type;

Wherein, the judging whether the cluster performance parameter of the available consensus cluster with the shortest response time meets the first preset condition includes:

In a case where the routing request type is the first routing type, it is determined 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 claims 3-5, wherein the judging whether the cluster performance parameter of the available consensus cluster with the shortest response time meets a first preset condition comprises:

Detecting whether the available consensus cluster with the shortest response time has a saturation status mark;

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 a case where it is detected 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 throughput in the cluster performance parameter is greater than or equal to a preset throughput threshold;

The first duration for which the throughput is greater than or equal to the preset throughput 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 a preset delay threshold;

The second period of time when the average transaction delay is greater than or equal to the preset delay threshold is greater than or equal to the second preset period of time.
The method according to claim 1, wherein, before determining a target consensus cluster 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;

Parse the cluster registration request to obtain cluster registration request information, where 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.
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 the target consensus cluster in at least one available consensus cluster according to the node location includes:

In the case where the node verification information is verified, the target consensus cluster is determined in at least one of the available consensus clusters according to the position of the node.
A consensus method for a blockchain system, including:

Receive a transaction request sent by a target peer node, where 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 cluster according to the node location of the target peer node Determine that 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, where the transaction request information includes transaction information;

Initiating a consensus regarding the transaction information;

If the consensus is successful, execute the transaction corresponding to the transaction information.
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:

In the case where 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 and obtaining transaction request information, the method further includes:

In the case that the transaction request type is not the first transaction type, acquiring the target channel information;

Query the target channel information in the target channel list, where the target channel list is a channel list stored locally;

Wherein, the initiating a consensus on the transaction information includes:

In the case where the target channel information is queried, a consensus is initiated for the transaction information.
The method according to claim 13, wherein, after the query of the target channel information in the target channel list, the method further comprises:

In the case where 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 a channel coordination node, where 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 sending the address query request to the channel cooperation node, the method further comprises:

Receiving the cluster address corresponding to the target channel information fed back by the channel cooperation node;

Sending the cluster address corresponding to the target channel information to the target peer node.
The method according to any one of claims 13-15, wherein the target channel information is a target hash value, and the target hash value is generated according to the attribute information of the target channel corresponding to the transaction request; the target The channel list is a target hash table, and 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:

Receiving an address query request sent by a target consensus cluster, the address query request being 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, where the address query request information includes the target channel information;

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

In the case that 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 the attribute information of the target channel corresponding to the transaction request; the distributed database includes distributed A hash table, the distributed hash table includes a plurality of second hash values, and each of the second hash values is generated according to attribute information of a channel in the blockchain system;

Wherein, in the distributed database, querying the cluster address corresponding to the target channel information includes:

Based on the distributed hash table, among multiple preset channel collaboration nodes, query the target channel collaboration node storing the target hash value, and the preset channel collaboration node is used in the blockchain system For the node that maintains the distributed hash table, one of the preset channel collaboration nodes corresponds to a consensus cluster;

The cluster address of the consensus cluster corresponding to the target channel collaboration 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 the position of the node included in the routing request information of the consensus cluster routing request in at least one available consensus cluster Target consensus cluster, and feed back the target cluster address corresponding to the target consensus cluster, wherein the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

Receiving the target cluster address fed back 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 sending a transaction request to the target consensus cluster based on the target cluster address, the method further includes:

In the case that the transaction request type of the transaction request is not the first transaction type, receiving the cluster address corresponding to the target channel information fed back by the target consensus cluster or channel collaboration 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;

The first parsing module is configured to parse the consensus cluster routing request to obtain routing request information, where the routing request information includes the node location of the target peer node;

The first determining module is configured to determine a target consensus cluster in at least one available consensus cluster according to the position of the node, where the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

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 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 based on the node location of the target peer node Determine in at least one available consensus cluster that the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

The second analysis module is used to analyze the transaction request to obtain transaction request information, where the transaction request information includes transaction information;

The information consensus module is used to initiate a 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 an address query request sent by a target consensus cluster, and 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 configured to parse the address query request to obtain address query request information, where 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 also includes the 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 node position included in the routing request information of the consensus cluster routing request, At least one available consensus cluster determines a target consensus cluster, and feeds back the target cluster address corresponding to the target consensus cluster, where the available consensus cluster is a consensus cluster in a normal working state in the blockchain system;

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, comprising: a processor and a memory storing computer program instructions, and the processor implements claims 1-10, claims 11-17, and claims when executing the computer program instructions The consensus method of the blockchain system described in any one of 18-21 or claims 22-23.
A computer-readable storage medium with computer program instructions stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, the realization of claims 1-10, 11-17, and 18- 21 or the consensus method of the blockchain system according to any one of claims 22-23.