Blockchain consensus method, device and system

Abstract

To provide a method for block chain consensus increasing consensus effectiveness, and an apparatus and a system for the method.SOLUTION: The method comprises the steps of: receiving, by a leader node in the same network as a client terminal, a piece of transaction information sent by the client terminal, and a piece of transaction information sent by at least one or more peer nodes; sending both pieces of the transaction information to a leader node in a previous-level network till priority of the previous-level network becomes the highest if transaction data in both pieces of the transaction information are consistent; generating, by the leader node in a highest-priority network, a piece of proposal information according to the received pieces of transaction information; and performing a consensus determination on the piece of proposal information based on a Byzantine fault-tolerant consensus mechanism; and sending the piece of proposal information to a leader node in a next-level network till the next-level network becomes the sub-network where the client terminal is located after success in the consensus determination.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain consensus method, apparatus and system. [Background technology]

[0002] With the rapid development of blockchain technology, more and more data begins to be stored and interacted with by blockchain. In the design of blockchain, the consensus mechanism has always been a technical difficulty, especially in a peer-to-peer network environment.

[0003] Consensus means that the participating nodes are in agreement, and in blockchain, it is mainly to ensure that the order of transaction requests is consistent. In terms of blockchain systems, peer-to-peer networks can be understood as public networks, and the currently common peer-to-peer network consensus solutions are Proof Of Work (POW) and Proof of Stake (POS).

[0004] In implementing the present invention, the inventors have found that the prior art has at least the following problems: it has relatively low performance, i.e., each block holds a very small amount of transactions, and the confirmation time for each transaction is very long; and it is energy consuming, i.e., the mining mechanism causes a huge waste of energy. Summary of the Invention [Problem to be solved by the invention]

[0005] In view of the above, embodiments of the present invention provide a blockchain consensus method, apparatus and system to solve the technical problems of long transaction confirmation time and small transaction volume held by blocks. [Means for solving the problem]

[0006] In order to achieve the above-mentioned objective, according to one aspect of an embodiment of the present invention, a blockchain consensus method applied to a leader node in the same network as a customer terminal is provided, comprising: receiving transaction information sent by the customer terminal and transaction information sent by the leader node and at least one peer node in the same network as the customer terminal, or receiving transaction information sent by at least two of the peer nodes; determining whether the received transaction information is consistent, and if so, sending the transaction information to a leader node in a previous level network.

[0007] According to another aspect of an embodiment of the present invention, a blockchain consensus method applied to a leader node in a top-priority network is further provided, the method including: generating proposal information according to received transaction information; making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism; and sending the proposal information to a leader node in a next-level network after passing the consensus decision.

[0008] According to another aspect of the embodiment of the present invention, a blockchain consensus method is further provided for a leader node in a medium-priority network, comprising: receiving proposal information sent by a leader node in a highest-priority network, and performing signature verification on the proposal information; and after passing the signature verification, writing transaction data in the proposal information into a block, adding a signature of the leader node to the proposal information, and sending the proposal information to peer nodes in the same network as the leader node and to leader nodes in a next-level network until the next-level network becomes the network in which the customer terminal is located.

[0009] Based on another aspect of an embodiment of the present invention, a blockchain consensus method applied to a peer node in the same network as a customer terminal is further provided, the method including the steps of receiving transaction information sent by the customer terminal and performing signature verification on the transaction information, and after the signature verification is passed, adding a signature of the peer node to the transaction information, and sending the transaction information to a leader node in the same network as the peer node.

[0010] According to another aspect of an embodiment of the present invention, a blockchain consensus device is provided, which is provided in a leader node in the same network as a customer terminal, comprising: a first receiving module for receiving transaction information sent by the customer terminal and transaction information sent by the leader node and at least one peer node in the same network as the customer terminal, or for receiving transaction information sent by at least two of the peer nodes; and a first transmitting module for determining whether the received transaction information matches, and if so, for transmitting the transaction information to a leader node in a previous level network.

[0011] According to another aspect of the embodiment of the present invention, there is further provided a blockchain consensus device, which is provided in a leader node in a highest priority network, comprising: a proposal module for generating proposal information according to received transaction information; a consensus module for making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism; and a second sending module for sending the proposal information to a leader node in a next level network after passing the consensus decision.

[0012] According to another aspect of the embodiment of the present invention, a blockchain consensus device is provided, which is provided in a leader node in a medium-priority network, further comprising: a second receiving module for receiving proposal information sent by a leader node in a highest-priority network and performing signature verification on the proposal information; and a writing module for writing transaction data in the proposal information into a block after passing the signature verification, attaching a signature of the leader node to the proposal information, and transmitting the proposal information to peer nodes in the same network as the leader node and leader nodes in a next-level network until the next-level network becomes the network in which the customer terminal is located.

[0013] Based on another aspect of an embodiment of the present invention, a blockchain consensus device is provided, further comprising: a third receiving module for receiving transaction information sent by the customer terminal and performing signature verification on the transaction information; and a third transmitting module for attaching a signature of the peer node to the transaction information after signature verification has passed, and transmitting the transaction information to a leader node in the same network as the peer node.

[0014] According to another aspect of an embodiment of the present invention, there is provided an electronic device further comprising one or more processors and a memory device for storing one or more programs, the one or more programs being executed by the one or more processors such that the one or more processors realize a method according to any of the above embodiments.

[0015] According to another aspect of the present invention, there is further provided a computer-readable medium having stored thereon a computer program which, when executed by a processor, implements the method according to any of the above embodiments.

[0016] According to another aspect of the embodiment of the present invention, a blockchain consensus method is further provided, the method including: a customer terminal transmitting transaction information to at least two nodes, including at least two of a leader node and a peer node, in a same network as the customer terminal; a leader node in the same network as the customer terminal receiving the transaction information transmitted by the customer terminal and the transaction information transmitted by at least one of the peer nodes, or receiving the transaction information transmitted by at least two of the peer nodes, and if transaction data in the transaction information are consistent, transmitting the transaction information to a leader node in a previous level network until the priority of the previous level network becomes the highest priority; a leader node in the highest priority network generating proposal information according to the received transaction information, performing a consensus judgment on the proposal information based on a Byzantine fault tolerant consensus mechanism, and transmitting the proposal information to a leader node in a next level network after passing the consensus judgment, until the next level network becomes a network in which the customer terminal is located.

[0017] According to another aspect of the embodiment of the present invention, there is provided a blockchain consensus system, comprising: a customer terminal for transmitting transaction information to at least two nodes, including at least two of a leader node and a peer node, in the same network as the customer terminal; a leader node in the same network as the customer terminal for receiving the transaction information transmitted by the customer terminal and the transaction information transmitted by at least one of the peer nodes, or for receiving the transaction information transmitted by at least two of the peer nodes, and if transaction data in the transaction information match, transmitting the transaction information to a leader node in a previous level network until the priority of the previous level network becomes the highest priority; and a leader node in a highest priority network for generating proposal information according to the received transaction information, performing a consensus judgment on the proposal information based on a Byzantine fault tolerant consensus mechanism, and transmitting the proposal information to a leader node in a next level network after passing the consensus judgment, until the next level network becomes a network in which the customer terminal is located. Effect of the Invention

[0018] The above-mentioned embodiment of the invention has the following advantages or beneficial effects: A consensus judgment is performed on the proposed information based on a Byzantine fault-tolerant consensus mechanism, and after passing the consensus judgment, the proposed information is sent to the leader node in the next-level network until the next-level network becomes the network where the customer terminal is located, thereby solving the technical problems of the long confirmation time and small transaction volume held by the block in the prior art. The embodiment of the present invention performs consensus based on a Byzantine fault-tolerant consensus mechanism under the premise that the consistency of data is guaranteed using a cryptographic algorithm in a peer-to-peer network environment, and can improve the consensus efficiency. In the actual consensus process, a consensus mechanism within a hierarchical domain is used to achieve consensus within a small range, and the propagation method is very compatible with peer-to-peer networks, while on the other hand, it can reduce the waste of resources caused by mining and improve the consensus efficiency.

[0019] Further advantages of the above unconventional optional scheme will be described below in conjunction with the detailed description of the invention. [Brief description of the drawings]

[0020] The drawings are intended to facilitate a better understanding of the invention and are not intended to limit the invention. [Figure 1] FIG. 1 is a block diagram of a blockchain consensus system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a schematic diagram of the main flow of a blockchain consensus method according to one embodiment of the present invention. [Diagram 3] FIG. 3 is a schematic diagram of suggestion information according to an embodiment of the present invention. [Figure 4] FIG. 4 is a schematic diagram of the main flow of a blockchain consensus method according to another embodiment of the present invention. [Diagram 5]FIG. 5 is a schematic diagram of the main flow of a blockchain consensus method according to another embodiment of the present invention. [Figure 6] FIG. 6 is a schematic diagram of the main flow of a blockchain consensus method based on one possible embodiment of the present invention. [Figure 7] FIG. 7 is a schematic diagram of the main modules of a blockchain consensus device according to one embodiment of the present invention. [Figure 8] FIG. 8 is a schematic diagram of the main modules of a blockchain consensus device based on another embodiment of the present invention. [Figure 9] FIG. 9 is an exemplary system architecture diagram to which an embodiment of the present invention may be applied. [Figure 10] FIG. 10 is a structural schematic diagram of a computer system suitable for implementing a terminal or server according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] In the following, exemplary embodiments of the present invention will be described in conjunction with the drawings. Although the detailed description of the embodiments of the present invention is included for easy understanding, it should be understood that these are only exemplary. Therefore, it should be understood that those skilled in the art can make various changes and modifications to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, in the following description, descriptions of known functions and structures are omitted.

[0022] FIG. 1 is a block diagram of a blockchain consensus system according to an embodiment of the present invention. As shown in FIG. 1, a peer-to-peer network (i.e., a public network) includes multiple subnetworks, each of which has a different priority. FIG. 1 exemplarily illustrates a three-layer subnetwork, where, for example, the priority of subnetwork A is higher than the priority of subnetwork B, and the priority of subnetwork B is higher than the priority of subnetwork C. Since the network range to which the blockchain is applied is different, the number of priorities of each subnetwork is not limited to the three layers shown in FIG. 1, and may be more or less layers, and there may be multiple subnetworks with the same priority, and this point is not particularly limited in the embodiment of the present invention. The Internet, which is a public network, is a collection of computer networks formed by connecting computer networks (including local area networks and metropolitan area networks) at different locations and scales all over the world together. In the embodiment of the present invention, the subnetwork may be a local area network, a metropolitan area network, or the like.

[0023] In an embodiment of the present invention, each sub-network has one leader node and multiple peer nodes, and both the peer node and the leader node can receive transaction information sent from a customer terminal. The leader nodes are hierarchical, and the lower-level leader nodes can know the upper-level leader nodes, and the upper-level leader nodes can know the lower-level leader node set, and each leader node can know all the peer nodes in the same sub-network, and each peer node can know other peer nodes in the same sub-network and the leader nodes in the same sub-network. Therefore, the priority of the sub-network to which a leader node joins determines the priority of the leader node.

[0024] For example, in a local area network environment, if only one node can communicate with an external network, this node becomes the leader node of the local area network, and the other nodes in the local area network become peer nodes, and the status of each peer node is equal.

[0025] Once a leader node is formed, it does not remain the same, and if a peer node detects an abnormality in the leader node in the current network environment, it can re-select it using the Raft algorithm, etc., but the leader nominated as a candidate during the selection process must have the network authority to access the higher-level leader. If a leader node detects an abnormality in the parent leader node corresponding to the node (for example, the network is not connected), it can propagate by connecting to the surrounding network, and after other leader nodes in the surrounding network receive it, they send a response, and the leader node immediately changes the corresponding parent leader node.

[0026] 2 is a schematic diagram of the main flow of a blockchain consensus method according to an embodiment of the present invention. As shown in FIG. 2, in one embodiment of the present invention, the blockchain consensus method can include the following steps:

[0027] A client terminal transmits transaction information to at least two nodes in the same network as the client terminal, step 201.

[0028] After ensuring the legitimacy of the transaction information, the customer terminal transmits the transaction information to at least two nodes (which may be peer nodes or leader nodes) in the same network as the customer terminal, to prevent a single node from cheating. Specifically, the customer terminal may transmit the transaction information to a leader node and at least one peer node, or may transmit the transaction information to at least two peer nodes. In addition, the customer terminal can only transmit the transaction information to nodes that have already established a connection with the customer terminal.

[0029] As shown in FIG. 1, assuming that a customer terminal is in a subnetwork C, the customer terminal transmits transaction information to at least two nodes in the subnetwork C, such as Peer 31, Peer 32, and Peer 33 in the subnetwork C, or Leader 30, Peer 31, Peer 32, and Peer 34 in the subnetwork C.

[0030] Optionally, the transaction information includes transaction data and a signature of the customer terminal. The transaction data may be processed using a cryptographic algorithm to ensure data integrity. Specifically, the transaction data is first hashed, and then the hash value is processed using the private key of the customer terminal to obtain the signature of the customer terminal. If the public key of the customer terminal has not been propagated to each node in advance, the transaction information should further include the public key of the customer terminal so that the nodes can verify the signature of the customer terminal.

[0031] A leader node in the same network as the customer terminal receives the transaction information sent by the customer terminal and the transaction information sent by at least one of the peer nodes, or receives the transaction information sent by at least two of the peer nodes, and if the transaction data in the transaction information match, sends the transaction information to a leader node in a previous level network until the priority of the previous level network becomes the highest priority (step 202).

[0032] Optionally, the step of a leader node in the same network as the customer terminal receiving the transaction information sent by the customer terminal and the transaction information sent by at least one of the peer nodes, or receiving the transaction information sent by at least two of the peer nodes, includes: a peer node in the same network as the customer terminal receiving the transaction information sent by the customer terminal, performing signature verification thereon, and after signature verification has passed, attaching a signature of the peer node to the transaction information, and sending the transaction information to a leader node in the same network as the peer node, or a leader node in the same network as the customer terminal receiving the transaction information sent by the customer terminal and the transaction information sent by at least one of the peer nodes, and performing signature verification thereon, respectively, or receiving transaction information sent by at least two of the peer nodes, and performing signature verification thereon, respectively.

[0033] In step 201, the customer terminal sends transaction information to the peer node. After the peer node receives the transaction information sent by the customer terminal, it verifies the customer terminal signature using the customer terminal public key. Specifically, it performs hash processing on the transaction data in the transaction information, and compares whether the hash value matches the signature after unlocking using the public key. If the signature verification is passed, it adds the signature of the peer node to the transaction information, and sends the transaction information after adding the signature of the peer node to the leader node in the same network as the peer node. Therefore, the leader node receives the transaction information sent by the peer node (transferred by one or more peer nodes) and may also receive the transaction information sent by the customer terminal, that is, the leader node receives at least two pieces of transaction information.

[0034] When the leader node receives transaction information sent by a peer node, it first verifies the signature of the peer node, and after signature verification has passed, it performs signature verification on the signature of the customer terminal to obtain the transaction data. The first signature verification is to verify that the transaction information transferred by the peer node has not been tampered with during transmission over the network and to ensure the authenticity of the transaction information transferred by the peer node, and the second signature verification is to verify that the transaction data in the transaction information is the transaction data sent by the customer terminal. When the leader node receives transaction information sent by a customer terminal, it verifies only the signature of the customer terminal to obtain the transaction data.

[0035] If it is determined that the transaction data in the transaction information matches, the leader node will determine whether it has a parent leader, and if it assumes that a parent leader exists, it will add its own signature to the transaction information and send it to the parent leader, which will then perform the same operation (including signature verification and signature assignment) until the current leader node becomes the top-level leader after receiving the information. The leader node can verify each piece of transaction information to ensure the consistency of the transaction data. Note that the parent leader must verify each signature in the transaction information in order to ensure that the transaction data sent by the customer terminal has not been tampered with.

[0036] Optionally, if the transaction data in the transaction information are consistent, the step of sending the transaction information to a leader node in a previous level network until the priority of the previous level network is the highest includes: a leader node in the same network as the customer terminal judges whether the transaction data in each received transaction information is consistent based on the majority rule, and if consistent, attaches a signature of the leader node to the transaction information, sends the transaction information to a leader node in the previous level network, performs signature verification on the transaction information received by the leader node in the previous level network, and after passing the signature verification, adds a signature of the leader node to the transaction information, and sends the transaction information to a leader node in the previous level network until the priority of the previous level network is the highest. The leader node obtains the transaction data in each transaction information by signature verification, and judges whether the transaction data in each transaction information is consistent, for example, can judge whether the received multiple transaction data are consistent based on the majority rule. If it is confirmed that the transaction data are consistent, the transaction information that is confirmed not to have been tampered with is packed into one transaction information, and then sent to a parent leader after being attached with a signature of the leader node.

[0037] Step 303: the leader node in the highest priority network generates proposal information according to the received transaction information, performs a consensus decision on the proposal information based on a Byzantine Fault Tolerant consensus mechanism (BFT), and after passing the consensus decision, sends the proposal information to a leader node in a next level network until the next level network becomes the network in which the customer terminal is located.

[0038] Since the leader node constantly transmits transaction information to the leader node in the highest priority network, the leader node in the highest priority network can generate proposal information including a data list, the present consensus identifier, the leader node identifier in the highest priority network, and the signature of the leader node in the highest priority network according to transaction information received within a period or a certain number of transaction information. As shown in FIG. 3. Each transaction data in the data list is arranged in order of transaction time, that is, it is data to be written into a block. For example, when the number of transaction information received by the leader node in the highest priority network reaches 100, the 100 transaction information is packed, or counting from the first transaction information received, the transaction information received within 2 seconds is packed into the proposal information. Here, the default generation method of the present consensus identifier (CID) is auto-increment.

[0039] The transaction information sent from the lower-level leader node has a multi-layer signature, and the leader node in the highest-priority network can verify the accuracy of the transaction data only by signature verification, and after passing the signature verification, it will be packed into the proposal information.

[0040] When the leader node in the highest priority network changes, the new leader node will assign a new number and add its own signature, which will then be propagated to the peer nodes and lower-level leader nodes in the same network. There are many reasons why the leader node changes, such as: the leader node itself abnormally exits (other nodes detect the leader node's stoppage), or there is a problem with the data sent by the leader node (of course, such a problem does not necessarily have to be a problem with the leader node, but may be a problem in the transmission process). In either case, the leader node will be deemed by other peer nodes as not being sufficiently secure, prompting them to trigger a re-election of the leader node.

[0041] Optionally, the leader node identifier in the highest priority network can be the ID or IP of the leader node. However, since IP has a problem of duplication, the ID is generally selected as the leader node identifier to ensure the uniqueness of the identifier. The proposed information can further carry the public key of the current node (i.e., the leader node in the highest priority network). It is freely determined whether to carry the public key, because the public key itself is public. It may be provided through prior negotiation or carried in the information, and the embodiment of the present invention is not particularly limited in this respect.

[0042] Optionally, the step of making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism includes: a leader node in the highest priority network sends the proposal information to itself and a peer node in the highest priority network, the leader node and the peer node receive the proposal information, and respectively make a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism. As shown in Fig. 1, Leader00 in the highest priority network sends proposal information to Peer01, Peer02, Peer03, Peer04 and Leader00 itself in the same network, and Peer01, Peer02, Peer03, Peer04 and Leader00 make a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism.

[0043] Optionally, the step of making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism includes: performing signature verification on the proposal information; generating write information including the present consensus identifier and a signature according to the proposal information after the verification is passed; propagating the write information to all nodes in the current network; performing signature verification and consensus rule decision on the received write information; generating accept information including the present consensus identifier and a signature according to the write information after the verification is passed; propagating the accept information to all nodes in the current network; and performing signature verification and consensus rule decision on the received accept information.

[0044] Both the peer node and the leader node perform signature verification and CID order check for the received proposal information, and after passing the verification, propagate the write information to other nodes in the same network and the current node itself. The write information does not need to include specific information content, but only needs to have a CID and a signature. It is possible to freely decide whether to carry a public key or not, because the public key itself is public. It may be provided through prior consultation or carried in the information, and this point is not particularly limited in the embodiment of the present invention. After the other nodes in the same network and the current node receive the write information, they verify the write information and make a consensus rule decision. Specifically, the consensus can be reached using the principle N≧3f+1, where N is the total number of nodes and f is the number of malicious nodes. For example, if four nodes are involved in the consensus, one node abnormality (f is the malicious number) is allowed, and if there are seven nodes, two node abnormalities are allowed.

[0045] After passing the judgment, the Accept information is generated and the signature of the current node is added, and then the Accept information is propagated to other nodes in the same network and the current node itself. Similarly, the Accept information and the Write information only require the CID and the signature. It is possible to freely decide whether to carry the public key or not, because the public key itself is public. It may be provided in advance through negotiation or carried in the information, and there is no particular limitation on this point in the embodiment of the present invention. After the other nodes in the same network and the current node receive the Accept information, they verify the Accept information and make a consensus rule judgment (for example, N≧3f+1). If the judgment is passed, it means that the consensus is successful, and the transaction data in the proposed information can be written into the block.

[0046] The step of sending the proposal information to a leader node in a next level network until the next level network is a network where the customer terminal is located includes: a leader node in the highest priority network sends the proposal information to a leader node in a next level network; a leader node in the next level network receives the proposal information, performs signature verification on the proposal information, and writes transaction data in the proposal information into a block after signature verification is passed, and adds a signature of the leader node to the proposal information; and sends the proposal information to peer nodes in the same network as the leader node and to leader nodes in the next level network until the next level network is a network where the customer terminal is located; a peer node in the same network as the leader node receives the proposal information sent by the leader node, performs signature verification on the proposal information, and writes transaction data in the proposal information into a block after signature verification is passed.

[0047] The proposal information sent from the upper-layer leader node has a multi-layer signature, and the peer nodes and lower-layer leader nodes in the same network as the upper-layer leader node can determine the accuracy of the transaction data only by signature verification, and write the transaction data into a block after passing the signature verification. In an embodiment of the present invention, the lower-layer leader node needs to sign the proposal information of this consensus, and then propagate the signed proposal information to the peer nodes and lower-layer leader nodes in the same network, until it reaches the network where the customer terminal is located (i.e., the lowest-layer network).

[0048] Optionally, after step 303, the method may further include: at least two nodes in the same network as the client terminal and having a connection established with the client terminal receive the proposal information, perform signature verification on the proposal information, and after passing the signature verification, write transaction data in the proposal information into a block, and send response information to the client terminal.

[0049] As described in step 301, after ensuring the legitimacy of the transaction information, the customer terminal sends the transaction information to at least two nodes (which may be peer nodes or leader nodes) in the same network as the customer terminal to prevent a single node from cheating. Therefore, after passing the signature verification, at least two nodes (which may be peer nodes or leader nodes) in the same network as the customer terminal and which have a connection with the customer terminal not only write the transaction data into a block, but also send response information to the customer terminal. Each peer node does not know whether other peer nodes respond to the customer terminal, and each peer node which has a connection with the customer terminal can respond to the customer terminal.

[0050] The Byzantine Fault Tolerant consensus mechanism (BFT) has the advantages of low energy consumption, relatively large throughput, and short confirmation time. In the embodiment of the present invention, BFT is combined with a peer-to-peer network to realize the consensus of the entire blockchain system in the peer-to-peer network environment, thereby improving the consensus efficiency and reducing costs.

[0051] As can be seen from the above embodiments, the present invention adopts a technical means of performing a consensus judgment on the proposed information based on a Byzantine fault-tolerant consensus mechanism, and after passing the consensus judgment, transmitting the proposed information to the leader node in the next level network until the next level network becomes the network where the customer terminal is located, thereby solving the technical problems of the long confirmation time and small transaction volume held by the block in the prior art. The embodiment of the present invention performs consensus based on a Byzantine fault-tolerant consensus mechanism on the premise that the consistency of data is guaranteed using a cryptographic algorithm in a peer-to-peer network environment, and can improve the consensus efficiency. In the actual consensus process, a consensus mechanism within a layer structure is used to achieve consensus within a small range, and the propagation method is very compatible with peer-to-peer networks, while on the other hand, it can reduce the waste of resources caused by mining and improve the consensus efficiency.

[0052] 4 is a schematic diagram of the main flow of a blockchain consensus method according to another embodiment of the present invention. The blockchain consensus method applied to a leader node in the same network as a customer terminal includes the steps of: receiving transaction information sent by the customer terminal and the leader node, transaction information sent by at least one of the peer nodes in the same network as the customer terminal, or receiving transaction information sent by at least two of the peer nodes; and determining whether the received transaction information is consistent, and if so, sending the transaction information to a leader node in a previous level network.

[0053] After ensuring the legitimacy of the transaction information, the customer terminal transmits the transaction information to at least two nodes (which may be peer nodes or leader nodes) in the same network as the customer terminal, to prevent a single node from cheating. Specifically, the customer terminal may transmit the transaction information to a leader node and at least one peer node, or transmit the transaction information to at least two peer nodes.

[0054] Optionally, the transaction information includes transaction data and a signature of the customer terminal. The transaction data may be processed using a cryptographic algorithm to ensure data consistency. Optionally, step 401 includes receiving transaction information sent by the customer terminal and transaction information sent by at least one peer node, and performing signature verification on them respectively, or receiving transaction information sent by at least two peer nodes, and performing signature verification on them respectively, where the transaction information sent by the peer node includes the transaction information sent by the customer terminal and the signature of the peer node. In step 201, the customer terminal sends the transaction information to the peer node, and after receiving the transaction information sent by the customer terminal, the peer node verifies the customer terminal signature by the customer terminal public key. Specifically, the transaction data in the transaction information is hashed, and the hash value is compared with the signature after unlocking by the public key to see if it is consistent. If the signature verification is passed, the signature of the peer node is added to the transaction information, and the transaction information after the signature of the peer node is added is sent to a leader node in the same network as the peer node. Therefore, a leader node may receive transaction information sent by a peer node (forwarded by one or more peer nodes) and may also receive transaction information sent by a customer terminal, i.e., a leader node receives at least two pieces of transaction information. When a leader node receives transaction information sent by a peer node, it first verifies the signature of the peer node, and after signature verification has passed, it performs signature verification on the signature of the customer terminal to obtain the transaction data. The first signature verification is to verify that the transaction information forwarded by the peer node has not been tampered with during network transmission and to ensure the authenticity of the transaction information forwarded by the peer node, and the second signature verification is to verify that the transaction data in the transaction information is the transaction data sent by the customer terminal. When a leader node receives transaction information sent by a customer terminal, it verifies only the signature of the customer terminal to obtain the transaction data.

[0055] Optionally, step 402 includes judging whether the transaction data in each received transaction information is consistent based on the majority rule, and if so, adding the signature of the leader node to the transaction information, and sending the transaction information to a leader node in the previous level network. If it is determined that the transaction data in the transaction information is consistent, the leader node judges whether it has a parent leader, and if it assumes that a parent leader exists, it adds its own signature to the transaction information and sends it to the parent leader, and after the parent leader also receives the information, it operates in the same way (including signature verification and signature addition) until the current leader node becomes the top-level leader. The leader node can verify each transaction information to ensure the consistency of the transaction data.

[0056] 5 is a schematic diagram of a main flow of a blockchain consensus method according to another embodiment of the present invention. The blockchain consensus method applied to a leader node in a top-priority network includes the steps of: generating proposal information according to received transaction information in step 501; making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism in step 502; and sending the proposal information to a leader node in a next-level network after passing the consensus decision in step 503.

[0057] The leader node constantly transmits transaction information to the leader node in the highest priority network, and the leader node in the highest priority network can generate proposal information including a data list, the consensus identifier, a leader node identifier in the highest priority network, and a signature of the leader node in the highest priority network according to transaction information received within a period or a certain number of transaction information.

[0058] Optionally, the step of making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism includes transmitting the proposal information to the leader node itself and to peer nodes in the highest priority network, receiving the proposal information, and making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism.

[0059] Optionally, the step of performing consensus judgment on the proposal information based on a Byzantine fault-tolerant consensus mechanism includes: performing signature verification on the proposal information, generating write information including the present consensus identifier and a signature according to the proposal information after the verification is passed, propagating the write information to all nodes in the current network, performing signature verification and consensus rule judgment on the received write information, generating received information including the present consensus identifier and a signature according to the write information after the verification is passed, propagating the received information to all nodes in the current network, and performing signature verification and consensus rule judgment on the received received information.

[0060] The present invention further provides a blockchain consensus method applied to a leader node in a medium-priority network, comprising the steps of receiving proposal information sent by a leader node in a highest-priority network, and performing signature verification on the proposal information; and after passing the signature verification, writing the transaction data in the proposal information into a block, adding the signature of the leader node to the proposal information, and sending the proposal information to peer nodes in the same network as the leader node and to leader nodes in a next-level network, until the next-level network becomes the network in which the customer terminal is located.

[0061] The present invention further provides a blockchain consensus method applied to a peer node in the same network as a customer terminal, comprising: receiving transaction information sent by the customer terminal, performing signature verification on the transaction information, and after passing the signature verification, adding a signature of the peer node to the transaction information, and sending the transaction information to a leader node in the same network as the peer node. Optionally, the method further comprises receiving proposal information, performing signature verification on the proposal information, and after passing the signature verification, writing the transaction data in the proposal information into a block, and sending response information to the customer terminal.

[0062] 6 is a schematic diagram of the main flow of a block chain consensus method according to one embodiment of the present invention. The entire process is described in detail below using an example with only two-layer leader nodes. The block chain consensus method can include the following steps:

[0063] A customer terminal transmits transaction information to the Peer11 node, the Peer12 node, the Peer14 node and the Leader10 node in the same network as the customer terminal (step 601).

[0064] Specifically, the client terminal first hash processes the transaction data, and then uses the client terminal private key to process the hash value to obtain the client terminal signature. If the client terminal public key has not been propagated to each node in advance, the client terminal public key must be further included in the transaction information so that the nodes can verify the client terminal signature.

[0065] Since the Peer11 node, Peer12 node, Peer14 node and Leader10 node are in the same network as the customer terminal and have established a connection with the customer terminal, after ensuring the legitimacy of the transaction information, the customer terminal propagates the transaction information, and the Peer11 node, Peer12 node, Peer14 node and Leader10 node respectively receive the transaction information.

[0066] In addition, in order to simplify the schematic diagram, Fig. 6 exemplarily shows the process of Peer11 node receiving transaction information. In addition, the customer terminal may transmit transaction information to Peer11 node, Peer12 node and Peer13 node, or to Peer12 node and Peer13 node, and the embodiment of the present invention is not particularly limited in this respect, and prevents a single node from cheating.

[0067] The Peer11 node receives the transaction information sent by the customer terminal, performs signature verification on it, and after passing the signature verification, attaches the signature of the Peer11 node to the transaction information and transmits the transaction information to the Leader10 node in step 602. The signature verification and signing process of the Peer12 node and the Peer14 node is the same as that of the Peer11 node, so it will not be described repeatedly.

[0068] The Leader10 node receives the transaction information sent by the customer terminal and the transaction information sent by the Peer11 node, Peer12 node, and Peer14 node, performs signature verification on each of them, and after passing the signature verification, determines whether the transaction data in each received transaction information matches, and if they match, attaches the signature of the Leader10 node to the transaction information and sends the transaction information to the Leader00 node in the previous level network, step 603.

[0069] When the Leader 10 node receives transaction information sent by a peer node, it first verifies the signature of the peer node, and after signature verification has passed, it performs signature verification on the customer terminal signature to obtain the transaction data.

[0070] The Leader00 node generates proposal information according to the received transaction information, and transmits the proposal information to the Leader00 node, the Peer01 node, the Peer02 node, the Peer03 node, and the Peer04 node (step 604).

[0071] In order to simplify the schematic diagram, FIG. 6 only shows a Peer01 node and a Peer02 node as examples, and the execution process of each Peer node in the same network as the Leader00 node is similar, so it will not be described repeatedly.

[0072] The Leader00 node, Peer01 node, Peer02 node, Peer03 node, and Peer04 node perform signature verification on the proposal information, and after passing the verification, generate Write information according to the proposal information and propagate the Write information to all nodes in the current network (step 605).

[0073] Both the peer node and the leader node perform signature verification and CID sequence check on the received proposal information, and after passing the verification, propagate the write information to other nodes in the current network and the current node itself. The write information does not need to contain specific information content, only the CID and signature are required.

[0074] The Leader00 node, Peer01 node, Peer02 node, Peer03 node, and Peer04 node receive the Write information, perform signature verification and consensus rule judgment on the Write information, and after passing the judgment, generate Accept information according to the Write information and propagate the Accept information to all nodes in the current network (step 606).

[0075] Specifically, it mainly checks the order of CIDs, verifies the signature using a hash, and determines the consensus rule according to legal rules (the principle of N≧3f+1).

[0076] The Leader00 node, Peer01 node, Peer02 node, Peer03 node, and Peer04 node receive the Accept information, and perform signature verification and consensus rule judgment on the Accept information. If the judgment is passed, this consensus is deemed successful (step 607).

[0077] The Leader00 node writes the transaction data in the proposal information into a block, and after signing the proposal information, sends it to the Leader10 node in the next level network, and the Peer01 node, Peer02 node, Peer03 node, and Peer04 node write the transaction data in the proposal information into a block (step 608).

[0078] The Leader10 node receives the proposal information, performs signature verification on the proposal information, and after signature verification passes, writes the transaction data in the proposal information into a block, and after attaching the signature of the Leader10 node to the proposal information, propagates it to the Peer11 node, Peer12 node, Peer13 node, and Peer14 node (step 609).

[0079] The Peer11 node, the Peer12 node, the Peer13 node, and the Peer14 node receive the proposal information sent by the Leader10 node, perform signature verification on the proposal information, and after the signature verification has passed, write the transaction data in the proposal information into a block (step 610).

[0080] After passing the signature verification, the Peer11 node, the Peer12 node, the Peer14 node and the Leader10 node can further send response information to the customer terminal, step 611.

[0081] In addition, the specific implementation content of the blockchain consensus method in one referable embodiment of the present invention has already been described in detail in the above blockchain consensus method, so the overlapping content will not be described here.

[0082] Figure 7 is a schematic diagram of the main modules of a blockchain consensus apparatus according to one embodiment of the present invention. As shown in Figure 7, the blockchain consensus apparatus 700 is provided in a leader node in the same network as a customer terminal, and includes a first receiving module 701 for receiving transaction information sent by the customer terminal and transaction information sent by the leader node and at least one of the peer nodes in the same network as the customer terminal, or for receiving transaction information sent by at least two of the peer nodes, and a first sending module 702 for determining whether the received transaction information is consistent, and if so, for sending the transaction information to a leader node in a previous level network.

[0083] Optionally, the transaction information includes transaction data and a customer terminal signature; The step of receiving the transaction information transmitted by the client terminal and the transaction information transmitted by at least one peer node, or receiving the transaction information transmitted by at least two peer nodes, includes: receiving transaction information transmitted by a client terminal and at least one peer node and performing signature verification on each of the transaction information, or receiving transaction information transmitted by at least two peer nodes and performing signature verification on each of the transaction information, Here, the transaction information transmitted by the peer node includes the transaction information transmitted by the client terminal and the signature of the peer node.

[0084] Optionally, the step of determining whether the received transaction information matches, and if so, sending the transaction information to a leader node in a previous level network, comprises: Determine whether the transaction data in each received transaction information matches based on the majority rule; If there is a match, the transaction information is signed by the leader node and transmitted to a leader node in a previous level network.

[0085] Figure 8 is a schematic diagram of the main modules of a blockchain consensus apparatus according to another embodiment of the present invention. As shown in Figure 8, the blockchain consensus apparatus 800 is provided in a leader node in a top-priority network, and includes: a proposal module 801 for generating proposal information according to received transaction information, a consensus module 802 for making a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism, and a second sending module 803 for sending the proposal information to a leader node in a next-level network after passing the consensus decision.

[0086] Optionally, the step of generating the proposal information in response to the received transaction information comprises: The method includes generating proposal information including a data list, a consensus identifier, a leader node identifier in the highest priority network, and a signature of a leader node in the highest priority network in response to transaction information received within a preset period or a preset number of transaction information.

[0087] Optionally, the step of performing a consensus decision on the proposed information based on a Byzantine fault tolerant consensus mechanism comprises: transmitting the proposal information to itself and to peer nodes in the highest priority network; Receiving the proposal information and performing a consensus decision on the proposal information based on a Byzantine fault tolerant consensus mechanism.

[0088] Optionally, the step of performing a consensus decision on the proposed information based on a Byzantine fault tolerant consensus mechanism comprises: A signature verification is performed on the proposal information, and after the verification is passed, writing information including the consensus identifier and the signature is generated according to the proposal information; Propagating the write information to all nodes in the current network; Performing signature verification and consensus rule determination on the received writing information, and after passing the determination, generating received information including the consensus identifier and the signature according to the writing information; Propagating the received information to all nodes in the current network; This includes performing signature verification and consensus rule determination on the received information.

[0089] An embodiment of the present invention further provides a blockchain consensus device provided in a leader node in a medium-priority network, comprising: a second receiving module for receiving proposal information sent by a leader node in a highest-priority network and performing signature verification on the proposal information; and a writing module for writing transaction data in the proposal information into a block after passing signature verification, adding a signature of the leader node to the proposal information, and transmitting the proposal information to peer nodes in the same network as the leader node and leader nodes in a next-level network until the next-level network becomes the network in which the customer terminal is located.

[0090] Based on an embodiment of the present invention, a blockchain consensus device is further provided, which is provided in a peer node in the same network as a customer terminal, the device comprising: a third receiving module for receiving transaction information sent by the customer terminal and performing signature verification on the transaction information; and a third sending module for attaching a signature of the peer node to the transaction information after passing the signature verification, and sending the transaction information to a leader node in the same network as the peer node.

[0091] Optionally, the device further comprises a fourth receiving module for receiving proposal information, performing signature verification on the proposal information, and after passing the signature verification, writing transaction data in the proposal information into a block, and sending response information to the customer terminal.

[0092] The present invention further provides a blockchain consensus system, including: a customer terminal for transmitting transaction information to at least two nodes, including at least two of a leader node and a peer node, in the same network; a leader node in the same network as the customer terminal for receiving the transaction information transmitted by the customer terminal and the transaction information transmitted by at least one of the peer nodes, or for receiving the transaction information transmitted by at least two of the peer nodes, and if transaction data in the transaction information are consistent, transmitting the transaction information to a leader node in a previous level network until the priority of the previous level network becomes the highest priority; and a leader node in a highest priority network for generating proposal information according to the received transaction information, making a consensus judgment on the proposal information based on a Byzantine fault tolerant consensus mechanism, and transmitting the proposal information to a leader node in a next level network after passing the consensus judgment, until the next level network becomes the network in which the customer terminal is located.

[0093] Optionally, the transaction information includes transaction data and a customer terminal signature; The system further includes a peer node in the same network as the client terminal for receiving transaction information sent by the client terminal, performing signature verification thereon, and after passing the signature verification, adding a signature of the peer node to the transaction information, and sending the transaction information to a leader node in the same network as the peer node; or A leader node in the same network as the customer terminal is further configured to receive transaction information transmitted by the customer terminal and transaction information transmitted by at least one of the peer nodes and perform signature verification on each of them, or to receive transaction information transmitted by at least two of the peer nodes and perform signature verification on each of them.

[0094] Optionally, a leader node in the same network as the customer terminal is further configured to judge whether transaction data in each received transaction information matches based on majority rule, and if there is a match, to attach a signature of the leader node to the transaction information, and to transmit the transaction information to a leader node in a previous level network.

[0095] The system further includes a leader node in the previous level network for performing signature verification on the received transaction information, and after passing the signature verification, attaching a signature of the leader node to the transaction information, and transmitting the transaction information to a leader node in a previous level network until a priority of the previous level network becomes the highest priority.

[0096] Optionally, a leader node in said highest priority network further comprises: and generating proposal information including a data list, the present consensus identifier, a leader node identifier in the highest priority network, and a signature of a leader node in the highest priority network according to transaction information received within a preset period or a preset number of transaction information.

[0097] Optionally, said system further comprises a peer node in said highest priority network; a leader node in the highest priority network further configured to transmit the proposal information to itself and to peer nodes in the highest priority network; The leader node and the peer node are for receiving the proposal information and making a consensus decision on the proposal information respectively based on a Byzantine fault-tolerant consensus mechanism.

[0098] Optionally, the step of performing a consensus decision on the proposed information based on a Byzantine fault tolerant consensus mechanism comprises: A signature verification is performed on the proposal information, and after the verification is passed, writing information including the consensus identifier and the signature is generated according to the proposal information; Propagating the write information to all nodes in the current network; Performing signature verification and consensus rule determination on the received write information, and generating received information including the consensus identifier and the signature according to the write information after passing the determination; Propagating the received information to all nodes in the current network; This includes performing signature verification and consensus rule determination on the received information.

[0099] Optionally, a leader node in said highest priority network is further for transmitting said proposal information to a leader node in a next level network; a leader node in the next level network further for receiving the proposal information, performing signature verification on the proposal information, and writing the transaction data in the proposal information into a block after passing the signature verification, attaching a signature of the leader node to the proposal information, and transmitting the proposal information to peer nodes in the same network as the leader node and to leader nodes in the next level network until the next level network becomes a network in which the customer terminal is located; A peer node in the same network as the leader node receives the proposal information sent by the leader node, performs signature verification on the proposal information, and after the signature verification passes, writes the transaction data in the proposal information into a block.

[0100] Optionally, at least two nodes in the same network as the client terminal and having a connection established with the client terminal are further configured to receive the proposal information, perform signature verification on the proposal information, and after passing the signature verification, write transaction data in the proposal information into a block, and send response information to the client terminal.

[0101] As can be seen from the above embodiments, the present invention adopts a technical means of performing a consensus judgment on the proposed information based on a Byzantine fault-tolerant consensus mechanism, and after passing the consensus judgment, transmitting the proposed information to the leader node in the next level network until the next level network becomes the network where the customer terminal is located, thereby solving the technical problems of the long confirmation time and small transaction volume held by the block in the prior art. The embodiment of the present invention performs consensus based on a Byzantine fault-tolerant consensus mechanism on the premise that the consistency of data is guaranteed using a cryptographic algorithm in a peer-to-peer network environment, and can improve the consensus efficiency. In the actual consensus process, a consensus mechanism within a layer structure is used to achieve consensus within a small range, and the propagation method is very compatible with peer-to-peer networks, while on the other hand, it can reduce the waste of resources caused by mining and improve the consensus efficiency.

[0102] In addition, the specific implementation details of the blockchain consensus system of the present invention have already been described in detail in the blockchain consensus method described above, so the overlapping details will not be described here.

[0103] FIG. 9 illustrates an exemplary system architecture 900 of a blockchain consensus method or system to which embodiments of the present invention may be applied.

[0104] 9, the system architecture 900 can include terminal devices 901, 902, 903, a network 904, and a server 905. The network 904 is used as a medium to provide a communication link between the terminal devices 901, 902, 903, and the server 905. The network 904 can include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0105] Users can use terminal devices 901, 902, and 903 to interact with server 904 via network 904 to receive or transmit information, etc. Various communication customer terminal applications can be installed on terminal devices 901, 902, and 903, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox customer terminals, social platform software, etc. (some examples) can be installed.

[0106] The terminal devices 901, 902, 903 may be various electronic devices equipped with a display and supporting web browsing, including, but not limited to, smartphones, tablet computers, laptop computers, desktop computers, and the like.

[0107] The server 905 can be a server that provides various services, for example, a background management server (some examples) that provides support for shopping sites viewed on the user terminal devices 901, 902, and 903. The background management server can perform processing such as analysis on data such as received product information research requests, and feed back the processing results (for example, target push information, product information--some examples) to the terminal devices.

[0108] It should be understood that the number of terminal devices, networks and servers in FIG. 9 is merely schematic, and the system may have any number of terminal devices, networks and servers based on implementation requirements.

[0109] Reference is now made to Figure 10, which illustrates a structural schematic diagram of a computer system 1000 suitable for implementing the terminal device of the embodiment of the present invention. The terminal device illustrated in Figure 10 is merely an example, and does not limit the function and scope of use of the embodiment of the present invention.

[0110] 10, computer system 1000 includes a central processing unit (CPU) 1001, which can execute various suitable operations and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage portion 1008 into random access memory (RAM) 1003. RAM 1003 further stores various programs and data necessary for the operation of system 1000. CPU 1001, ROM 1002 and RAM 1003 are connected to each other via bus 1004. Input / output (I / O) interface 1005 is also connected to bus 1004.

[0111] The following components are connected to the I / O interface 1005: an input section 1006 such as a keyboard, a mouse, etc.; an output section 1007 such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1008 such as a hard disk, etc.; and a communication section 1009 such as a network interface card such as a LAN card, a modem, etc. The communication section 1009 executes communication processing via a network such as the Internet. A driver 1010 is also connected to the I / O interface 1005 as necessary. A removable medium 1011, for example, a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed in the driver 1010 as necessary so that a computer program read therefrom is installed in the storage section 1008 as necessary.

[0112] In particular, according to the embodiments disclosed in the present invention, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product including a computer program loaded on a computer readable medium, the computer program including program code for performing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication portion 1009 and / or installed from a removable medium 1011. When the computer program is executed by the central processing unit (CPU) 1001, the above functions defined in the system of the present invention are performed.

[0113] It should be noted that the computer readable medium described in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the above. The computer readable storage medium can be, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more conductors, a portable computer magnetic disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), a rewritable read-only memory (EPROM or flash memory), an optical fiber, a portable compact magnetic disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, the computer readable storage medium can be any tangible medium that contains or stores a program, which can be used by or in combination with a command execution system, apparatus, or device. Also, in this disclosure, the computer readable signal medium can be included in a data signal propagating in baseband or as part of a carrier wave, into which the computer readable program code is loaded. Such propagated data signals may take several forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may transmit, propagate, or transmit a program for use by or in connection with a command execution system, apparatus, or device. The program code contained in the computer-readable medium may be transmitted by any suitable medium, including, but not limited to, wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0114] The flowcharts and block diagrams in the drawings illustrate the architecture, functions, and operations that can be realized based on the systems, methods, and computer program products of the embodiments disclosed herein. In this regard, each block in the flowcharts or block diagrams can represent a module, program section, or part of code, which includes one or more executable commands for implementing a given logical function. It should be noted that in some alternative implementations, the functions noted in the blocks may occur in a different order than those noted in the drawings. For example, two consecutively shown blocks may in fact essentially be executed in parallel, and may even be executed in the opposite order, which may be determined based on the related functions. It should be noted that each block in the block diagrams or flowcharts, and combinations of blocks in the block diagrams or flowcharts, may be realized by a dedicated hardware-based system for performing a given function or operation, or by a combination of dedicated hardware and computer commands.

[0115] The relevant modules described in the embodiments of the present invention may be implemented in software or hardware. The described modules may be provided in a processor, for example, a processor including a first receiving module and a first transmitting module. The names of the modules, in some cases, are not intended to be limitations on the modules themselves.

[0116] In another aspect, the present invention further provides a computer readable medium, which may be included in the equipment described in the above embodiment or may exist independently, but is not attached to the equipment. The computer readable medium is loaded with one or more programs, and when the one or more programs are executed by one of the equipment, the equipment includes: receiving transaction information sent by the customer terminal and the leader node, transaction information sent by at least one of the peer nodes in the same network as the customer terminal, or receiving transaction information sent by at least two of the peer nodes, judging whether the received transaction information is consistent, and if so, sending the transaction information to a leader node in a previous level network.

[0117] According to the technical solution of the embodiment of the present invention, a technical means is adopted to perform a consensus judgment on the proposed information based on a Byzantine fault-tolerant consensus mechanism, and after passing the consensus judgment, the proposed information is sent to the leader node in the next level network until the next level network becomes the network where the customer terminal is located, thereby solving the technical problems of the long confirmation time and the small transaction volume held by the block in the prior art. In the embodiment of the present invention, on the premise that the consistency of data is guaranteed using a cryptographic algorithm in a peer-to-peer network environment, consensus is performed based on a Byzantine fault-tolerant consensus mechanism, which can improve the consensus efficiency. In the actual consensus process, a consensus mechanism within a layer structure is used to achieve consensus within a small range, and the propagation method is very compatible with peer-to-peer networks, while on the other hand, it can reduce the waste of resources caused by mining and improve the consensus efficiency.

[0118] The above-mentioned embodiment of the present invention does not limit the scope of protection of the present disclosure. It is obvious to those skilled in the art that various modifications, combinations, subcombinations and alternatives can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements made within the spirit and principle of the present invention should be understood to be included in the scope of protection of the present invention. [Item of invention] [Item 1] A blockchain consensus method applied to a leader node in the same network as a customer terminal, receiving transaction information transmitted by the client terminal and transaction information transmitted by the leader node and at least one peer node in the same network as the client terminal, or receiving transaction information transmitted by at least two of the peer nodes; determining whether the received transaction information matches, and if so, sending the transaction information to a leader node in a previous level network; Including, Blockchain consensus method. [Item 2] The transaction information includes transaction data and a customer terminal signature; The step of receiving transaction information transmitted by the client terminal and transaction information transmitted by at least one peer node, or receiving transaction information transmitted by at least two peer nodes, includes: receiving transaction information transmitted by a client terminal and at least one peer node and performing signature verification on each of the transaction information, or receiving transaction information transmitted by at least two peer nodes and performing signature verification on each of the transaction information, wherein the transaction information transmitted by the peer node includes the transaction information transmitted by the client terminal and a signature of the peer node; Item 1. The blockchain consensus method according to item 1. [Item 3] The step of determining whether the received transaction information matches, and if so, sending the transaction information to a leader node in a previous level network further includes: Determine whether the transaction data in each received transaction information matches based on the majority rule; If there is a match, attaching a signature of the leader node to the transaction information and transmitting the transaction information to a leader node in a previous level network. Item 1. The blockchain consensus method according to item 1. [Item 4] A blockchain consensus method applied to a leader node in a top priority network, comprising: generating proposal information in response to the received transaction information; performing a consensus decision on the proposed information based on a Byzantine fault tolerant consensus mechanism; After passing the consensus decision, sending the proposal information to a leader node in a next level network; Including, Blockchain consensus method. [Item 5] The step of generating proposal information in response to the received transaction information further comprises: generating proposal information, according to the transaction information received within a preset period or a preset number of transaction information, the proposal information including a data list, the consensus identifier, a leader node identifier in the highest priority network, and a signature of a leader node in the highest priority network; Item 4. The blockchain consensus method. [Item 6] The step of performing a consensus decision on the proposed information based on the Byzantine fault tolerant consensus mechanism further includes: transmitting the proposal information to itself and to peer nodes in the highest priority network; receiving the proposal information and performing a consensus decision on the proposal information based on a Byzantine fault tolerant consensus mechanism; Item 4. The blockchain consensus method. [Item 7] The step of performing a consensus decision on the proposed information based on the Byzantine fault tolerant consensus mechanism further includes: A signature verification is performed on the proposal information, and after the verification is passed, writing information including the consensus identifier and the signature is generated according to the proposal information; Propagating the write information to all nodes in the current network; Performing signature verification and consensus rule determination on the received writing information, and after passing the determination, generating received information including the consensus identifier and the signature according to the writing information; Propagating the received information to all nodes in the current network; and performing signature verification and consensus rule determination on the received information; Item 6. The blockchain consensus method according to item 6. [Item 8] A blockchain consensus method applied to a leader node in a medium priority network, comprising: receiving proposal information transmitted by a leader node in a highest priority network and performing signature verification on the proposal information; After passing signature verification, writing the transaction data in the proposal information into a block, attaching the signature of the leader node to the proposal information, and sending the proposal information to peer nodes in the same network as the leader node and to leader nodes in a next-level network until the next-level network is the network in which the customer terminal is located; Including, Blockchain consensus method. [Item 9] A blockchain consensus method applied to a peer node in the same network as a client terminal, receiving transaction information transmitted by the customer terminal and performing signature verification on the transaction information; After passing the signature verification, adding a signature of the peer node to the transaction information, and sending the transaction information to a leader node in the same network as the peer node; Including, Blockchain consensus method. [Item 10] receiving proposal information, performing signature verification on the proposal information, and after the signature verification is passed, writing transaction data in the proposal information into a block, and transmitting response information to the customer terminal; Item 9. The blockchain consensus method according to item 9. [Item 11] A blockchain consensus device provided in a leader node in the same network as a customer terminal, A first receiving module for receiving transaction information sent by the client terminal and transaction information sent by the leader node, at least one of the peer nodes in the same network as the client terminal, or for receiving transaction information sent by at least two of the peer nodes; a first sending module for determining whether the received transaction information is consistent, and if so, sending the transaction information to a leader node in a previous level network; Equipped with Blockchain consensus device. [Item 12] A blockchain consensus device provided in a leader node in a highest priority network, a proposal module for generating proposal information in response to the received transaction information; a consensus module for performing a consensus decision on the proposed information based on a Byzantine fault tolerant consensus mechanism; a second sending module for sending the proposal information to a leader node in a next level network after passing the consensus judgment; Equipped with Blockchain consensus device. [Item 13] A blockchain consensus device provided in a leader node in a medium priority network, A second receiving module for receiving proposal information sent by a leader node in a highest priority network and performing signature verification on the proposal information; a write module for writing transaction data in the proposal information into a block after passing signature verification, attaching a signature of the leader node to the proposal information, and transmitting the proposal information to peer nodes in the same network as the leader node and to leader nodes in a next-level network until the next-level network is a network in which the customer terminal is located; Equipped with Blockchain consensus device. [Item 14] A blockchain consensus device provided in a peer node in the same network as a customer terminal, a third receiving module for receiving the transaction information transmitted by the customer terminal and performing signature verification thereon; a third sending module for adding a signature of the peer node to the transaction information after passing signature verification, and sending the transaction information to a leader node in the same network as the peer node; Equipped with Blockchain consensus device. [Item 15] The client terminal transmits transaction information to at least two nodes in the same network as the client terminal, the at least two nodes including a leader node and a peer node; A leader node in the same network as the client terminal receives the transaction information sent by the client terminal and the transaction information sent by at least one of the peer nodes, or receives the transaction information sent by at least two of the peer nodes, and if the transaction data in the transaction information are consistent, transmits the transaction information to a leader node in a previous level network until the priority of the previous level network becomes the highest priority; A leader node in the highest priority network generates proposal information according to the received transaction information, performs a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism, and transmits the proposal information to a leader node in a next-level network after passing the consensus decision, until the next-level network is a network in which the customer terminal is located; Including, Blockchain consensus method. [Item 16] a client terminal for transmitting transaction information to at least two nodes, including at least two of a leader node and a peer node, in the same network; a leader node in the same network as the client terminal for receiving transaction information sent by the client terminal and transaction information sent by at least one of the peer nodes, or for receiving transaction information sent by at least two of the peer nodes, and if transaction data in the transaction information match, sending the transaction information to a leader node in a previous level network until the priority of the previous level network becomes the highest priority; a leader node in a highest priority network for generating proposal information according to received transaction information, performing a consensus decision on the proposal information based on a Byzantine fault tolerant consensus mechanism, and transmitting the proposal information to a leader node in a next level network after passing the consensus decision until the next level network becomes a network in which the customer terminal is located; Including, Blockchain consensus system. [Item 17] one or more processors; a storage device for storing one or more programs; Equipped with The one or more programs are executed by the one or more processors so that the one or more processors implement the method according to any one of items 1 to 10. electronic equipment. [Item 18] A computer-readable medium having a computer program stored thereon, When the program is executed by a processor, the method according to any one of items 1 to 10 is realized. Computer-readable medium. [Explanation of symbols]

[0119] A, B, C…Subnetworks 700, 800…Blockchain consensus device 701…First receiving module 702...first transmission module 801…Proposal module 802…Consensus module 803…Second transmitting module 900…System Architecture 901, 902, 903...User terminal device 904…Network 905...Server 1000…Computer systems 1001...Central processing unit 1002...Read-only memory, ROM 1008...Memory part 1003...Random access memory, RAM 1004…Bus 1005...Output interface, O interface 1006...Input section 1007...Output part 1009…Communication section 1010…Driver 1011…Removable media

Claims

1. A blockchain consensus method, comprising: Dividing the peer-to-peer network into multiple sub-networks having different priorities, where each sub-network includes multiple nodes, the multiple nodes including a leader node and at least one peer node capable of communicating with at least one external network; A leader node in the same network as the client terminal receives the transaction information transmitted by the client terminal and the transaction information transmitted by at least one peer node, or receives the transaction information transmitted by at least two of the peer nodes; Determine whether the received transaction information is consistent, and if so, transmit the transaction information to a leader node in an upper level sub-network until the upper level sub-network becomes the highest priority sub-network; a leader node in a highest-priority subnetwork generates proposal information according to the received transaction information, performs a consensus judgment on the proposal information based on a Byzantine fault-tolerant consensus mechanism, and transmits the proposal information to a leader node in a lower-level subnetwork after passing the consensus judgment, until the lower-level subnetwork becomes the subnetwork in which the customer terminal is located; Including, Blockchain consensus method.

2. The transaction information transmitted by the client terminal includes transaction data and a signature of the client terminal; The leader node in the same sub-network as the client terminal receives transaction information transmitted by the client terminal and transaction information transmitted by at least one peer node, or receives transaction information transmitted by at least two peer nodes. receiving transaction information transmitted by a client terminal and at least one peer node and performing signature verification on each of the transaction information, or receiving transaction information transmitted by at least two peer nodes and performing signature verification on each of the transaction information, wherein the transaction information transmitted by each peer node includes the transaction information transmitted by the client terminal and the signature of the peer node; The blockchain consensus method of claim 1.

3. A leader node in the same sub-network as the client terminal determines whether the transaction data in each transaction information matches based on the majority rule; If there is a match, attaching a signature of a leader node in the current sub-network to the transaction information and sending the transaction information to a leader node in a previous level sub-network. The blockchain consensus method of claim 1.

4. The leader node in the highest priority sub-network further comprises generating proposal information in response to the received transaction information. generating proposal information, according to the transaction information received within a preset period or a preset number of transaction information, the proposal information including a data list, the consensus identifier, a leader node identifier in the highest priority sub-network, and a signature of a leader node in the highest priority sub-network; The blockchain consensus method of claim 1.

5. The method of performing a consensus decision on the proposal information based on the Byzantine fault tolerant consensus mechanism further comprises: transmitting the proposal information to itself and to peer nodes in the highest priority sub-network; receiving the proposal information and performing a consensus decision on the proposal information based on a Byzantine fault tolerant consensus mechanism; The blockchain consensus method of claim 1.

6. The method of performing a consensus decision on the proposal information based on the Byzantine fault tolerant consensus mechanism further comprises: A signature verification is performed on the proposal information, and after the verification is passed, writing information including the consensus identifier and the signature is generated according to the proposal information; Propagating the write information to all nodes in the current highest priority sub-network; Performing signature verification and consensus rule determination on the received writing information, and after passing the determination, generating received information including the consensus identifier and the signature according to the writing information; Propagating the received information to all nodes in the current highest priority sub-network; and performing signature verification and consensus rule determination on the received information; The blockchain consensus method according to claim 5.

7. A medium-priority subnetwork among the plurality of subnetworks receives the proposal information transmitted by the leader node in the highest-priority subnetwork, and performs signature verification on the proposal information; writing the transaction data in the proposal information into a block after passing signature verification, attaching a signature of a leader node in the medium-priority sub-network to the proposal information, and transmitting the proposal information to peer nodes in the same sub-network as the leader node in the medium-priority sub-network and to leader nodes in a next-level sub-network until the next-level sub-network becomes the sub-network in which the customer terminal is located; Further comprising: The blockchain consensus method of claim 1.

8. A peer node in the same sub-network as the client terminal receives the transaction information sent by the client terminal and performs signature verification on the transaction information; After passing signature verification, adding a signature of the peer node to the transaction information, and sending the transaction information to a leader node in the same sub-network as the peer node; Further comprising: The blockchain consensus method of claim 1.

9. a peer node in the same sub-network as the client terminal receives proposal information, performs signature verification on the proposal information, and after the signature verification is passed, writes transaction data in the proposal information into a block and transmits response information to the client terminal; The blockchain consensus method of claim 1.

10. A blockchain consensus device, A partitioning module for partitioning a peer-to-peer network into a plurality of sub-networks having different priorities, each sub-network including a plurality of nodes, the plurality of nodes including a leader node and at least one peer node capable of communicating with at least one external network; a first receiving module in the same sub-network as a client terminal, for receiving transaction information transmitted by said client terminal and transaction information transmitted by at least one of said peer nodes, or for receiving transaction information transmitted by at least two of said peer nodes; a first transmitting module for determining whether the received transaction information matches, and if so, transmitting the transaction information to a leader node in a previous level network until the previous level sub-network becomes a highest priority sub-network; a proposal module for generating proposal information in response to the received transaction information in the highest priority sub-network; a consensus module for performing a consensus decision on the proposal information based on a Byzantine fault-tolerant consensus mechanism; a second sending module for sending the proposal information to a leader node in a next-level sub-network after passing a consensus decision until the next-level sub-network becomes a sub-network in which the customer terminal is located; Equipped with Blockchain consensus device.

11. A second receiving module for receiving proposal information transmitted by a leader node in a highest priority subnetwork in a medium priority subnetwork among the plurality of subnetworks, and performing signature verification on the proposal information; a write module for writing transaction data in the proposal information into a block after passing signature verification, attaching a signature of a leader node in the medium-priority sub-network to the proposal information, and transmitting the proposal information to peer nodes in the same sub-network as the leader node in the medium-priority sub-network and to leader nodes in a next-level sub-network until the next-level sub-network is the sub-network in which the customer terminal is located; Further comprising: The blockchain consensus apparatus of claim 10.

12. a third receiving module for receiving the transaction information transmitted by the client terminal in the same sub-network in which the client terminal is located and performing signature verification thereon; a third sending module for adding a signature of the peer node to the transaction information after passing signature verification, and sending the transaction information to a leader node in the same sub-network as the customer terminal; Further comprising: The blockchain consensus apparatus of claim 10.

13. A peer-to-peer network divided into a plurality of sub-networks having different priorities, each sub-network including a plurality of nodes, the plurality of nodes including a leader node and at least one peer node capable of communicating with at least one external network; a client terminal for transmitting transaction information to at least two nodes, including at least two of a leader node and a peer node, in a same sub-network; receiving transaction information transmitted by the client terminal and transaction information transmitted by at least one peer node, or receiving transaction information transmitted by at least two peer nodes; a leader node in the same sub-network as the client terminal for transmitting transaction information to a leader node in a previous level network if transaction data in the transaction information matches, until the previous level sub-network becomes a highest priority sub-network; a leader node in a highest priority sub-network for generating proposal information according to received transaction information, performing a consensus judgment on the proposal information based on a Byzantine fault-tolerant consensus mechanism, and transmitting the proposal information to a leader node in a next level sub-network after passing the consensus judgment, until the next level sub-network becomes a sub-network in which the customer terminal is located; Including, Blockchain consensus system.

14. one or more processors; a storage device for storing one or more programs; Equipped with said one or more programs being executed by said one or more processors such that said one or more processors implement the method according to any one of claims 1 to 9; electronic equipment.

15. A computer-readable storage medium having a computer program stored thereon, The method according to any one of claims 1 to 9 is achieved when the computer program is executed by a computer processor. A computer-readable storage medium.

Images