WO2020258912A1 - 一种区块链共识方法、装置和系统 - Google Patents

一种区块链共识方法、装置和系统 Download PDF

Info

Publication number
WO2020258912A1
WO2020258912A1 PCT/CN2020/077518 CN2020077518W WO2020258912A1 WO 2020258912 A1 WO2020258912 A1 WO 2020258912A1 CN 2020077518 W CN2020077518 W CN 2020077518W WO 2020258912 A1 WO2020258912 A1 WO 2020258912A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
transaction
network
node
client
Prior art date
Application number
PCT/CN2020/077518
Other languages
English (en)
French (fr)
Inventor
邵珠光
孙海波
赵光伟
黄海泉
张�林
Original Assignee
京东数字科技控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 京东数字科技控股有限公司 filed Critical 京东数字科技控股有限公司
Priority to US17/616,543 priority Critical patent/US20220239496A1/en
Priority to JP2021568814A priority patent/JP2022533396A/ja
Priority to KR1020217040523A priority patent/KR102566892B1/ko
Publication of WO2020258912A1 publication Critical patent/WO2020258912A1/zh
Priority to JP2023184790A priority patent/JP2024010123A/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1089—Hierarchical topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/44—Star or tree networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091—Interfacing with client-server systems or between P2P systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1093—Some peer nodes performing special functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • the present invention relates to the field of blockchain technology, and in particular to a blockchain consensus method, device and system.
  • Consensus means that the participating nodes are in the same state. In the blockchain, it is mainly to ensure that the order of requested transactions is globally consistent.
  • the peer-to-peer network can be understood as a public network.
  • common peer-to-peer network consensus solutions are Proof Of Work (POW) and Proof of Stake (POS).
  • the performance is low, the transaction volume carried by each block is small, and the confirmation time of each transaction is long; it consumes energy, and the use of mining mechanisms leads to a serious waste of energy.
  • the embodiments of the present invention provide a blockchain consensus method, device, and system to solve the technical problems of long transaction confirmation time and small transaction volume carried by the block.
  • a blockchain consensus method is provided, which is applied to a master node in the same network as a client, and includes: receiving transaction messages sent by the client and Transaction messages sent by at least one peer node, or transaction messages sent by at least two peer nodes are received; wherein, the peer node, the master node, and the client are all in the same network; it is determined that the received Whether the transaction messages are consistent with each other, if so, send the transaction message to the master node in the upper-level network.
  • a blockchain consensus method which is applied to the master node in the highest priority network.
  • the method includes: generating a proposal message according to the received transaction message;
  • the fault-tolerant consensus mechanism makes a consensus decision on the proposal message; after the consensus decision is passed, the proposal message is sent to the master node in the next-level network.
  • a blockchain consensus method is also provided, which is applied to a master node in a medium-priority network, and the method includes: receiving a proposal sent by a master node in the highest-priority network Message, the proposal message is verified; after the verification is passed, the transaction data in the proposal message is written into the block, and the signature of the master node is attached to the proposal message, and the proposal The message is sent to the peer node in the same network as the master node and the master node in the next level network; until the next level network is the network where the client is located.
  • a blockchain consensus method is also provided, which is applied to a peer node in the same network as a client, and the method includes: receiving a transaction message sent by the client , And verify it; after the verification is passed, attach the signature of the peer node to the transaction message, and send the transaction message to the master node in the same network as the peer node .
  • a blockchain consensus device which is set on a master node in the same network as a client, and the device includes: a first receiving module for receiving the client The transaction message sent by the peer node and the transaction message sent by at least one peer node, or the transaction message sent by at least two peer nodes are received; wherein, the peer node, the master node, and the client are all in the same In the network; the first sending module is used to determine whether the received transaction messages are consistent, and if so, send the transaction messages to the master node in the upper-level network.
  • a block chain consensus device which is set in the master node in the highest priority network, and the device includes: a proposal module for generating according to the received transaction message Proposal message; consensus module, used to make a consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism; the second sending module, used to send the proposal message to the master node in the next level network after the consensus decision is passed.
  • a blockchain consensus device which is set in a master node in a medium priority network, and the device includes: a second receiving module for receiving the highest priority network
  • the proposal message sent by the master node in the master node verifies the proposal message; the write module is used to write the transaction data in the proposal message into the block after the signature verification is passed, and write it on the proposal message Attach the signature of the master node, and send the proposal message to the peer node in the same network as the master node and the master node in the next level network; until the next level network is the client The network where the end is located.
  • a blockchain consensus device which is set on a peer node in the same network as the client.
  • the device includes: a third receiving module for receiving The transaction message sent by the client terminal and verify the signature; the third sending module is used to attach the signature of the peer node to the transaction message after the verification is passed, and send the transaction message To the master node in the same network as the peer node.
  • an electronic device including: one or more processors; a storage device, configured to store one or more programs, when the one or more programs are One or more processors execute, so that the one or more processors implement the method described in any of the foregoing embodiments.
  • a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, the method described in any of the above embodiments is implemented.
  • a blockchain consensus method including: a client sends a transaction message to at least two nodes in the same network as the client; wherein, the at least The two nodes include at least two of a master node and a peer node; the master node in the same network as the client receives the transaction message sent by the client and at least one transaction message sent by the peer node, Or, receiving transaction messages sent by at least two of the peer nodes; if the transaction data in the transaction messages are consistent, the transaction message is sent to the master node in the upper level network until the upper level network has priority The highest priority level is the highest; the master node in the highest priority network generates a proposal message based on the received transaction message, and performs a consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism; after the consensus decision is passed, the proposal message is sent to the next The master node in the first-level network until the next-level network is the network where the client is located.
  • a blockchain consensus system including: a client terminal, configured to send transaction messages to at least two nodes in the same network as the client terminal; wherein , The at least two nodes include at least two of a master node and a peer node; the master node in the same network as the client is used to receive a transaction message sent by the client and at least one of the pair The transaction message sent by the peer node, or the transaction message sent by at least two peer nodes is received; if the transaction data in the transaction message is consistent, the transaction message is sent to the master node in the upper-level network until all The priority of the upper-level network is the highest; the master node in the highest-priority network is used to generate proposal messages according to the received transaction messages, and make consensus judgments on the proposal messages based on the Byzantine fault-tolerant consensus mechanism; the consensus judgment passes After that, the proposal message is sent to the master node in the next level network until the next level network is the network where the client
  • An embodiment of the above-mentioned invention has the following advantages or beneficial effects: Because the consensus decision based on the Byzantine fault-tolerant consensus mechanism is adopted for the proposal message, after the consensus decision is passed, the proposal message is sent to the master node in the next level network until the next The level network is the technical means of the network where the client is located, so it overcomes the technical problems of long transaction confirmation time and small transaction volume carried by blocks in the prior art.
  • the embodiment of the present invention uses cryptographic algorithms to ensure data consistency in a peer-to-peer network environment, and consensus based on the Byzantine fault-tolerant consensus mechanism can effectively improve consensus efficiency; in the actual consensus process, a hierarchical regional consensus mechanism is adopted , Through the consensus reached in a small area, and the method of broadcasting, on the one hand, it is very compatible with the peer-to-peer network, on the other hand, it can reduce the waste of resources caused by mining, thereby effectively improving the efficiency of consensus.
  • Figure 1 is a framework diagram of a blockchain consensus system according to an embodiment of the present invention
  • Fig. 2 is a schematic diagram of the main process of a blockchain consensus method according to an embodiment of the present invention
  • Fig. 3 is a schematic diagram of a proposal message according to an embodiment of the present invention.
  • FIG. 4 is a schematic diagram of the main process of a blockchain consensus method according to another embodiment of the present invention.
  • Fig. 5 is a schematic diagram of the main process of a blockchain consensus method according to another embodiment of the present invention.
  • FIG. 6 is a schematic diagram of the main flow of a blockchain consensus method according to an embodiment of the present invention.
  • Figure 7 is a schematic diagram of the main modules of a blockchain consensus device according to an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of the main modules of a blockchain consensus device according to another embodiment of the present invention.
  • FIG. 9 is an exemplary system architecture diagram to which the embodiment of the present invention can be applied.
  • FIG. 10 is a schematic structural diagram of a computer system suitable for implementing a terminal device or a server according to an embodiment of the present invention.
  • Fig. 1 is a framework diagram of a blockchain consensus system according to an embodiment of the present invention.
  • a point-to-point network ie, a public network
  • FIG. 1 exemplarily shows a three-level sub-network, for example, the priority of the sub-network A is higher than the priority of the sub-network B, and the priority of the sub-network B is higher than the priority of the sub-network C. Due to the different network ranges of blockchain applications, the number of priorities of each sub-network is not limited to the three levels shown in Figure 1. It can be more or less, and sub-networks of the same priority.
  • the public network is the Internet, which is a collection of computer networks formed by connecting computer networks (including local area networks and metropolitan area networks) of different locations and sizes in the world.
  • the sub-network may be a local area network, a metropolitan area network, or the like.
  • each sub-network has a master node (Leader) and multiple peer nodes (Peer), and both the Peer node and the leader node can receive transaction messages issued by the client.
  • the Leader node is a hierarchical structure.
  • the lower-level Leader node can know the upper-level Leader node, and the upper-level Leader node can also know the lower-level Leader node set; each leader node can know all the Peer nodes in the same sub-network; each Peer node can know the same child Other Peer nodes in the network and Leader nodes in the same sub-network. Therefore, the priority of the sub-network that the leader node joins determines the priority of the leader node.
  • each peer node may be only one node that can communicate with the external network.
  • This node is the leader node of the local area network, and the other nodes in the local area network are peer nodes, and each peer node has an equal status.
  • the Leader node is not static. When the Peer node detects an abnormality of the Leader node in the current network environment, it can be re-elected through the Raft protocol, etc. However, the leader nominated during the election process must have network access to the superior leader. If the leader node detects that the parent leader node corresponding to the node is abnormal (for example, the network is unavailable), it can broadcast to the surrounding network that can be connected. After receiving it, other Leader nodes in the surrounding network will send a response, and then the leader node will respond accordingly The parent Leader node changes.
  • Fig. 2 is a schematic diagram of the main process of a blockchain consensus method according to an embodiment of the present invention.
  • the blockchain consensus method may include:
  • Step 201 The client sends a transaction message to at least two nodes in the same network as the client.
  • the client terminal After ensuring the legitimacy of the transaction message, the client terminal sends the transaction message to at least two nodes (either Peer node or Leader node) that are in the same network as the client terminal to prevent individual nodes from cheating. Specifically, the client may send transaction messages to the Leader node and at least one Peer node, or may send transaction messages to at least two Peer nodes. It should be pointed out that the client can only send transaction messages to nodes that have established a connection with the client.
  • nodes either Peer node or Leader node
  • the client will send transaction messages to at least two nodes in sub-network C, such as Peer31, Peer32, and Peer33 in sub-network C, or, Leader30, Peer31, Peer32 and Peer34 in network C.
  • the transaction message includes transaction data and a client's signature.
  • Cryptographic algorithms can be used to process transaction data to ensure data consistency. Specifically, the transaction data can be hashed first, and then the hash value can be processed using the client's private key to obtain the client's signature. If the public key of the client is not broadcast to each node in advance, the transaction message should also include the public key of the client for the node to verify the client's signature.
  • Step 202 The master node in the same network as the client receives the transaction message sent by the client and the transaction message sent by at least one of the peer nodes, or receives the transaction message sent by at least two of the peer nodes.
  • Transaction message if the transaction data in the transaction message is consistent, the transaction message is sent to the master node in the upper-level network until the priority of the upper-level network is the highest.
  • the master node in the same network as the client receives the transaction message sent by the client and the transaction message sent by at least one of the peer nodes, or receives the transaction message sent by the at least two peer nodes
  • the transaction message includes: a peer node in the same network as the client receives the transaction message sent by the client and verifies it; after the verification is passed, the transaction message is appended with the transaction message The signature of the peer node, and send the transaction message to the master node in the same network as the peer node; or, the master node in the same network as the client receives the message sent by the client
  • the transaction message and at least one of the peer nodes send the transaction message and verify the signature respectively; or, receive the transaction message sent by at least two of the peer nodes and verify the signature respectively.
  • the client sends a transaction message to the Peer node, after the Peer node receives the transaction message sent by the client, it verifies the client's signature through the client's public key. Specifically, the transaction data in the transaction message is hashed, and the hash value is compared with the signature after decryption by the public key. If the verification is passed, the signature of the Peer node is attached to the transaction message, and the transaction message with the signature of the Peer node attached is sent to the Leader node in the same network as the Peer node. Therefore, the Leader node will receive the transaction message sent by the Peer node (forwarded by one or more Peer nodes), and may also receive the transaction message sent by the client, that is, the Leader node will receive at least two transaction messages.
  • the Leader node receives the transaction message sent by the Peer node, it first verifies the signature of the Peer node. After the verification is passed, the client signature is verified to obtain the transaction data. The first verification is to verify that the transaction message forwarded by the Peer node has not been tampered with during network transmission, and to ensure the authenticity of the transaction message forwarded by the Peer node; the second verification is to verify that the transaction data in the transaction message is the customer Transaction data sent by the client. If the Leader node receives the transaction message sent by the client, it only needs to verify the client's signature to obtain the transaction data.
  • the leader node will determine whether it has a parent leader. If there is a parent leader, it will add its own signature to the transaction message and send it to the parent leader; the parent leader After receiving the message, the same operation (including verification and additional signature) will be done until the current Leader node is the highest level Leader. Verifying each transaction message through the Leader node can ensure the consistency of transaction data. It should be pointed out that the parent leader needs to verify each signature in the transaction message in turn to ensure that the transaction data sent by the client has not been tampered with.
  • the transaction message is sent to the master node in the upper-level network until the priority of the upper-level network is the highest, including: being in contact with the client
  • the master node in the same network judges whether the transaction data in each transaction message received is consistent based on the principle of majority; if so, append the signature of the master node to the transaction message, and send the transaction message to the previous
  • the master node in the upper-level network the master node in the upper-level network verifies the received transaction message; after the verification is passed, the master node’s signature is attached to the transaction message, and the transaction
  • the transaction message is sent to the master node in the upper-level network; until the priority of the upper-level network is the highest.
  • the Leader node obtains the transaction data in each transaction message through verification and determines whether the transaction data in each transaction message is consistent. For example, it can be determined whether multiple received transaction data are consistent based on the majority principle. If the transaction data is confirmed to be consistent, the transaction messages that are deemed to have not been tampered with are packaged into a transaction message, and the Leader node's signature is attached and sent to the parent Leader.
  • Step 303 The master node in the highest priority network generates a proposal message according to the received transaction message, and makes a consensus decision on the proposal message based on the Byzantine Fault Tolerance Consensus Mechanism (BFT); after the consensus decision is passed, the proposal message is sent To the master node in the lower-level network until the lower-level network is the network where the client is located.
  • BFT Byzantine Fault Tolerance Consensus Mechanism
  • the Leader node in the highest priority network can generate proposal messages based on the transaction messages received within a period of time or a certain number of transaction messages.
  • the proposal message includes the data list, the current round of consensus identification, the identification of the master node in the highest priority network, and the signature of the master node in the highest priority network, as shown in FIG. 3.
  • Each transaction data in the data list is arranged in sequence based on the transaction time, that is, the data that needs to be written into the block. For example, when the number of transaction messages received by the Leader node in the highest priority network reaches 100, the 100 transaction messages will be packaged; or it will be received within 2 seconds after receiving the first transaction message. The received transaction messages are packaged into proposal messages.
  • the default generation method of this round of consensus identification (CID) is self-increment.
  • the transaction message sent by the lower-level Leader node carries multi-level signatures.
  • the Leader node in the highest priority network only needs to verify the correctness of the transaction data. After the verification is passed, it will be packaged into a proposal message.
  • leader node in the highest priority network changes, the new leader node can start numbering again, add its own signature, and broadcast to the peer node and lower leader node in the same network.
  • Leader node changes For example, the Leader node itself exits abnormally (other nodes will detect that the Leader node has no heartbeat), or there is a problem with the data sent by the Leader node (Of course, this problem is not necessarily caused by the Leader node, but also There may be a problem in the transmission process). Under these circumstances, other peer nodes will think that the leader node is not safe enough, so they will trigger the re-election of the leader node.
  • the master node identifier in the highest priority network may be the ID or IP of the master node.
  • IP has the problem of duplication.
  • ID is selected as the master node identification to ensure the uniqueness of the identification.
  • the proposal message may further carry the public key of the current node (that is, the Leader node in the highest priority network). Whether to carry the public key can be freely determined, because the public key itself is public and can be negotiated in advance, or can be carried in a message, which is not limited in the embodiment of the present invention.
  • performing a consensus decision on the proposal message based on a Byzantine fault-tolerant consensus mechanism includes: the master node in the highest priority network sends the proposal message to the master node itself and the highest priority network The master node and the peer node receive the proposal message, and make a consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism.
  • Leader00 in the highest priority network sends proposal messages to Peer01, Peer02, Peer03, Peer04, and Leader00 itself in the same network.
  • Peer01, Peer02, Peer03, Peer04, and Leader00 will all be based on the Byzantine fault-tolerant consensus mechanism. Consensus judgment is made on the proposal message.
  • the consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism includes: verifying the proposal message, and after the verification is passed, generating a Write message according to the proposal message; wherein, the The written message includes the current round of consensus identification and signature; broadcasts the written message to all nodes in the current network; performs signature verification and consensus rule determination on the received written message, and after the judgment is passed, according to the Write the message to generate an Accpet message; where the received message includes the current round of consensus identification and signature; broadcast the received message to all nodes in the current network; verify the received message and Consensus rule determination.
  • Both the Peer node and the Leader node perform signature verification and CID sequence confirmation on the received proposal message; after the verification is passed, the Write message is broadcast to other nodes in the same network and the current node itself.
  • the Write message does not need to contain specific messages. Content, only CID and signature are required.
  • Whether to carry the public key can be freely determined, because the public key itself is public and can be negotiated in advance, or can be carried in a message, which is not limited in the embodiment of the present invention.
  • After other nodes in the same network and the current node receive the Write message they will verify the Write message and make a consensus rule decision. Specifically, a consensus can be reached using the principle of N ⁇ 3f+1, where N is the total number of nodes, and f is the number of malicious nodes. For example, if 4 nodes participate in the consensus, then 1 node is allowed to be abnormal (f is the number of evils), and if there are 7 nodes, 2 nodes are allowed to be abnormal.
  • the Accpet message is generated and the signature of the current node is attached, and the Accept message is broadcast to other nodes in the same network and the current node itself.
  • the Accpet message is similar to the Write message, and only the CID and signature are required.
  • Whether to carry the public key can be freely determined, because the public key itself is public and can be negotiated in advance, or can be carried in a message, which is not limited in the embodiment of the present invention.
  • other nodes in the same network and the current node verify the Accept message and make a consensus rule determination (for example, N ⁇ 3f+1). If the judgment is passed, it indicates that the current round of consensus is successful, and the transaction data in the proposal message can be written into the block.
  • the next-level network is the network where the client is located; a peer node in the same network as the master node receives the proposal message sent by the master node, and verifies the proposal message; After the sign is approved, the transaction data in the proposal message is written into the block.
  • the proposal message sent by the upper-level Leader node carries multi-level signatures. Peer nodes in the same network as the upper-level Leader node and the lower-level Leader nodes only need to verify the correctness of the transaction data, and write the transaction data after the verification is passed. Into the block. In the embodiment of the present invention, for the lower-level Leader node, it is necessary to sign the proposal message of the current round of consensus, and then broadcast the signed proposal message to the Peer node and the lower-level Leader node in the same network as it, and so on. , Until the client's network (ie the lowest level network).
  • the method may further include: at least two nodes that are in the same network as the client and have established connections with the client receive the proposal message, and perform processing on the proposal message. Sign verification; after the verification is passed, the transaction data in the proposal message is written into the block, and a response message is sent to the client.
  • the client sends the transaction message to at least two nodes (Peer node or Leader node) that are in the same network as the client, To prevent individual nodes from cheating. Therefore, after the verification is passed, at least two nodes (Peer node or Leader node) that are in the same network with the client and establish a connection with the client will not only write transaction data into the block, but also The client sends a response message.
  • Each Peer node does not know whether other Peer nodes will answer the client, and each Peer node that establishes a connection with the client will answer the client.
  • the Byzantine fault-tolerant consensus mechanism has the advantages of low energy consumption, large throughput, and short confirmation time.
  • the embodiment of the present invention combines BFT with a peer-to-peer network to achieve consensus in the entire blockchain system under a peer-to-peer network environment. Can effectively improve consensus efficiency and reduce costs.
  • the present invention uses the Byzantine fault-tolerant consensus mechanism to make a consensus decision on the proposal message. After the consensus decision is passed, the proposal message is sent to the master node in the next-level network until the next The level network is the technical means of the network where the client is located, thereby solving the technical problems of long transaction confirmation time and small transaction volume carried by blocks in the prior art.
  • the embodiment of the present invention uses cryptographic algorithms to ensure data consistency in a peer-to-peer network environment, and consensus based on the Byzantine fault-tolerant consensus mechanism can effectively improve consensus efficiency; in the actual consensus process, a hierarchical regional consensus mechanism is adopted , Through the consensus reached in a small area, and the method of broadcasting, on the one hand, it is very compatible with the peer-to-peer network, on the other hand, it can reduce the waste of resources caused by mining, thereby effectively improving the efficiency of consensus.
  • Fig. 4 is a schematic diagram of the main process of a blockchain consensus method according to another embodiment of the present invention.
  • the blockchain consensus method is applied to a master node in the same network as a client, and includes: step 401, receiving a transaction message sent by the client and a transaction message sent by at least one peer node, or receiving at least two A transaction message sent by a peer node; wherein the peer node, the master node, and the client are all in the same network; step 402, it is determined whether the received transaction message is consistent, and if so, The transaction message is sent to the master node in the upper level network.
  • the client terminal After ensuring the legitimacy of the transaction message, the client terminal sends the transaction message to at least two nodes (either Peer node or Leader node) that are in the same network as the client terminal to prevent individual nodes from cheating. Specifically, the client can send the transaction message to the Leader node and at least one Peer node, and can also send the transaction message to at least two Peer nodes.
  • the client can send the transaction message to the Leader node and at least one Peer node, and can also send the transaction message to at least two Peer nodes.
  • the transaction message includes transaction data and a client's signature.
  • Cryptographic algorithms can be used to process transaction data to ensure data consistency.
  • step 401 includes: receiving the transaction message sent by the client and the transaction message sent by at least one peer node, and verifying the transaction message respectively; or, receiving the transaction message sent by at least two peer nodes and verifying the transaction message respectively. It performs signature verification; wherein the transaction message sent by the peer node includes the transaction message sent by the client and the signature of the peer node. Since in step 201, the client sends a transaction message to the Peer node, after receiving the transaction message sent by the client, the Peer node verifies the client's signature through the client's public key.
  • the transaction data in the transaction message is hashed, and the hash value is compared with the signature after decryption by the public key. If the verification is passed, the signature of the Peer node is attached to the transaction message, and the transaction message with the signature of the Peer node attached is sent to the Leader node in the same network as the Peer node. Therefore, the Leader node will receive the transaction message sent by the Peer node (forwarded by one or more Peer nodes), and may also receive the transaction message sent by the client, that is, the Leader node will receive at least two transaction messages. If the Leader node receives the transaction message sent by the Peer node, it first verifies the signature of the Peer node.
  • the client signature is verified to obtain the transaction data.
  • the first verification is to verify that the transaction message forwarded by the Peer node has not been tampered with during network transmission, and to ensure the authenticity of the transaction message forwarded by the Peer node; the second verification is to verify that the transaction data in the transaction message is the customer Transaction data sent by the client. If the Leader node receives the transaction message sent by the client, it only needs to verify the client's signature to obtain the transaction data.
  • step 402 includes: judging whether the transaction data in each transaction message received is consistent based on the principle of majority; if so, attaching the signature of the master node to the transaction message, and sending the transaction message To the master node in the upper level network. If it is determined that the transaction data in the transaction message is consistent, the leader node will determine whether it has a parent leader. If there is a parent leader, it will add its own signature to the transaction message and send it to the parent leader; the parent leader After receiving the message, the same operation (including verification and additional signature) will be done until the current Leader node is the highest level Leader. Verifying each transaction message through the Leader node can ensure the consistency of transaction data.
  • Fig. 5 is a schematic diagram of the main process of a blockchain consensus method according to another embodiment of the present invention.
  • the block chain consensus method is applied to the master node in the highest priority network, and includes: step 501, generating a proposal message according to the received transaction message; step 502, performing consensus judgment on the proposal message based on the Byzantine fault-tolerant consensus mechanism; Step 503: After the consensus decision is passed, the proposal message is sent to the master node in the next level network.
  • the Leader node in the highest priority network can generate proposal messages based on the transaction messages received within a period of time or a certain number of transaction messages.
  • the proposal message includes the data list, the current round of consensus identification, the identification of the master node in the highest priority network, and the signature of the master node in the highest priority network.
  • performing a consensus decision on the proposal message based on a Byzantine fault-tolerant consensus mechanism includes: sending the proposal message to the master node itself and a peer node in the highest priority network; receiving the proposal message , And based on the Byzantine fault-tolerant consensus mechanism to make a consensus judgment on the proposal message.
  • the consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism includes: verifying the proposal message, and after the verification is passed, generating a write message according to the proposal message; wherein, the write message Including the current round of consensus identification and signature; broadcast the write message to all nodes in the current network; perform signature verification and consensus rule determination on the received write message, and after the determination is passed, according to the write message Generate a received message; where the received message includes the current round of consensus identification and signature; broadcast the received message to all nodes in the current network; perform signature verification and consensus rule determination on the received received message.
  • the present invention also provides a blockchain consensus method, applied to a master node in a medium priority network, including: receiving a proposal message sent by a master node in the highest priority network, and verifying the proposal message; After the signature is passed, the transaction data in the proposal message is written into the block, and the signature of the master node is attached to the proposal message, and the proposal message is sent to the same network as the master node The peer node and the master node in the lower-level network; until the lower-level network is the network where the client is located.
  • the present invention also provides a blockchain consensus method, which is applied to peer nodes in the same network as the client, including: receiving the transaction message sent by the client and verifying it; after the verification is passed Attach the signature of the peer node to the transaction message, and send the transaction message to a master node in the same network as the peer node.
  • the method further includes: receiving a proposal message, verifying the proposal message; after the verification is passed, writing the transaction data in the proposal message to a block, and sending a response to the client news.
  • Fig. 6 is a schematic diagram of the main process of a blockchain consensus method according to a reference embodiment of the present invention. The entire process is described in detail below with an example of only two-level Leader nodes.
  • the blockchain consensus method may include the following steps:
  • step 601 the client sends the transaction message to the Peer11 node, Peer12 node, Peer14 node and Leader10 node.
  • the client may first hash the transaction data, and then use the client's private key to process the hash value to obtain the client's signature. If the public key of the client is not broadcast to each node in advance, the transaction message should also carry the public key of the client for the node to verify the client's signature.
  • Peer11, Peer12, Peer14, and Leader10 nodes are in the same network as the client and are connected to the client, after ensuring the legitimacy of the transaction message, the client broadcasts the transaction message, Peer11 node, Peer12 node, Peer14 node and Leader10 node respectively received the transaction message.
  • FIG. 6 exemplarily shows the process of the Peer11 node receiving the transaction message.
  • the client can also send transaction messages to Peer11, Peer12, and Peer13 nodes, and can also be Peer12 and Peer13 nodes, which is not limited in the embodiment of the present invention to prevent individual nodes from cheating.
  • Step 602 the Peer11 node receives the transaction message sent by the client and verifies it; after the verification is passed, the Peer11 node's signature is attached to the transaction message, and the transaction message is sent to the Leader10 node .
  • the signature verification and signature process of Peer12 node and Peer14 node is similar to that of Peer11 node, and will not be repeated.
  • the Leader10 node receives the transaction message sent by the client and the Peer11 node, Peer12 node, and Peer14 node send transaction messages, and verifies them respectively; after the verification passes, the transaction in each received transaction message is determined Whether the data is consistent; if so, attach the signature of the Leader10 node to the transaction message, and send the transaction message to the Leader00 node in the upper level network.
  • Leader10 node receives the transaction message sent by the Peer node, it first verifies the signature of the Peer node. After the verification is passed, the client signature is verified to obtain the transaction data.
  • the Leader00 node In step 604, the Leader00 node generates a proposal message according to the received transaction message, and sends the proposal message to the Leader00 node, Peer01, Peer02, Peer03, and Peer04 nodes.
  • FIG. 6 exemplarily shows the Peer01 node and the Peer02 node, which are similar to the execution process of each Peer node in the same network as the Leader00 node, and will not be repeated.
  • Step 605 The Leader00 node, Peer01 node, Peer02 node, Peer03 node, and Peer04 node verify the proposal message, and after the verification is passed, generate a Write message according to the proposal message, and broadcast the Write message to the current network All nodes.
  • Both the Peer node and the Leader node perform signature verification and CID sequence confirmation on the received proposal message; after the verification is passed, the Write message is broadcast to other nodes in the current network and the current node itself.
  • the Write message does not need to contain specific messages. Content, only CID and signature are required.
  • Step 606 Leader00 node, Peer01 node, Peer02 node, Peer03 node, Peer04 node, receive the Write message, verify the signature of the Write message and determine the consensus rule, after the judgment is passed, generate an Accpet message according to the Write message, and broadcast the Accpet message to All nodes in the current network.
  • the CID sequence is mainly confirmed, the signature is verified by Hash, and the consensus rule is determined by the legal rule (N ⁇ 3f+1 principle).
  • the Leader00 node, Peer01 node, Peer02 node, Peer03 node, and Peer04 node receive the Accpet message, and perform signature verification and consensus rule determination on the Accpet message; if the determination is passed, it indicates that the current round of consensus is successful.
  • the Leader00 node writes the transaction data in the proposal message into the block, and sends the proposal message to the Leader10 node in the next level network after signing the proposal message; Peer01 node, Peer02 node, Peer03 node, Peer04 node, and The transaction data in the proposal message is written into the block.
  • the Leader10 node receives the proposal message and verifies the proposal message; after the verification is passed, the transaction data in the proposal message is written into the block, and the Leader10 node is attached to the proposal message
  • the signature of is broadcast to Peer11 node, Peer12 node, Peer13 node, Peer14 node.
  • step 610 the Peer11 node, Peer12 node, Peer13 node, and Peer14 node receive the proposal message sent by the Leader10 node, and verify the proposal message; after the verification is passed, the transaction data in the proposal message is written into the block.
  • the Peer11 node, Peer12 node, Peer14 node and Leader10 node may also send a response message to the client.
  • Fig. 7 is a schematic diagram of main modules of a blockchain consensus device according to an embodiment of the present invention.
  • the blockchain consensus device 700 is set on a master node in the same network as the client, and includes: a first receiving module 701, configured to receive a transaction message and at least one pair sent by the client A transaction message sent by a peer node, or a transaction message sent by at least two peer nodes is received; wherein the peer node, the master node, and the client are all in the same network; the first sending module 702, It is used to determine whether the received transaction messages are consistent, and if so, the transaction message is sent to the master node in the upper level network.
  • the transaction message includes transaction data and a client's signature
  • Receiving transaction messages sent by the client and transaction messages sent by at least one peer node, or receiving transaction messages sent by at least two peer nodes, includes:
  • the transaction message sent by the peer node includes the transaction message sent by the client and the signature of the peer node.
  • judging whether the received transaction messages are consistent, and if so, sending the transaction message to the master node in the upper-level network including:
  • Fig. 8 is a schematic diagram of main modules of a blockchain consensus device according to another embodiment of the present invention.
  • the blockchain consensus device 800 is set up at the master node in the highest priority network, and includes: a proposal module 801 for generating proposal messages based on received transaction messages; and a consensus module 802 for generating proposal messages based on The Byzantine fault-tolerant consensus mechanism makes a consensus decision on the proposal message; the second sending module 803 is configured to send the proposal message to the master node in the next level network after the consensus decision is passed.
  • the proposal message is generated according to the received transaction message, including:
  • the proposal message includes the data list, the current round of consensus identification, the identification of the master node in the highest priority network, and the signature of the master node in the highest priority network.
  • the consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism includes:
  • the proposal message is received, and a consensus decision is made on the proposal message based on the Byzantine fault-tolerant consensus mechanism.
  • the consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism includes:
  • the embodiment of the present invention also provides a blockchain consensus device, which is set on a master node in a medium-priority network, and includes: a second receiving module for receiving proposal messages sent by the master node in the highest-priority network.
  • the proposal message is verified; the writing module is used to write the transaction data in the proposal message into the block after the verification is passed, and add the signature of the master node to the proposal message, and
  • the proposal message is sent to the peer node in the same network as the master node and the master node in the next level network; until the next level network is the network where the client is located.
  • a blockchain consensus device which is set at a peer node in the same network as the client, and includes: a third receiving module, configured to receive transaction messages sent by the client, and Verify the signature; the third sending module is used to attach the signature of the peer node to the transaction message after the signature verification is passed, and send the transaction message to the same node as the peer node The master node in the network.
  • a fourth receiving module configured to receive a proposal message and verify the proposal message; after the verification is passed, write the transaction data in the proposal message into the block and send it to the The client sends a reply message.
  • the present invention also provides a blockchain consensus system, including: a client terminal for sending transaction messages to at least two nodes in the same network as the client terminal; wherein, the at least two nodes include a master At least two of a node and a peer node; a master node in the same network as the client, used to receive transaction messages sent by the client and transaction messages sent by at least one of the peer nodes, or, Receive transaction messages sent by at least two of the peer nodes; if the transaction data in the transaction messages are consistent, send the transaction message to the master node in the upper-level network until the priority of the upper-level network is Highest; The master node in the highest priority network is used to generate proposal messages based on the received transaction messages, and make consensus judgments on the proposal messages based on the Byzantine fault-tolerant consensus mechanism; after the consensus judgment is passed, the proposal messages are sent to The master node in the lower-level network until the lower-level network is the network where the client is located.
  • a blockchain consensus system including: a client terminal for sending
  • the transaction message includes transaction data and a client's signature
  • the system also includes: a peer node in the same network as the client, for receiving the transaction message sent by the client and verifying it; after the verification is passed, the transaction message is displayed on the transaction message. Attach the signature of the peer node, and send the transaction message to the master node in the same network as the peer node; or,
  • the master node in the same network as the client is also used to: receive transaction messages sent by the client and transaction messages sent by at least one of the peer nodes, and verify and sign them respectively; or, receive at least two The transaction messages sent by each of the peer nodes are verified and signed respectively.
  • the master node in the same network as the client is further used to determine whether the transaction data in each transaction message received is consistent based on the principle of majority; if so, append the transaction message to the transaction message. Signature of the master node, and sending the transaction message to the master node in the upper level network;
  • the system also includes: a master node in the upper-level network for verifying the received transaction message; after the verification is passed, attach the signature of the master node to the transaction message, and The transaction message is sent to the master node in the upper-level network; until the priority of the upper-level network is the highest.
  • the master node in the highest priority network is also used to:
  • the proposal message includes the data list, the current round of consensus identification, the identification of the master node in the highest priority network, and the signature of the master node in the highest priority network.
  • the system further includes a peer node in the highest priority network
  • the master node in the highest priority network is further used to: send the proposal message to the master node itself and the peer node in the highest priority network;
  • the master node and the peer node are configured to receive the proposal message, and respectively make a consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism.
  • the consensus decision on the proposal message based on the Byzantine fault-tolerant consensus mechanism includes:
  • the master node in the highest priority network is further used to: send the proposal message to the master node in the next level network;
  • the master node in the lower-level network is also used to: receive the proposal message, verify the proposal message; after the verification is passed, write the transaction data in the proposal message into the block, and log in The proposal message is appended with the signature of the master node, and the proposal message is sent to the peer node in the same network as the master node and the master node in the next level network; until the next level The network is the network where the client is located;
  • the peer node in the same network as the master node is used to: receive the proposal message sent by the master node, and verify the proposal message; after the verification is passed, write the transaction data in the proposal message Block.
  • At least two nodes that are in the same network as the client and have established a connection with the client are also used to: receive the proposal message, and verify the proposal message; after the verification is passed, Write the transaction data in the proposal message into a block, and send a response message to the client.
  • the present invention uses the Byzantine fault-tolerant consensus mechanism to make a consensus decision on the proposal message. After the consensus decision is passed, the proposal message is sent to the master node in the next-level network until the next The level network is the technical means of the network where the client is located, thereby solving the technical problems of long transaction confirmation time and small transaction volume carried by blocks in the prior art.
  • the embodiment of the present invention uses cryptographic algorithms to ensure data consistency in a peer-to-peer network environment, and consensus based on the Byzantine fault-tolerant consensus mechanism can effectively improve consensus efficiency; in the actual consensus process, a hierarchical regional consensus mechanism is adopted , Through the consensus reached in a small area, and the method of broadcasting, on the one hand, it is very compatible with the peer-to-peer network, on the other hand, it can reduce the waste of resources caused by mining, thereby effectively improving the efficiency of consensus.
  • FIG. 9 shows an exemplary system architecture 900 of a blockchain consensus method or a blockchain consensus system to which embodiments of the present invention can be applied.
  • the system architecture 900 may include terminal devices 901, 902, and 903, a network 904, and a server 905.
  • the network 904 is used to provide a medium for communication links between the terminal devices 901, 902, 903 and the server 905.
  • the network 904 may include various connection types, such as wired, wireless communication links, or fiber optic cables, and so on.
  • the user can use the terminal devices 901, 902, and 903 to interact with the server 904 through the network 904 to receive or send messages and so on.
  • Various communication client applications may be installed on the terminal devices 901, 902, and 903, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).
  • the terminal devices 901, 902, and 903 may be various electronic devices that have a display screen and support web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and so on.
  • the server 905 may be a server that provides various services, for example, a back-end management server (just an example) that provides support for shopping websites browsed by users using the terminal devices 901, 902, 903.
  • the background management server can analyze and process the received product information query request and other data, and feed back the processing results (such as target push information, product information-only examples) to the terminal device.
  • terminal devices, networks, and servers in FIG. 9 are merely illustrative. According to implementation needs, there can be any number of terminal devices, networks and servers.
  • FIG. 10 shows a schematic structural diagram of a computer system 1000 suitable for implementing a terminal device of an embodiment of the present invention.
  • the terminal device shown in FIG. 10 is only an example, and should not bring any limitation to the function and application scope of the embodiment of the present invention.
  • the computer system 1000 includes a central processing unit (CPU) 1001, which can be based on a program stored in a read only memory (ROM) 1002 or a program loaded from a storage part 1008 into a random access memory (RAM) 1003 And perform various appropriate actions and processing.
  • CPU central processing unit
  • RAM random access memory
  • various programs and data required for the operation of the system 1000 are also stored.
  • the CPU 1001, the ROM 1002, and the RAM 1003 are connected to each other through a bus 1004.
  • An input/output (I/O) interface 1005 is also connected to the bus 1004.
  • the following components are connected to the I/O interface 1005: an input part 1006 including a keyboard, a mouse, etc.; an output part 1007 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and speakers, etc.; a storage part 1008 including a hard disk, etc. ; And a communication section 1009 including a network interface card such as a LAN card, a modem, and the like. The communication section 1009 performs communication processing via a network such as the Internet.
  • the driver 1010 is also connected to the I/O interface 1005 as needed.
  • a removable medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1010 as required, so that the computer program read therefrom is installed into the storage part 1008 as required.
  • the process described above with reference to the flowchart can be implemented as a computer software program.
  • the disclosed embodiments of the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart.
  • the computer program may be downloaded and installed from the network through the communication part 1009, and/or installed from the removable medium 1011.
  • the central processing unit (CPU) 1001 the above-mentioned functions defined in the system of the present invention are executed.
  • the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two.
  • the computer-readable storage medium may be, for example, but not limited to, an electric, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable Programmable read only memory (EPROM or flash memory), optical fiber, portable compact disk read only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above.
  • the computer-readable storage medium may be any tangible medium that contains or stores a program, and the program may be used by or in combination with an instruction execution system, apparatus, or device.
  • a computer-readable signal medium may include a data signal propagated in a baseband or as a part of a carrier wave, and a computer-readable program code is carried therein. This propagated data signal can take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • the computer-readable signal medium may also be any computer-readable medium other than the computer-readable storage medium.
  • the computer-readable medium may send, propagate, or transmit the program for use by or in combination with the instruction execution system, apparatus, or device .
  • the program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.
  • each block in the flowchart or block diagram may represent a module, program segment, or part of code, and the above-mentioned module, program segment, or part of code contains one or more for realizing the specified logical function Executable instructions.
  • the functions noted in the blocks may also occur in a different order than noted in the drawings. For example, two blocks shown in succession can actually be executed substantially in parallel, or they can sometimes be executed in the reverse order, depending on the functions involved.
  • each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be It is realized by a combination of dedicated hardware and computer instructions.
  • the modules involved in the described embodiments of the present invention can be implemented in software or hardware.
  • the described modules can also be provided in the processor.
  • a processor includes a first receiving module and a first sending module, where the names of these modules do not constitute the module under certain circumstances. The limitation of itself.
  • the present invention also provides a computer-readable medium.
  • the computer-readable medium may be included in the device described in the foregoing embodiment; or it may exist alone without being assembled into the device.
  • the aforementioned computer-readable medium carries one or more programs.
  • the device includes: receiving transaction messages sent by the client and transactions sent by at least one peer node Message, or receiving transaction messages sent by at least two peer nodes; wherein the peer node, the master node, and the client are all in the same network; determine whether the received transaction messages are consistent, If it is, the transaction message is sent to the master node in the upper level network.
  • the consensus decision based on the Byzantine fault-tolerant consensus mechanism is adopted for the proposal message, after the consensus decision is passed, the proposal message is sent to the master node in the next level network until the next level network is the client.
  • the embodiment of the present invention uses cryptographic algorithms to ensure data consistency in a peer-to-peer network environment, and consensus based on the Byzantine fault-tolerant consensus mechanism can effectively improve consensus efficiency; in the actual consensus process, a hierarchical regional consensus mechanism is adopted , Through the consensus reached in a small area, and the method of broadcasting, on the one hand, it is very compatible with the peer-to-peer network, on the other hand, it can reduce the waste of resources caused by mining, thereby effectively improving the efficiency of consensus.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computing Systems (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种区块链共识方法、装置和系统，涉及计算机技术领域。该方法的一具体实施方式包括：与客户端处于同一网络中的主节点接收客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息；若交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到上一级网络的优先级为最高；最高优先级网络中的主节点根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制对提案消息进行共识判定；共识判定通过后，将提案消息发送至下一级网络中的主节点，直到下一级网络为客户端所处的网络。该实施方式能够解决交易确认时间长、区块承载的交易量小的技术问题。

Description

一种区块链共识方法、装置和系统 技术领域
本发明涉及区块链技术领域，尤其涉及一种区块链共识方法、装置和系统。
背景技术
随着区块链技术的快速发展，越来越多的数据开始使用区块链进行存储和交互。在区块链的设计中，共识机制一直都是一个技术难点，尤其是在点对点的网络环境下。
共识就是参与节点状态一致，在区块链中主要是保证请求交易的顺序全局一致。对于区块链系统而言，点对点网络可以理解为公网，目前常见的点对点网络共识方案是工作量证明(Proof Of Work，简称POW)和权益证明(Proof of Stake，简称POS)。
在实现本发明过程中，发明人发现现有技术中至少存在如下问题：
性能较低，每个区块承载的交易量很小，并且每笔交易确认时间很久；耗费能源，采用挖矿机制导致能源的严重浪费。
发明内容
有鉴于此，本发明实施例提供一种区块链共识方法、装置和系统，以解决交易确认时间长、区块承载的交易量小的技术问题。
为实现上述目的，根据本发明实施例的一个方面，提供了一种区块链共识方法，其应用于与客户端处于同一网络中的主节点，包括：接收所述客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
根据本发明实施例的另一个方面，还提供了一种区块链共识方法，其应用于最高优先级网络中的主节点，所述方法包括：根据接收到的交易消息生成提案消息；基于拜占庭容错共识机制对所述提案消息进行共识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点。
根据本发明实施例的另一个方面，还提供了一种区块链共识方法，其应用于中等优先级网络中的主节点，所述方法包括：接收最高优先级网络中的主节点发送的提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络。
根据本发明实施例的另一个方面，还提供了一种区块链共识方法，其应用于与客户端处于同一网络中的对等节点，所述方法包括：接收所述客户端发送的交易消息，并对其进行验签；验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点。
根据本发明实施例的另一个方面，提供了一种区块链共识装置，其设置于与客户端处于同一网络中的主节点，所述装置包括：第一接收模块，用于接收所述客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；第一发送模块，用于判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
根据本发明实施例的另一个方面，还提供了一种区块链共识装置，其设置于最高优先级网络中的主节点，所述装置包括：提案模块，用于根据接收到的交易消息生成提案消息；共识模块，用于基于拜占庭容错共识机制对所述提案消息进行共识判定；第二发送模块，用于共识判定通过后，将所述提案消息发送至下一级网络中的主节点。
根据本发明实施例的另一个方面，还提供了一种区块链共识装置，其设置于中等优先级网络中的主节点，所述装置包括：第二接收模块，用于接收最高优先级网络中的主节点发送的提案消息，对所述提案消息进行验签；写入模块，用于验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络。
根据本发明实施例的另一个方面，还提供了一种区块链共识装置，其设置于与客户端处于同一网络中的对等节点，所述装置包括：第三接收模块，用于接收所述客户端发送的交易消息，并对其进行验签；第三发送模块，用于验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点。
根据本发明实施例的另一个方面，还提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一实施例所述的方法。
根据本发明实施例的另一个方面，还提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一实施例所述的方法。
根据本发明实施例的另一个方面，还提供了一种区块链共识方法，包括：客户端将交易消息发送至与所述客户端处于同一网络中的至少两个节点；其中，所述至少两个节点包括主节点和对等节点中的至少两个；与所述客户端处于同一网络中的主节点接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高；最高优先级网络中的主节点根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制对所述提案消息进行共 识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为所述客户端所处的网络。
另外，根据本发明实施例的另一个方面，提供了一种区块链共识系统，包括：客户端，用于将交易消息发送至与所述客户端处于同一网络中的至少两个节点；其中，所述至少两个节点包括主节点和对等节点中的至少两个；与所述客户端处于同一网络中的主节点，用于接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高；最高优先级网络中的主节点，用于根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为所述客户端所处的网络。
上述发明中的一个实施例具有如下优点或有益效果：因为采用基于拜占庭容错共识机制对提案消息进行共识判定，共识判定通过后，将提案消息发送至下一级网络中的主节点，直到下一级网络为客户端所处的网络的技术手段，所以克服了现有技术中交易确认时间长、区块承载的交易量小的技术问题。本发明实施例在点对点网络环境下，利用密码学算法保证数据一致性的前提下，基于拜占庭容错共识机制进行共识，可有效提高共识效率；在实际共识过程中，采用分层级区域内共识机制，通过共识在小范围内达成，并下达广播的方式，一方面与点对点网络非常契合，另一方面可减少了挖矿带来的资源浪费，从而有效提高共识效率。
上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1为本发明实施例的区块链共识系统的框架图；
图2是根据本发明一个实施例的区块链共识方法的主要流程的示意图；
图3是根据本发明实施例的提案消息的示意图；
图4是根据本发明另一个实施例的区块链共识方法的主要流程的示意图；
图5是根据本发明又一个实施例的区块链共识方法的主要流程的示意图；
图6是根据本发明一个可参考实施例的区块链共识方法的主要流程的示意图；
图7是根据本发明一个实施例的区块链共识装置的主要模块的示意图；
图8是根据本发明另一个实施例的区块链共识装置的主要模块的示意图；
图9是本发明实施例可以应用于其中的示例性系统架构图；
图10是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
图1为本发明实施例的区块链共识系统的框架图。如图1所示，点对点网络(即公网)包括多个子网络，各个子网络的优先级不同。图1示例性地示出了三级子网络，例如子网络A的优先级高于子网络B的优先级，子网络B的优先级高于子网络C的优先级。由于区块链应用的网络范围不同，各个子网络的优先级数量并不限于图1中所示 的三级，可以是更多级数，也可以是更少级数，而且相同优先级的子网络也可以由多个，本发明实施例对此不作限制。公网即国际互联网(Internet)，它是把全球不同位置、不同规模的计算机网络(包括局域网、城域网)相互连接在一起所形成的计算机网络的集合体。在本发明的实施例中，子网络可以是局域网、城域网等。
在本发明的实施例中，每个子网络中都有一个主节点(Leader)和多个对等节点(Peer)，Peer节点和Leader节点都可以接收客户端发布的交易消息。Leader节点是一种分级结构，下级的Leader节点可知上级Leader节点，上级Leader节点也可知下级Leader节点集合；每个Leader节点都可知同一子网络中的所有Peer节点；每个Peer节点都可知同一子网络中的其他Peer节点和同一子网络中的Leader节点。因此，Leader节点加入的子网络的优先级决定了该Leader节点的优先级。
例如一个局域网环境中可能只有一个节点是可以与外部网络通信的，这个节点就是该局域网的Leader节点，该局域网中的其他节点则为Peer节点，每个Peer节点地位平等。
Leader节点不是一成不变的，当Peer节点检测到当前网络环境的Leader节点异常，可通过Raft协议等进行重新选举，但该选举过程中提名的Leader必须自身有访问上级Leader的网络权限。若Leader节点检测到该节点对应的父级Leader节点异常(如网络不通)，则可以向周围可联通网络进行广播，周围网络的其他Leader节点接收到后会发送应答，随即该Leader节点进行对应的父级Leader节点变更。
图2是根据本发明一个实施例的区块链共识方法的主要流程的示意图。作为本发明的一个实施例，如图2所示，所述区块链共识方法可以包括：
步骤201，客户端将交易消息发送至与所述客户端处于同一网络中的至少两个节点。
在确保交易消息的合法性后，客户端将所述交易消息发送至与所述客户端处于同一网络中的至少两个节点(Peer节点或Leader节点均可)，以防止单独节点作弊。具体地，客户端可以将交易消息发送至 Leader节点和至少一个Peer节点，也可以将交易消息发送至至少两个Peer节点。需要指出的是，客户端只能够将交易消息发送至已与所述客户端建立连接的节点。
如图1所示，假设客户端处于子网络C中，那么客户端会将交易消息发送至子网络C中的至少两个节点，例如子网络C中的Peer31、Peer32和Peer33等，或者，子网络C中的Leader30、Peer31、Peer32和Peer34等。
可选地，所述交易消息包括交易数据和客户端的签名。可以采用密码学算法对交易数据进行处理，以保证数据的一致性。具体地，可以先对交易数据进行哈希处理，然后采用客户端私钥对哈希数值进行处理，从而得到客户端的签名。如果没有提前向各个节点广播客户端的公钥，所述交易消息还要包括客户端的公钥，以供节点验证客户端签名。
步骤202，与所述客户端处于同一网络中的主节点接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高。
可选地，与所述客户端处于同一网络中的主节点接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收所述至少两个对等节点发送的交易消息，包括：与所述客户端处于同一网络中的对等节点接收所述客户端发送的交易消息，并对其进行验签；验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点；或者，与所述客户端处于同一网络中的主节点接收所述客户端发送的交易消息和至少一个所述对等节点发送交易消息，并分别对其进行验签；或者，接收至少两个所述对等节点发送的交易消息，并分别对其进行验签。
由于在步骤201中，客户端向Peer节点发送了交易消息，那么Peer 节点接收到客户端发送的交易消息后，通过客户端公钥对客户端签名进行验证。具体地，对交易消息中的交易数据进行哈希处理，比较哈希数值与通过公钥解密后的签名是否一致。如果验签通过，则在该交易消息上附加上该Peer节点的签名，并将附加了该Peer节点签名后的交易消息发送至与该Peer节点处于同一网络中的Leader节点。因此，Leader节点会接收到Peer节点(一个或者多个Peer节点转发)发送的交易消息，也有可能会收到客户端发送的交易消息，即Leader节点会接收到至少两条交易消息。
如果Leader节点接收到Peer节点发送的交易消息，则先对Peer节点的签名进行验证，验签通过后，再对客户端签名进行验签，以获得交易数据。第一次验签是为了验证Peer节点转发的交易消息在网络传输过程中没有被篡改，保证Peer节点转发的交易消息的真实性；第二次验签是为了验证交易消息中的交易数据是客户端发送的交易数据。如果Leader节点接收到客户端发送的交易消息，则只需要验证客户端签名，从而获得交易数据。
如果确定交易消息中的交易数据一致，则该Leader节点会判断其本身是否存在父级Leader，假设存在父级Leader，则在交易消息上加入自己的签名，并发送至父级Leader；父级Leader接收到消息之后也会做同样的操作(包括验签和附加签名)，直到当前Leader节点为最高级Leader。通过Leader节点对各个交易消息进行验证，可以确保交易数据的一致性。需要指出的是，父级Leader要对交易消息中的各个签名依次进行验证，以保证客户端发送的交易数据没有被篡改。
可选地，若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高，包括：与所述客户端处于同一网络中的主节点基于多数原则判断接收到的各个交易消息中的交易数据是否一致；若是，则在所述交易消息上附加上所述主节点的签名，并将所述交易消息发送至上一级网络中的主节点；所述上一级网络中的主节点对接收到的交易消息进行验签；验签通过后，在所述交易消息上附加上所述主节点的签名，并将所述 交易消息发送至上一级网络中的主节点；直到所述上一级网络的优先级为最高。Leader节点通过验签分别获取了各个交易消息中的交易数据，判断各个交易消息中的交易数据是否一致，例如可以基于多数原则来判断接收到的多个交易数据是否一致。如果确认交易数据一致，则将这些被认定为未篡改的交易消息打包成一个交易消息，并附加上该Leader节点的签名后发送至父级Leader。
步骤303，最高优先级网络中的主节点根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制(BFT)对所述提案消息进行共识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为客户端所处的网络。
由于Leader节点在不断地向最高优先级网络中的Leader节点发送交易消息，最高优先级网络中的Leader节点可以根据一段时间内的收到的交易消息或者一定数量的交易消息生成提案消息，其中，所述提案消息包括数据列表、本轮共识标识、所述最高优先级网络中的主节点标识和所述最高优先级网络中的主节点的签名，如图3所示。数据列表中的各条交易数据基于交易时间依次排列，也就是需要写入区块的数据。例如，最高优先级网络中的Leader节点接收到交易消息的数量达到100个时，就把这100个交易消息进行打包；或者是从接收到第一个交易消息开始算起，将2秒内接收到的交易消息打包成提案消息。其中，本轮共识标识(CID)的默认生成方式为自增。
由下级Leader节点发送的交易消息携带有多级签名，最高优先级网络中的Leader节点只需要验签就可以确定交易数据的正确性，验签通过后将其打包成提案消息。
当最高优先级网络中的Leader节点变化时，新的Leader节点可重新开始编号，加入自己的签名后广播至同一网络中的Peer节点和下级Leader节点。Leader节点变化的原因很多，例如：Leader节点本身异常退出(其他节点会检测到Leader节点没有心跳了)，或者Leader节点发送的数据本身有问题(当然这种问题不一定是Leader节点有问题，也有可能是传输过程有问题)，这些情况下都会导致其他Peer节点认 为Leader节点不够安全，所以会促使他们触发重新选举Leader节点。
可选地，所述最高优先级网络中的主节点标识可以是该主节点的ID或者IP。但是IP存在重复的问题，一般选择ID作为主节点标识，以保证标识的唯一性。所述提案消息还可以进一步携带当前节点(即最高优先级网络中的Leader节点)的公钥。是否携带公钥可以自由决定，因为公钥本身是公开的，可以事先就协商给出，也可以在消息中携带，本发明实施例对此不作限制。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：所述最高优先级网络中的主节点将所述提案消息发送至所述主节点自身和所述最高优先级网络中的对等节点；所述主节点和所述对等节点接收所述提案消息，并分别基于拜占庭容错共识机制对所述提案消息进行共识判定。如图1所示，最高优先级网络中的Leader00将提案消息发送至同一网络中的Peer01、Peer02、Peer03、Peer04以及Leader00自身，Peer01、Peer02、Peer03、Peer04以及Leader00都会基于拜占庭容错共识机制对所述提案消息进行共识判定。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：对所述提案消息进行验签，验证通过后，根据所述提案消息生成写入(Write)消息；其中，所述写入消息包括本轮共识标识和签名；将所述写入消息广播至当前网络中的所有节点；对接收到的所述写入消息进行验签和共识规则判定，判定通过后，根据所述写入消息生成接收(Accpet)消息；其中，所述接收消息包括本轮共识标识和签名；将所述接收消息广播至当前网络中的所有节点；对接收到的所述接收消息进行验签和共识规则判定。
无论是Peer节点还是Leader节点都对接收到的提案消息进行签名验证和CID的顺序性确认；验证通过后，向同一网络中的其他节点和当前节点自身广播Write消息，Write消息不需要含有具体消息内容，只需要CID和签名即可。是否携带公钥可以自由决定，因为公钥本身是公开的，可以事先就协商给出，也可以在消息中携带，本发明实施例对此不作限制。同一网络中的其他节点和当前节点接收到Write消息 后，对Write消息进行验证，并进行共识规则判定。具体地，可以采用N≥3f+1原则达成共识，N为总节点数量，f为作恶节点数量。例如有4个节点参与共识，那么允许1个节点异常(f即作恶数)，如果有7个节点则允许2个节点异常。
判定通过后，则生成Accpet消息并附加当前节点的签名后，向同一网络中的其他节点和当前节点自身广播Accept消息，Accpet消息和Write消息类似，也是只需要CID和签名即可。是否携带公钥可以自由决定，因为公钥本身是公开的，可以事先就协商给出，也可以在消息中携带，本发明实施例对此不作限制。同一网络中的其他节点和当前节点接收到Accept消息后，对Accept消息进行验证，并进行共识规则判定(比如N≥3f+1)。若判定通过，则表明本轮共识成功，可以将所述提案消息中的交易数据写入区块。
将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为客户端所处的网络，包括：所述最高优先级网络中的主节点将所述提案消息发送至下一级网络中的主节点；所述下一级网络中的主节点接收所述提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络；与所述主节点处于同一网络中的对等节点接收所述主节点发送的提案消息，并对所述提案消息进行验签；验签通过后，将提案消息中的交易数据写入区块。
由上级Leader节点发送的提案消息携带有多级签名，与上级Leader节点处于同一网络中的Peer节点以及下级Leader节点只需要验签就可以确定交易数据的正确性，验签通过后将交易数据写入区块。在本发明的实施例中，对于下级Leader节点，则需要将本轮共识的提案消息进行签名，然后将该签名后的提案消息广播至与其处于同一网络中的Peer节点和下级Leader节点，依次类推，直到客户端所处的网络(即最低级网络)。
可选地，在步骤303之后，所述方法还可以包括：与所述客户端处于同一网络中且与所述客户端建立连接的至少两个节点接收所述提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并向所述客户端发送应答消息。
如步骤301中所描述的，在确保交易消息的合法性后，客户端将所述交易消息发送至与所述客户端处于同一网络中的至少两个节点(Peer节点或Leader节点均可)，以防止单独节点作弊。因此，验签通过后，与所述客户端处于同一网络中且与所述客户端建立连接的至少两个节点(Peer节点或Leader节点均可)不但将交易数据写入区块，还会向所述客户端发送应答消息。每个Peer节点并不知道其他Peer节点是否会应答该客户端，与客户端建立连接的每个Peer节点都会应答客户端。
拜占庭容错共识机制(BFT)具有能耗低、吞吐量较大和确认时间短的优点，本发明实施例将BFT与点对点网络结合起来，实现在点对点网络的环境下，整个区块链系统达成共识，可有效提高共识效率，降低成本。
根据上面所述的各种实施例，可以看出本发明通过基于拜占庭容错共识机制对提案消息进行共识判定，共识判定通过后，将提案消息发送至下一级网络中的主节点，直到下一级网络为客户端所处的网络的技术手段，从而解决了现有技术中交易确认时间长、区块承载的交易量小的技术问题。本发明实施例在点对点网络环境下，利用密码学算法保证数据一致性的前提下，基于拜占庭容错共识机制进行共识，可有效提高共识效率；在实际共识过程中，采用分层级区域内共识机制，通过共识在小范围内达成，并下达广播的方式，一方面与点对点网络非常契合，另一方面可减少了挖矿带来的资源浪费，从而有效提高共识效率。
图4是根据本发明另一个实施例的区块链共识方法的主要流程的示意图。所述区块链共识方法应用于与客户端处于同一网络中的主节点，包括：步骤401，接收所述客户端发送的交易消息和至少一个对等 节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；步骤402，判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
在确保交易消息的合法性后，客户端将所述交易消息发送至与所述客户端处于同一网络中的至少两个节点(Peer节点或Leader节点均可)，以防止单独节点作弊。具体地，客户端可以将交易消息发送至Leader节点和至少一个Peer节点，也可以将交易消息发送至至少两个Peer节点。
可选地，所述交易消息包括交易数据和客户端的签名。可以采用密码学算法对交易数据进行处理，以保证数据的一致性。可选地，步骤401包括：接收客户端发送的交易消息和至少一个对等节点发送交易消息，并分别对其进行验签；或者，接收至少两个对等节点发送的交易消息，并分别对其进行验签；其中，所述对等节点发送的交易消息包括所述客户端发送的交易消息和所述对等节点的签名。由于在步骤201中，客户端向Peer节点发送了交易消息，那么Peer节点接收到客户端发送的交易消息后，通过客户端公钥对客户端签名进行验证。具体地，对交易消息中的交易数据进行哈希处理，比较哈希数值与通过公钥解密后的签名是否一致。如果验签通过，则在该交易消息上附加上该Peer节点的签名，并将附加了该Peer节点签名后的交易消息发送至与该Peer节点处于同一网络中的Leader节点。因此，Leader节点会接收到Peer节点(一个或者多个Peer节点转发)发送的交易消息，也有可能会收到客户端发送的交易消息，即Leader节点会接收到至少两条交易消息。如果Leader节点接收到Peer节点发送的交易消息，则先对Peer节点的签名进行验证，验签通过后，再对客户端签名进行验签，以获得交易数据。第一次验签是为了验证Peer节点转发的交易消息在网络传输过程中没有被篡改，保证Peer节点转发的交易消息的真实性；第二次验签是为了验证交易消息中的交易数据是客户端发送的交易数据。如果Leader节点接收到客户端发送的交易消息，则只需要 验证客户端签名，从而获得交易数据。
可选地，步骤402包括：基于多数原则判断接收到的各个交易消息中的交易数据是否一致；若是，则在所述交易消息上附加上所述主节点的签名，并将所述交易消息发送至上一级网络中的主节点。如果确定交易消息中的交易数据一致，则该Leader节点会判断其本身是否存在父级Leader，假设存在父级Leader，则在交易消息上加入自己的签名，并发送至父级Leader；父级Leader接收到消息之后也会做同样的操作(包括验签和附加签名)，直到当前Leader节点为最高级Leader。通过Leader节点对各个交易消息进行验证，可以确保交易数据的一致性。
图5是根据本发明又一个实施例的区块链共识方法的主要流程的示意图。所述区块链共识方法应用于最高优先级网络中的主节点，包括：步骤501，根据接收到的交易消息生成提案消息；步骤502，基于拜占庭容错共识机制对所述提案消息进行共识判定；步骤503，共识判定通过后，将所述提案消息发送至下一级网络中的主节点。
由于Leader节点在不断地向最高优先级网络中的Leader节点发送交易消息，最高优先级网络中的Leader节点可以根据一段时间内的收到的交易消息或者一定数量的交易消息生成提案消息，其中，所述提案消息包括数据列表、本轮共识标识、所述最高优先级网络中的主节点标识和所述最高优先级网络中的主节点的签名。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：将所述提案消息发送至所述主节点自身和所述最高优先级网络中的对等节点；接收所述提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：对所述提案消息进行验签，验证通过后，根据所述提案消息生成写入消息；其中，所述写入消息包括本轮共识标识和签名；将所述写入消息广播至当前网络中的所有节点；对接收到的所述写入消息进行验签和共识规则判定，判定通过后，根据所述写入消息生成接收消 息；其中，所述接收消息包括本轮共识标识和签名；将所述接收消息广播至当前网络中的所有节点；对接收到的所述接收消息进行验签和共识规则判定。
本发明还提供了一种区块链共识方法，应用于中等优先级网络中的主节点，包括：接收最高优先级网络中的主节点发送的提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络。
本发明还提供了一种区块链共识方法，应用于与客户端处于同一网络中的对等节点，包括：接收所述客户端发送的交易消息，并对其进行验签；验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点。可选地，所述方法还包括：接收提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并向所述客户端发送应答消息。
图6是根据本发明一个可参考实施例的区块链共识方法的主要流程的示意图。下面以只有两级Leader节点的实例对整个过程进行详细说明，所述区块链共识方法可以包括以下步骤：
步骤601，客户端将交易消息发送至与Peer11节点、Peer12节点、Peer14节点和Leader10节点。
具体地，客户端可以先对交易数据进行哈希处理，然后采用客户端私钥对哈希数值进行处理，从而得到客户端的签名。如果没有提前向各个节点广播客户端的公钥，所述交易消息还要携带客户端的公钥，以供节点验证客户端签名。
由于Peer11节点、Peer12节点、Peer14节点和Leader10节点与客户端处于同一网络中，且均与客户端建立连接，因此在确保交易消息的合法性后，客户端广播交易消息，Peer11节点、Peer12节点、Peer14节点和Leader10节点分别接收到交易消息。
需要指出的是，为了简化示意图，图6中示例性地示出了Peer11节点接收交易消息的过程。而且，客户端也可以将交易消息发送至Peer11节点、Peer12节点和Peer13节点，还可以是Peer12节点和Peer13节点，本发明实施例对此不作限制，以防止单独节点作弊。
步骤602，Peer11节点接收所述客户端发送的交易消息，并对其进行验签；验签通过后，在所述交易消息上附加上Peer11节点的签名，并将所述交易消息发送至Leader10节点。Peer12节点和Peer14节点的验签、签名过程与Peer11节点类似，不再赘述。
步骤603，Leader10节点接收所述客户端发送的交易消息和Peer11节点、Peer12节点、Peer14节点发送交易消息，并分别对其进行验签；验签通过后，判断接收到的各个交易消息中的交易数据是否一致；若是，则在所述交易消息上附加上Leader10节点的签名，并将所述交易消息发送至上一级网络中的Leader00节点。
如果Leader10节点接收到Peer节点发送的交易消息，则先对Peer节点的签名进行验证，验签通过后，再对客户端签名进行验签，以获得交易数据。
步骤604，Leader00节点根据接收到的交易消息生成提案消息，并将所述提案消息发送至Leader00节点以及Peer01节点、Peer02节点、Peer03节点、Peer04节点。
为了简化示意图，图6中示例性地示出了Peer01节点和Peer02节点，与Leader00节点处于同一网络中的各个Peer节点的执行过程类似，不再赘述。
步骤605，Leader00节点、Peer01节点、Peer02节点、Peer03节点、Peer04节点，对所述提案消息进行验签，验证通过后，根据所述提案消息生成Write消息，并将Write消息广播至当前网络中的所有节点。
无论是Peer节点还是Leader节点都对接收到的提案消息进行签名验证和CID的顺序性确认；验证通过后，向当前网络中的其他节点和当前节点自身广播Write消息，Write消息不需要含有具体消息内容，只需要CID和签名即可。
步骤606，Leader00节点、Peer01节点、Peer02节点、Peer03节点、Peer04节点，接收Write消息，对Write消息进行验签和共识规则判定，判定通过后，根据Write消息生成Accpet消息，并将Accpet消息广播至当前网络中的所有节点。
具体地，主要进行CID顺序性确认，通过Hash验证签名，通过法定规则(N≥3f+1原则)进行共识规则判定。
步骤607，Leader00节点、Peer01节点、Peer02节点、Peer03节点、Peer04节点，接收Accpet消息，并对Accpet消息进行验签和共识规则判定；若判定通过，则表明本轮共识成功。
步骤608，Leader00节点将提案消息中的交易数据写入区块，并对将所述提案消息签名后发送至下一级网络中的Leader10节点；Peer01节点、Peer02节点、Peer03节点、Peer04节点，将提案消息中的交易数据写入区块。
步骤609，Leader10节点接收所述提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上Leader10节点的签名后广播至Peer11节点、Peer12节点、Peer13节点、Peer14节点。
步骤610，Peer11节点、Peer12节点、Peer13节点、Peer14节点接收Leader10节点发送的提案消息，并对所述提案消息进行验签；验签通过后，将提案消息中的交易数据写入区块。
步骤611，验签通过后，Peer11节点、Peer12节点、Peer14节点和Leader10节点还可以向客户端发送应答消息。
另外，在本发明一个可参考实施例中区块链共识方法的具体实施内容，在上面所述区块链共识方法中已经详细说明了，故在此重复内容不再说明。
图7是根据本发明一个实施例的区块链共识装置的主要模块的示意图。如图7所示，所述区块链共识装置700设置于与客户端处于同一网络中的主节点，包括：第一接收模块701，用于接收所述客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少 两个对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；第一发送模块702，用于判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
可选地，所述交易消息包括交易数据和客户端的签名；
接收客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息，包括：
接收客户端发送的交易消息和至少一个对等节点发送交易消息，并分别对其进行验签；或者，接收至少两个对等节点发送的交易消息，并分别对其进行验签；
其中，所述对等节点发送的交易消息包括所述客户端发送的交易消息和所述对等节点的签名。
可选地，判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点，包括：
基于多数原则判断接收到的各个交易消息中的交易数据是否一致；
若是，则在所述交易消息上附加上所述主节点的签名，并将所述交易消息发送至上一级网络中的主节点。
图8是根据本发明另一个实施例的区块链共识装置的主要模块的示意图。如图8所示，所述区块链共识装置800设置于最高优先级网络中的主节点，包括：提案模块801，用于根据接收到的交易消息生成提案消息；共识模块802，用于基于拜占庭容错共识机制对所述提案消息进行共识判定；第二发送模块803，用于共识判定通过后，将所述提案消息发送至下一级网络中的主节点。
可选地，根据接收到的交易消息生成提案消息，包括：
根据预设时间段内接收到的交易消息或者预设数量的交易消息，生成提案消息；
其中，所述提案消息包括数据列表、本轮共识标识、所述最高优先级网络中的主节点标识和所述最高优先级网络中的主节点的签名。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：
将所述提案消息发送至所述主节点自身和所述最高优先级网络中的对等节点；
接收所述提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：
对所述提案消息进行验签，验证通过后，根据所述提案消息生成写入消息；其中，所述写入消息包括本轮共识标识和签名；
将所述写入消息广播至当前网络中的所有节点；
对接收到的所述写入消息进行验签和共识规则判定，判定通过后，根据所述写入消息生成接收消息；其中，所述接收消息包括本轮共识标识和签名；
将所述接收消息广播至当前网络中的所有节点；
对接收到的所述接收消息进行验签和共识规则判定。
本发明实施例还提供了一种区块链共识装置，设置于中等优先级网络中的主节点，包括：第二接收模块，用于接收最高优先级网络中的主节点发送的提案消息，对所述提案消息进行验签；写入模块，用于验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络。
根据本发明实施例还提供了一种区块链共识装置，设置于与客户端处于同一网络中的对等节点，包括：第三接收模块，用于接收所述客户端发送的交易消息，并对其进行验签；第三发送模块，用于验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点。
可选地，还包括：第四接收模块，用于接收提案消息，对所述提 案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并向所述客户端发送应答消息。
本发明还提供了一种区块链共识系统，包括：客户端，用于将交易消息发送至与所述客户端处于同一网络中的至少两个节点；其中，所述至少两个节点包括主节点和对等节点中的至少两个；与所述客户端处于同一网络中的主节点，用于接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高；最高优先级网络中的主节点，用于根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为所述客户端所处的网络。
可选地，所述交易消息包括交易数据和客户端的签名；
所述系统还包括：与所述客户端处于同一网络中的对等节点，用于接收所述客户端发送的交易消息，并对其进行验签；验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点；或者，
与所述客户端处于同一网络中的主节点还用于：接收所述客户端发送的交易消息和至少一个所述对等节点发送交易消息，并分别对其进行验签；或者，接收至少两个所述对等节点发送的交易消息，并分别对其进行验签。
可选地，与所述客户端处于同一网络中的主节点还用于：基于多数原则判断接收到的各个交易消息中的交易数据是否一致；若是，则在所述交易消息上附加上所述主节点的签名，并将所述交易消息发送至上一级网络中的主节点；
所述系统还包括：所述上一级网络中的主节点，用于对接收到的交易消息进行验签；验签通过后，在所述交易消息上附加上所述主节点的签名，并将所述交易消息发送至上一级网络中的主节点；直到所 述上一级网络的优先级为最高。
可选地，所述最高优先级网络中的主节点还用于：
根据预设时间段内接收到的交易消息或者预设数量的交易消息，生成提案消息；
其中，所述提案消息包括数据列表、本轮共识标识、所述最高优先级网络中的主节点标识和所述最高优先级网络中的主节点的签名。
可选地，所述系统还包括所述最高优先级网络中的对等节点；
所述最高优先级网络中的主节点还用于：将所述提案消息发送至所述主节点自身和所述最高优先级网络中的对等节点；
所述主节点和所述对等节点，用于接收所述提案消息，并分别基于拜占庭容错共识机制对所述提案消息进行共识判定。
可选地，基于拜占庭容错共识机制对所述提案消息进行共识判定，包括：
对所述提案消息进行验签，验证通过后，根据所述提案消息生成写入消息；其中，所述写入消息包括本轮共识标识和签名；
将所述写入消息广播至当前网络中的所有节点；
对接收到的所述写入消息进行验签和共识规则判定，判定通过后，根据所述写入消息生成接收消息；其中，所述接收消息包括本轮共识标识和签名；
将所述接收消息广播至当前网络中的所有节点；
对接收到的所述接收消息进行验签和共识规则判定。
可选地，所述最高优先级网络中的主节点还用于：将所述提案消息发送至下一级网络中的主节点；
所述下一级网络中的主节点还用于：接收所述提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络；
与所述主节点处于同一网络中的对等节点用于：接收所述主节点 发送的提案消息，并对所述提案消息进行验签；验签通过后，将提案消息中的交易数据写入区块。
可选地，与所述客户端处于同一网络中且与所述客户端建立连接的至少两个节点还用于：接收所述提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并向所述客户端发送应答消息。
根据上面所述的各种实施例，可以看出本发明通过基于拜占庭容错共识机制对提案消息进行共识判定，共识判定通过后，将提案消息发送至下一级网络中的主节点，直到下一级网络为客户端所处的网络的技术手段，从而解决了现有技术中交易确认时间长、区块承载的交易量小的技术问题。本发明实施例在点对点网络环境下，利用密码学算法保证数据一致性的前提下，基于拜占庭容错共识机制进行共识，可有效提高共识效率；在实际共识过程中，采用分层级区域内共识机制，通过共识在小范围内达成，并下达广播的方式，一方面与点对点网络非常契合，另一方面可减少了挖矿带来的资源浪费，从而有效提高共识效率。
需要说明的是，在本发明所述区块链共识系统的具体实施内容，在上面所述区块链共识方法中已经详细说明了，故在此重复内容不再说明。
图9示出了可以应用本发明实施例的区块链共识方法或区块链共识系统的示例性系统架构900。
如图9所示，系统架构900可以包括终端设备901、902、903，网络904和服务器905。网络904用以在终端设备901、902、903和服务器905之间提供通信链路的介质。网络904可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备901、902、903通过网络904与服务器904交互，以接收或发送消息等。终端设备901、902、903上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备901、902、903可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器905可以是提供各种服务的服务器，例如对用户利用终端设备901、902、903所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息——仅为示例)反馈给终端设备。
应该理解，图9中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
下面参考图10，其示出了适于用来实现本发明实施例的终端设备的计算机系统1000的结构示意图。图10示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图10所示，计算机系统1000包括中央处理单元(CPU)1001，其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。在RAM 1003中，还存储有系统1000操作所需的各种程序和数据。CPU 1001、ROM 1002以及RAM1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。
以下部件连接至I/O接口1005：包括键盘、鼠标等的输入部分1006；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1007；包括硬盘等的存储部分1008；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1009。通信部分1009经由诸如因特网的网络执行通信处理。驱动器1010也根据需要连接至I/O接口1005。可拆卸介质1011，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1010上，以便于从其上读出的计算机程序根据需要被安装入存储部分1008。
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种 计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1009从网络上被下载和安装，和/或从可拆卸介质1011被安装。在该计算机程序被中央处理单元(CPU)1001执行时，执行本发明的系统中限定的上述功能。
需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的 实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括第一接收模块和第一发送模块，其中，这些模块的名称在某种情况下并不构成对该模块本身的限定。
作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：接收所述客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
根据本发明实施例的技术方案，因为采用基于拜占庭容错共识机制对提案消息进行共识判定，共识判定通过后，将提案消息发送至下一级网络中的主节点，直到下一级网络为客户端所处的网络的技术手段，所以克服了现有技术中交易确认时间长、区块承载的交易量小的技术问题。本发明实施例在点对点网络环境下，利用密码学算法保证数据一致性的前提下，基于拜占庭容错共识机制进行共识，可有效提高共识效率；在实际共识过程中，采用分层级区域内共识机制，通过共识在小范围内达成，并下达广播的方式，一方面与点对点网络非常契合，另一方面可减少了挖矿带来的资源浪费，从而有效提高共识效 率。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (18)

  1. 一种区块链共识方法，其应用于与客户端处于同一网络中的主节点，所述方法包括：
    接收所述客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；
    判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
  2. 根据权利要求1所述的方法，其中，所述交易消息包括交易数据和客户端的签名；
    所述接收客户端发送的交易消息和至少一个对等节点发送的交易消息、或者接收至少两个对等节点发送的交易消息包括：
    接收客户端发送的交易消息和至少一个对等节点发送交易消息，并分别对其进行验签；或者，接收至少两个对等节点发送的交易消息，并分别对其进行验签；
    其中，所述对等节点发送的交易消息包括所述客户端发送的交易消息和所述对等节点的签名。
  3. 根据权利要求1所述的方法，其中，所述判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点进一步包括：
    基于多数原则判断接收到的各个交易消息中的交易数据是否一致；
    若是，则在所述交易消息上附加上所述主节点的签名，并将所述交易消息发送至上一级网络中的主节点。
  4. 一种区块链共识方法，其应用于最高优先级网络中的主节点，所述方法包括：
    根据接收到的交易消息生成提案消息；
    基于拜占庭容错共识机制对所述提案消息进行共识判定；
    共识判定通过后，将所述提案消息发送至下一级网络中的主节点。
  5. 根据权利要求4所述的方法，其中，所述根据接收到的交易消息生成提案消息进一步包括：
    根据预设时间段内接收到的交易消息或者预设数量的交易消息，生成提案消息；
    其中，所述提案消息包括数据列表、本轮共识标识、所述最高优先级网络中的主节点标识和所述最高优先级网络中的主节点的签名。
  6. 根据权利要求4所述的方法，其中，所述基于拜占庭容错共识机制对所述提案消息进行共识判定进一步包括：
    将所述提案消息发送至所述主节点自身和所述最高优先级网络中的对等节点；
    接收所述提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定。
  7. 根据权利要求6所述的方法，其中，所述基于拜占庭容错共识机制对所述提案消息进行共识判定进一步包括：
    对所述提案消息进行验签，验证通过后，根据所述提案消息生成写入消息；其中，所述写入消息包括本轮共识标识和签名；
    将所述写入消息广播至当前网络中的所有节点；
    对接收到的所述写入消息进行验签和共识规则判定，判定通过后，根据所述写入消息生成接收消息；其中，所述接收消息包括本轮共识标识和签名；
    将所述接收消息广播至当前网络中的所有节点；以及
    对接收到的所述接收消息进行验签和共识规则判定。
  8. 一种区块链共识方法，其应用于中等优先级网络中的主节点，所述方法包括：
    接收最高优先级网络中的主节点发送的提案消息，对所述提案消息进行验签；
    验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络。
  9. 一种区块链共识方法，其应用于与客户端处于同一网络中的对等节点，所述方法包括：
    接收所述客户端发送的交易消息，并对其进行验签；
    验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点。
  10. 根据权利要求9所述的方法，进一步包括：
    接收提案消息，对所述提案消息进行验签；验签通过后，将所述提案消息中的交易数据写入区块，并向所述客户端发送应答消息。
  11. 一种区块链共识装置，其设置于与客户端处于同一网络中的主节点，所述装置包括：
    第一接收模块，用于接收所述客户端发送的交易消息和至少一个对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；其中，所述对等节点与所述主节点、所述客户端均处于同一网络中；
    第一发送模块，用于判断接收到的所述交易消息是否一致，若是，则将交易消息发送至上一级网络中的主节点。
  12. 一种区块链共识装置，其设置于最高优先级网络中的主节点，所述装置包括：
    提案模块，用于根据接收到的交易消息生成提案消息；
    共识模块，用于基于拜占庭容错共识机制对所述提案消息进行共识判定；
    第二发送模块，用于共识判定通过后，将所述提案消息发送至下一级网络中的主节点。
  13. 一种区块链共识装置，其设置于中等优先级网络中的主节点，所述装置包括：
    第二接收模块，用于接收最高优先级网络中的主节点发送的提案消息，对所述提案消息进行验签；
    写入模块，用于验签通过后，将所述提案消息中的交易数据写入区块，并在所述提案消息上附加上所述主节点的签名，将所述提案消息发送至与所述主节点处于同一网络中的对等节点和下一级网络中的主节点；直到所述下一级网络为所述客户端所处的网络。
  14. 一种区块链共识装置，其设置于与客户端处于同一网络中的对等节点，所述装置包括：
    第三接收模块，用于接收所述客户端发送的交易消息，并对其进行验签；
    第三发送模块，用于验签通过后，在所述交易消息上附加上所述对等节点的签名，并将所述交易消息发送至与所述对等节点处于同一网络中的主节点。
  15. 一种区块链共识方法，包括：
    客户端将交易消息发送至与所述客户端处于同一网络中的至少两个节点；其中，所述至少两个节点包括主节点和对等节点中的至少两 个；
    与所述客户端处于同一网络中的主节点接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高；
    最高优先级网络中的主节点根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为所述客户端所处的网络。
  16. 一种区块链共识系统，包括：
    客户端，用于将交易消息发送至与所述客户端处于同一网络中的至少两个节点；其中，所述至少两个节点包括主节点和对等节点中的至少两个；
    与所述客户端处于同一网络中的主节点，用于接收所述客户端发送的交易消息和至少一个所述对等节点发送的交易消息，或者，接收至少两个所述对等节点发送的交易消息；若所述交易消息中的交易数据一致，则将交易消息发送至上一级网络中的主节点，直到所述上一级网络的优先级为最高；
    最高优先级网络中的主节点，用于根据接收到的交易消息生成提案消息，并基于拜占庭容错共识机制对所述提案消息进行共识判定；共识判定通过后，将所述提案消息发送至下一级网络中的主节点，直到所述下一级网络为所述客户端所处的网络。
  17. 一种电子设备，包括：
    一个或多个处理器；
    存储装置，用于存储一个或多个程序，
    当所述一个或多个程序被所述一个或多个处理器执行，使得所述 一个或多个处理器实现如权利要求1-10中任一所述的方法。
  18. 一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现如权利要求1-10中任一所述的方法。
PCT/CN2020/077518 2019-06-26 2020-03-03 一种区块链共识方法、装置和系统 WO2020258912A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US17/616,543 US20220239496A1 (en) 2019-06-26 2020-03-03 Blockchain consensus method, device and system
JP2021568814A JP2022533396A (ja) 2019-06-26 2020-03-03 ブロックチェーンコンセンサス方法、装置及びシステム
KR1020217040523A KR102566892B1 (ko) 2019-06-26 2020-03-03 블록체인 합의 방법, 디바이스 및 시스템
JP2023184790A JP2024010123A (ja) 2019-06-26 2023-10-27 ブロックチェーンコンセンサス方法、装置及びシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910560228.9A CN112150141A (zh) 2019-06-26 2019-06-26 一种区块链共识方法、装置和系统
CN201910560228.9 2019-06-26

Publications (1)

Publication Number Publication Date
WO2020258912A1 true WO2020258912A1 (zh) 2020-12-30

Family

ID=73869776

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/077518 WO2020258912A1 (zh) 2019-06-26 2020-03-03 一种区块链共识方法、装置和系统

Country Status (5)

Country Link
US (1) US20220239496A1 (zh)
JP (2) JP2022533396A (zh)
KR (1) KR102566892B1 (zh)
CN (1) CN112150141A (zh)
WO (1) WO2020258912A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113179166A (zh) * 2021-04-13 2021-07-27 华东师范大学 基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法
CN113364874A (zh) * 2021-06-09 2021-09-07 网易（杭州）网络有限公司 基于区块链的节点同步方法、装置、存储介质及服务器
CN115002221A (zh) * 2022-06-06 2022-09-02 长春理工大学 一种适用于物联网的区块链共识方法及系统
CN116720917A (zh) * 2023-06-16 2023-09-08 深圳职业技术学院 一种分布式碳交易市场共识方法

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112634054A (zh) * 2021-01-11 2021-04-09 杭州复杂美科技有限公司 交易执行方法、区块链一体机和区块链网络
CN115499128A (zh) * 2021-06-01 2022-12-20 中移雄安信息通信科技有限公司 区块链共识方法、装置、系统及存储介质
CN113489792B (zh) * 2021-07-07 2023-02-03 上交所技术有限责任公司 一种在跨数据中心集群共识算法中减少数据中心间网络传输次数的方法
CN113922864B (zh) * 2021-10-09 2023-07-28 郑州大学 一种基于拜占庭共识的多层卫星网络安全保障方法
KR20230115721A (ko) * 2022-01-27 2023-08-03 주식회사 미디움 블록체인 합의 방법, 블록체인 합의 장치, 블록체인 합의 방법을 수행하는 컴퓨터 프로그램 및 합의 방법이 저장된 프로그램이 저장된 컴퓨터 프로그램 기록매체
KR102439351B1 (ko) * 2022-02-10 2022-09-01 주식회사 스카이플레이 Esg를 위한 비채굴 블록체인 네트워크 시스템 및 그 시스템에 참여하는 서버 노드의 동작 방법
CN117411894A (zh) * 2022-07-08 2024-01-16 腾讯科技（深圳）有限公司 共识网络的数据处理方法、装置、程序产品、设备和介质
CN117221332B (zh) * 2023-06-08 2024-04-12 天津大学 基于多领导者拜占庭容错共识的高鲁棒性交易打包方法
CN116566995B (zh) * 2023-07-10 2023-09-22 安徽中科晶格技术有限公司 一种基于分类、聚类算法的区块链数据传输方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107392608A (zh) * 2017-07-11 2017-11-24 北京博晨技术有限公司 基于区块链系统的数字资产交易方法及区块链系统
CN108134706A (zh) * 2018-01-02 2018-06-08 中国工商银行股份有限公司 区块链多活高可用系统、计算机设备以及方法
CN109039847A (zh) * 2018-08-07 2018-12-18 广州三牛信息科技有限公司 一种利用dmt解决区块链全网消息一致性问题的方法及装置
CN109819003A (zh) * 2017-11-22 2019-05-28 南京理工大学 一种区块链的分层共识方法和系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018125989A2 (en) * 2016-12-30 2018-07-05 Intel Corporation The internet of things
CN106789095B (zh) * 2017-03-30 2020-12-08 腾讯科技（深圳）有限公司 分布式系统及消息处理方法
CA3065319A1 (en) * 2017-06-01 2018-12-06 Schvey, Inc. d/b/a/ Axoni Distributed privately subspaced blockchain data structures with secure access restriction management
US20190251199A1 (en) * 2018-02-14 2019-08-15 Ivan Klianev Transactions Across Blockchain Networks
US20190305957A1 (en) * 2018-04-02 2019-10-03 Ca, Inc. Execution smart contracts configured to establish trustworthiness of code before execution
CN108665365B (zh) * 2018-05-16 2021-07-13 四川大学 一种混合区块链架构系统、处理方法及处理系统
CN108984662B (zh) * 2018-06-28 2021-02-09 杭州复杂美科技有限公司 一种区块链数据同步方法
US11270017B2 (en) * 2018-10-16 2022-03-08 International Business Machines Corporation Selective exchange of transaction data

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107392608A (zh) * 2017-07-11 2017-11-24 北京博晨技术有限公司 基于区块链系统的数字资产交易方法及区块链系统
CN109819003A (zh) * 2017-11-22 2019-05-28 南京理工大学 一种区块链的分层共识方法和系统
CN108134706A (zh) * 2018-01-02 2018-06-08 中国工商银行股份有限公司 区块链多活高可用系统、计算机设备以及方法
CN109039847A (zh) * 2018-08-07 2018-12-18 广州三牛信息科技有限公司 一种利用dmt解决区块链全网消息一致性问题的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LIBO FENG, HUI ZHANG, YONG CHEN, LIQI LOU: "Scalable Dynamic Multi-Agent Practical Byzantine Fault-Tolerant Consensus in Permissioned Blockchain", APPLIED SCIENCES, MDPI, BASEL, SWITZERLAND, vol. 8, no. 10, Basel, Switzerland, pages 1 - 21, XP055723251, ISSN: 2076-3417, DOI: 10.3390/app8101919 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113179166A (zh) * 2021-04-13 2021-07-27 华东师范大学 基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法
CN113179166B (zh) * 2021-04-13 2022-07-08 华东师范大学 基于高鲁棒性拜占庭容错的联盟链数据安全实时上链方法
CN113364874A (zh) * 2021-06-09 2021-09-07 网易（杭州）网络有限公司 基于区块链的节点同步方法、装置、存储介质及服务器
CN113364874B (zh) * 2021-06-09 2022-06-10 网易（杭州）网络有限公司 基于区块链的节点同步方法、装置、存储介质及服务器
CN115002221A (zh) * 2022-06-06 2022-09-02 长春理工大学 一种适用于物联网的区块链共识方法及系统
CN115002221B (zh) * 2022-06-06 2023-06-23 长春理工大学 一种适用于物联网的区块链共识方法及系统
CN116720917A (zh) * 2023-06-16 2023-09-08 深圳职业技术学院 一种分布式碳交易市场共识方法

Also Published As

Publication number Publication date
US20220239496A1 (en) 2022-07-28
KR20220006623A (ko) 2022-01-17
KR102566892B1 (ko) 2023-08-11
JP2024010123A (ja) 2024-01-23
CN112150141A (zh) 2020-12-29
JP2022533396A (ja) 2022-07-22

Similar Documents

Publication Publication Date Title
WO2020258912A1 (zh) 一种区块链共识方法、装置和系统
WO2020168937A1 (zh) 区块链多方见证方法、装置、设备及计算机可读存储介质
JP6985576B2 (ja) ビジネスプロセスシステム、ビジネスデータ処理方法及び装置
US11502854B2 (en) Transparently scalable virtual hardware security module
US10104181B1 (en) Secure context-based group collaboration and communication
WO2018177124A1 (zh) 业务处理方法、装置、数据共享系统及存储介质
WO2018076759A1 (zh) 基于区块链的多链管理方法、系统、电子装置及存储介质
US20210304201A1 (en) Transaction verification method and apparatus, storage medium, and electronic device
JP2020516105A (ja) 分散システムにおけるネットワークノードに対する回復処理の実行
US11777914B1 (en) Virtual cryptographic module with load balancer and cryptographic module fleet
US9641340B2 (en) Certificateless multi-proxy signature method and apparatus
WO2022121538A1 (zh) 基于区块链的数据同步方法、系统及相关设备
JP2024505692A (ja) ブロックチェーンネットワークに基づくデータ処理方法、装置及びコンピュータ機器
CN111125781B (zh) 一种文件签名方法、装置和文件签名验证方法、装置
WO2022057275A1 (zh) 校验数据的方法、装置、设备和计算机可读介质
CN113055188A (zh) 一种数据处理方法、装置、设备及存储介质
CN113206746B (zh) 一种数字证书管理方法和装置
WO2022088710A1 (zh) 一种镜像管理方法及装置
WO2023231558A1 (zh) 区块链共识方法、装置、介质、电子设备和程序产品
WO2024021406A1 (zh) 一种防范网络攻击的方法及装置
CN113873004B (zh) 一种任务执行方法和装置以及分布式计算系统
CN113179169B (zh) 一种数字证书管理方法和装置
CN113206738B (zh) 一种数字证书管理方法和装置
CN113242132B (zh) 一种数字证书管理方法和装置
CN112994882B (zh) 基于区块链的鉴权方法、装置、介质及设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20830581

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021568814

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20217040523

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS (EPO FORM 1205A DATED 14.04.2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20830581

Country of ref document: EP

Kind code of ref document: A1