WO2022134233A1 - 一种区块链的共识方法、装置、服务器及存储介质 - Google Patents

一种区块链的共识方法、装置、服务器及存储介质 Download PDF

Info

Publication number
WO2022134233A1
WO2022134233A1 PCT/CN2021/071152 CN2021071152W WO2022134233A1 WO 2022134233 A1 WO2022134233 A1 WO 2022134233A1 CN 2021071152 W CN2021071152 W CN 2021071152W WO 2022134233 A1 WO2022134233 A1 WO 2022134233A1
Authority
WO
WIPO (PCT)
Prior art keywords
consensus
round
blockchain
master node
target
Prior art date
Application number
PCT/CN2021/071152
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 杭州趣链科技有限公司
Publication of WO2022134233A1 publication Critical patent/WO2022134233A1/zh
Priority to US18/340,102 priority Critical patent/US20230334930A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C13/00—Voting apparatus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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

Definitions

  • the present application relates to the technical field of blockchain, and in particular to a consensus method, device, server and storage medium for blockchain.
  • consistency is an indispensable and important attribute, which also includes two consistency attributes of transaction sequence consistency and state consistency.
  • transaction sequence consistency In order to ensure the consistency of the blockchain system, it is usually necessary to introduce a consensus algorithm to ensure that all nodes execute the same transaction sequence in a consistent order (transaction sequence consistency).
  • transaction sequence consistency In addition, an additional state comparison scheme needs to be introduced To ensure that the execution results of all nodes are consistent (state consistency).
  • the consensus algorithm under the existing technology couples the consensus and transaction execution, which affects the stability of the consensus; and different master nodes in the blockchain build different proposal blocks on the basis of the latest local block, resulting in memory resources. waste. At the same time, it is necessary to record the content and execution results of all blocks in real time, maintain a huge number of historical states, and increase the design complexity of the execution module.
  • This application provides a consensus method for blockchain.
  • checkpoint rounds it is unnecessary to wait for the transaction execution results of all nodes synchronously in each consensus round, which reduces the impact of transaction execution on consensus and improves consensus. stability.
  • the newly created block includes the execution result and status of the previous block in the blockchain, and only the newly created block is checked for consistency, avoiding the waste of memory resources and computing resources.
  • the checkpoint round can be flexibly customized, which improves the scalability of the consensus algorithm.
  • the present application provides a consensus method for a blockchain
  • the blockchain includes multiple nodes, and the multiple nodes are connected to each other;
  • the blockchain has multiple consensus rounds during operation to Consensus is performed on the transactions executed on the blockchain, the multiple consensus rounds include a checkpoint round, and in one of the consensus rounds, the multiple nodes include a master node and a target node,
  • the target node is any node among all the nodes in the plurality of nodes except the master node; after the target transaction is executed in the blockchain, a consensus proposal message for the target transaction will be generated;
  • the method includes:
  • the master node receives the first set of voting results generated by the plurality of nodes for the consensus proposal message in the second consensus round, and the first The second consensus round is one consensus round before the first consensus round;
  • the master node In the first consensus round, the master node generates a first consensus proposal block for the consensus proposal message, and the consensus proposal message includes the first consensus proposal block, the second consensus round the first set of voting results and the target transaction;
  • the master node determines that the second consensus round is the checkpoint round according to the first voting result
  • the master node determines whether the blockchain reaches a consensus on the target transaction according to the first voting result.
  • the master node determines that the second consensus round is the checkpoint round according to the first voting result, including:
  • the master node determines whether it has received the first preset number of first voting results
  • the master node determines that the second consensus round is the checkpoint round.
  • the master node determines whether it has received the first preset number of first voting results, including:
  • the host determines whether the second consensus round is the checkpoint round.
  • the target node in the second consensus round, the target node generates a transaction corresponding to the target transaction.
  • transaction execution results the first voting result set generated in the second consensus round includes the transaction execution results, and the first voting result set generated in the second consensus round includes multiple transaction execution results;
  • the master node determines whether the blockchain reaches a consensus on the target transaction according to the first voting result, including:
  • the master node determines whether multiple transaction execution results in the first voting result set generated in the second consensus round are consistent
  • the master node If the transaction execution results of the second preset number of nodes are consistent, the master node generates checkpoint information, and aggregates the checkpoint information in the first voting result set generated in the second consensus round middle;
  • the master node determines whether the transaction execution result generated by itself according to the target transaction is consistent with the transaction execution result in the first voting result set generated in the second consensus round;
  • the master node determines whether the transaction execution result generated by itself according to the target transaction and the transaction execution result in the first voting result set generated in the second consensus round are not Consistent, including:
  • the method further includes:
  • the master node waits for this consensus to time out
  • the method for switching the master node includes:
  • Number the multiple nodes in the blockchain according to the sequence of the chain structure take the first node in the chain structure as the initial master node; when the master node needs to be switched, follow the sequence of numbers The master nodes are switched in sequence.
  • the method further includes: if the second consensus round is not the checkpoint round, the master node re-aggregates the other nodes in the first consensus round.
  • the first voting result generated by the consensus round generates a second voting result set;
  • the method further includes:
  • the new master node constructs a second proposal block on the basis of the first proposal block, and the second proposal block includes the second voting result set, the consensus proposal message and the target transaction.
  • the present application provides a consensus method for a blockchain
  • the blockchain includes multiple nodes, and the multiple nodes are connected to each other;
  • the blockchain has multiple consensuses during operation rounds to perform consensus on transactions executed on the blockchain, the plurality of consensus rounds include a checkpoint round, and in one of the consensus rounds, the plurality of nodes include a master node and a The target node, the target node is any node among all the nodes in the multiple nodes except the master node; after the target transaction is executed in the blockchain, a consensus on the target transaction will be generated proposal message;
  • the method includes: in a first consensus round of the plurality of consensus rounds, the target node receives a consensus proposal message from the master node, the consensus proposal message includes the plurality of nodes in the consensus proposal message. A set of first voting results generated for the consensus proposal message in the second consensus round, where the second consensus round is a consensus round before the first consensus round;
  • the target node determines whether the first consensus round it is in is the checkpoint round
  • the target node obtains the transaction execution result corresponding to the target transaction, and the transaction execution result is encapsulated in the target node in the first consensus round in the first voting result generated in the second;
  • the target node sends the first voting result including the transaction execution result to the master node.
  • the method before the target node determines whether the first consensus round it is in is the checkpoint round, the method further includes:
  • the target node judges whether the consensus proposal message includes checkpoint information
  • the target node determines whether it has reached a consensus on the target transaction according to the checkpoint information.
  • the method further includes:
  • the target node If the first consensus round is not the checkpoint round, the target node generates a first voting result for the consensus proposal message, and sends it to the master node;
  • the first voting result does not include the transaction execution result obtained by the target node for the target transaction.
  • the present application also provides a consensus device for a blockchain, which is applied to a blockchain, wherein the blockchain includes multiple nodes, and the multiple nodes are connected to each other; the blockchain is in the The runtime is provided with multiple consensus rounds to achieve consensus on the transactions executed on the blockchain, the multiple consensus rounds include a checkpoint round, and within one of the consensus rounds, the multiple consensus rounds
  • the node includes a master node and a target node, and the target node is any node among all other nodes in the multiple nodes except the master node; the target transaction will be generated after the execution of the target transaction in the blockchain A consensus proposal message for the target transaction;
  • the device includes:
  • a first receiving module configured to receive, in the first consensus round of the plurality of consensus rounds, the messages generated by the plurality of nodes for the consensus proposal message in the second consensus round.
  • the first set of voting results, the second consensus round is a consensus round before the first consensus round;
  • a proposal block generation module configured to generate a first consensus proposal block for the consensus proposal message in the first consensus round, and the consensus proposal message includes the first consensus proposal block The consensus proposal block, the first set of voting results in the second consensus round, and the target transaction;
  • the second receiving module is configured to receive the first voting result generated by the target node for the consensus proposal message
  • the first judging module is configured to judge that the second consensus round is the checkpoint round according to the first voting result
  • a second judgment module the second judgment module is configured to judge whether the blockchain reaches a consensus on the target transaction according to the first voting result if the second consensus round is the checkpoint round .
  • the first judgment module is mainly used for the master node to judge whether it has received the first preset number of first voting results; if so, the master node determines that the second consensus round is Checkpoint rounds.
  • the second judgment module is mainly used for the master node to judge the first voting result set generated in the second consensus round if the second consensus round is the checkpoint round. Whether the execution results of multiple transactions are consistent; if the transaction execution results of the second preset number of nodes are consistent, the master node generates checkpoint information, and aggregates the checkpoint information into the first set of voting results generated in the second consensus round. The master node judges whether the transaction execution result generated by itself based on the target transaction is consistent with the transaction execution result in the first voting result set generated in the second consensus round; if the transaction execution result generated by the master node itself is consistent with the second consensus round If the transaction execution results in the first voting result set generated in the consensus round are consistent, it is determined that the blockchain reaches a consensus on the target transaction.
  • the present application also provides a consensus device for a blockchain, which is applied to a blockchain, wherein the blockchain includes multiple nodes, and the multiple nodes are connected to each other; the blockchain is in the The runtime is provided with multiple consensus rounds to achieve consensus on the transactions executed on the blockchain, the multiple consensus rounds include a checkpoint round, and within one of the consensus rounds, the multiple consensus rounds
  • the node includes a master node and a target node, and the target node is any node among all other nodes in the multiple nodes except the master node; the target transaction will be generated after the execution of the target transaction in the blockchain A consensus proposal message for the target transaction;
  • the device includes:
  • a third receiving module configured to receive a consensus proposal message from the master node in the first consensus round among the plurality of consensus rounds, where the consensus proposal message includes the a first set of voting results generated by multiple nodes for the consensus proposal message in a second consensus round, where the second consensus round is a consensus round before the first consensus round;
  • a third judging module where the third judging module is used to judge whether the first consensus round it is in is the checkpoint round
  • An obtaining module configured to obtain a transaction execution result corresponding to the target transaction if the first consensus round is the checkpoint round, and the transaction execution result is encapsulated in the target node where the in the first voting result generated in the first consensus round;
  • a sending module configured to send the first voting result including the transaction execution result to the master node.
  • the present application also provides a server, the server comprising:
  • processors one or more processors
  • One or more application programs wherein the one or more application programs are stored in the memory and configured to be executed by the processor to implement the consensus method of a blockchain as described in any of the above.
  • the present application also provides a computer-readable storage medium on which a computer program is stored, and the computer program is loaded by a processor to execute the steps in the blockchain consensus method described in any of the above .
  • This application provides a consensus method for blockchain.
  • checkpoint rounds it is unnecessary to wait for the transaction execution results of all nodes synchronously in each consensus round, which reduces the impact of transaction execution on consensus and improves consensus. stability.
  • the newly created block includes the execution result and status of the previous block in the blockchain, and only the newly created block is checked for consistency, avoiding the waste of memory resources and computing resources.
  • the checkpoint round can be flexibly customized, which improves the scalability of the consensus algorithm.
  • FIG. 1 is a schematic diagram of a scenario of a blockchain system provided by an embodiment of the present application
  • FIG. 2 is a schematic flowchart of an embodiment of a blockchain consensus method provided in an embodiment of the present application
  • FIG. 3 is a schematic flowchart of an embodiment of a master node judging whether a target transaction reaches a consensus according to an embodiment of the present application;
  • FIG. 4 is a schematic flowchart of another embodiment of the consensus method of the blockchain provided by the embodiment of the present application.
  • FIG. 5 is a flowchart of a specific embodiment of a blockchain consensus method provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram of an embodiment of a consensus apparatus of a blockchain provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of another embodiment of the consensus device of the blockchain provided by the embodiment of the present application.
  • FIG. 8 shows a schematic structural diagram of a server involved in an embodiment of the present application.
  • first and second are only used for descriptive purposes, and should not be construed as indicating or implying relative importance or implying the number of indicated technical features. Thus, features defined as “first”, “second” may expressly or implicitly include one or more of said features. In the description of the present invention, “plurality” means two or more, unless otherwise expressly and specifically defined.
  • the embodiments of the present application provide a consensus method, device, server, and storage medium for a blockchain, which will be described in detail below.
  • the blockchain system may include multiple nodes 100 and servers 200 , each node 100 corresponds to a terminal device, and the node 100 and the server 200 network connection, the server 200 is integrated with the consensus device of the blockchain, and the node 100 can access the server 200.
  • the server 200 is mainly used for, in the first consensus round among the multiple consensus rounds, the master node receives the first set of voting results generated by the plurality of nodes for the consensus proposal message in the second consensus round, and the first The second consensus round is a consensus round before the first consensus round; in the first consensus round, the master node generates the first consensus proposal block for the consensus proposal message, and the consensus proposal message includes the first consensus proposal block , the first voting result set and target transaction in the second consensus round; the master node receives the first voting result generated by the target node for the consensus proposal message; the master node judges the second consensus round as a checkpoint according to the first voting result Round; if the second consensus round is the checkpoint round, the master node judges whether the blockchain reaches a consensus on the target transaction according to the first voting result.
  • the target node is used for the target node to receive a consensus proposal message from the master node in the first consensus round of multiple consensus rounds, and the consensus proposal message includes multiple nodes generated in the second consensus round for the consensus proposal message
  • the first set of voting results for the second consensus round is a consensus round before the first consensus round; the target node judges whether the first consensus round it is in is the checkpoint round; if the first consensus round is the checkpoint round For the checkpoint round, the target node obtains the transaction execution result corresponding to the target transaction, and the transaction execution result is encapsulated in the first voting result generated by the target node in the first consensus round; the target node will include the first voting result of the transaction execution result.
  • a voting result is sent to the master node.
  • the server 200 may be an independent server, or a server network or server cluster composed of servers.
  • the server 200 described in this embodiment of the present invention includes but is not limited to a computer, a network host, A single web server, a set of multiple web servers, or a cloud server consisting of multiple servers.
  • the cloud server is composed of a large number of computers or network servers based on cloud computing (Cloud Computing).
  • communication between the server and the node may be implemented through any communication method, including but not limited to, based on the 3rd Generation Partnership Project (3rd Generation Partnership Project, 3GPP), Long Term Evolution (Long Term Evolution, LTE) , Mobile communication of Worldwide Interoperability for Microwave Access (WiMAX), or computer based on TCP/IP Protocol Suite (TCP/IP Protocol Suite, TCP/IP), User Datagram Protocol (User Datagram Protocol, UDP) network communication, etc.
  • 3rd Generation Partnership Project 3rd Generation Partnership Project, 3GPP
  • Long Term Evolution Long Term Evolution
  • LTE Long Term Evolution
  • WiMAX Worldwide Interoperability for Microwave Access
  • TCP/IP Protocol Suite TCP/IP Protocol Suite, TCP/IP
  • User Datagram Protocol User Datagram Protocol
  • UDP User Datagram Protocol
  • the terminal device corresponding to the node 100 used in the embodiment of the present invention may be a device including both receiving and transmitting hardware, that is, a device having receiving and transmitting hardware capable of performing two-way communication on a two-way communication link.
  • Such terminal devices may include cellular or other communication devices with a single-line display or a multi-line display or a cellular or other communication device without a multi-line display.
  • the specific terminal device corresponding to the node 100 may specifically be a desktop terminal or a mobile terminal, and the terminal device corresponding to the node 100 may specifically be one of a mobile phone, a tablet computer, a notebook computer, and the like.
  • FIG. 1 is only one application scenario of the solution of the present application, and does not constitute a limitation to the application scenario of the solution of the present application.
  • Other application environments may also include more than those shown in FIG. show more or less servers, or server network connection relationship, for example, only 1 server and 2 nodes are shown in FIG. 1, it can be understood that the blockchain system may also include one or more other servers, or /And one or more nodes connected to the server network, which are not specifically limited here.
  • the blockchain system may further include a memory 300 for storing data, such as storing host data, such as host state data when a terminal device corresponding to a node is running.
  • data such as storing host data, such as host state data when a terminal device corresponding to a node is running.
  • FIG. 1 the schematic diagram of the scenario of the blockchain system shown in FIG. 1 is only an example.
  • the blockchain system and scenario described in the embodiments of the present invention are for the purpose of illustrating the technical solutions of the embodiments of the present invention more clearly, not It constitutes a limitation on the technical solutions provided by the embodiments of the present invention.
  • Those skilled in the art know that with the evolution of the blockchain system and the emergence of new business scenarios, the technical solutions provided by the embodiments of the present invention are similar to similar technical problems. Be applicable.
  • the blockchain provided by the embodiments of the present application includes multiple nodes, and the multiple nodes are connected to each other and can broadcast to each other.
  • a transaction is executed in the blockchain, it actually needs to be executed on every node in the blockchain. Therefore, it is necessary to ensure that the same transaction is executed in a consistent order on multiple nodes, and the transactions of all nodes are executed in the same order. The execution results need to be consistent.
  • consensus needs to be used to ensure the consistency of transaction execution sequences and the consistency of transaction execution results on multiple nodes.
  • the transaction is executed on the blockchain, that is, when the blockchain is running, multiple consensus rounds can be set to achieve consensus on the transactions executed on the blockchain, and the checkpoint round is included in the multiple consensus rounds. Transactions need to be agreed upon when the consensus round reaches the checkpoint round.
  • each node in the blockchain can serve as a master node, that is, the master node can be divided or changed according to actual needs.
  • a consensus proposal message for the target transaction will be generated in the node to verify the order in which the transactions are executed on each node and whether the execution results of the transactions are consistent.
  • the consensus method of the blockchain may include:
  • the master node receives the first set of voting results generated by the multiple nodes for the consensus proposal message in the second consensus round.
  • one consensus round is equivalent to one time period.
  • consensus is made on the execution status of transactions on nodes in the current blockchain, including the execution sequence of transactions and transactions The implementation results are agreed upon.
  • one consensus round is equivalent to one time period, and multiple consensus rounds may be included in the running process of the blockchain; and since the time is continuous, multiple consensus rounds are also continuous.
  • multiple nodes can generate the first voting result for the consensus proposal message, wherein the first voting result is that each node judges whether the consensus proposal message can pass.
  • Each node can also obtain the execution result of the transaction, but only consensus on the execution result of the transaction is performed in a specific checkpoint round, decoupling the execution of the transaction from the consensus, and avoiding the execution of the transaction affecting the stability of the consensus.
  • multiple nodes in the blockchain can be divided into a master node and other nodes, and in the first consensus round, the master node can receive multiple nodes in the The set of first voting results generated for the consensus proposal message in the second consensus round.
  • the second consensus round is a consensus round before the first consensus round; that is, in the first consensus round, the master node will receive the first consensus proposal message generated by multiple nodes in the previous consensus round. Collection of voting results.
  • the master node after each consensus round starts, the master node will receive the first set of voting results generated in the previous consensus round adjacent to the current consensus round.
  • the master node In the first consensus round, the master node generates the first consensus proposal block for the consensus proposal message.
  • the blockchain is a chain storage structure
  • the block is the data element in the chain storage structure.
  • the block chain is connected to each other to form a one-way chain structure, and the first block is called the founding block. That is, the block chain is a chain structure, and the characteristics of the block chain include the hash value of the previous block in the block located in the subsequent block in the chain structure. Therefore, the post-sequence block at the end of the chain structure can include the hash values of all the previous blocks in the chain structure, which ensures that the post-sequence block at the end of the chain structure can include the hash values of all the blocks in the chain structure. Information about all blocks in the pre-order. Therefore, when consensus is performed, only the last block on the chain structure can be verified. At the same time, consensus will not affect the execution of transactions in previous blocks.
  • the node will start a new round of consensus, and the master node can create a new first proposal block based on the current local latest block based on the consensus proposal message. Since the post-sequence block includes the information in all the pre-order blocks in the chain structure, in the subsequent consensus, only the new first proposal block needs to be verified, and there is no need to verify all the blocks in the chain structure , greatly improving the efficiency of consensus; it also decouples blockchain consensus and transaction execution.
  • the first consensus proposal block, the first voting result set generated in the second consensus round, and the target transaction can be encapsulated in the consensus proposal message, and broadcast to the target node by the master node. .
  • the master node broadcasts and encapsulates the first consensus proposal block, the first voting result set generated in the second consensus round, and the consensus proposal message of the target transaction, it actually needs to be broadcast to the blockchain except itself. All other nodes.
  • the master node receives the first voting result generated by the target node for the consensus proposal message.
  • the target node After the master node broadcasts the consensus proposal message encapsulating the first consensus proposal block, the first voting result set generated in the second consensus round, and the target transaction to the target node, the target node will vote again on the consensus proposal message and get The first voting result in the first consensus round, and the first voting result generated by each is fed back to the master node. That is, the master node will receive the first voting result generated by the target node for the consensus proposal message in the first consensus round.
  • the master node determines whether the second consensus round is a checkpoint round according to the first voting result.
  • the master node After the master node receives the first voting result of other nodes, the master node also needs to determine whether the second round is a checkpoint round; that is, the master node needs to determine whether the previous consensus round of the current consensus round is a checkpoint round. Click rounds.
  • the master node judges whether the blockchain reaches a consensus on the target transaction according to the first voting result.
  • multiple consensus rounds will be set during the transaction execution process, and only when the blockchain is in the checkpoint round will the target transaction be judged in the next consensus round of the checkpoint round Whether a consensus is reached or not does not need to be judged in each consensus round.
  • This application provides a consensus method for blockchain.
  • checkpoint rounds it is unnecessary to wait for the transaction execution results of all nodes synchronously in each consensus round, which reduces the impact of transaction execution on consensus and improves consensus. stability.
  • the newly created block includes the execution result and status of the previous block in the blockchain, and only the newly created block is checked for consistency, avoiding the waste of memory resources and computing resources.
  • the checkpoint round can be flexibly customized, which improves the scalability of the consensus algorithm.
  • the master node determines whether the second consensus round is a checkpoint round according to the first voting result, which may include:
  • the master node determines whether it has received the first preset number of first voting results; if so, the master node determines whether the second consensus round is a checkpoint round.
  • the master node can monitor the number of the first voting results it has received at any time. Set the number of first voting results, then the master node does not need to judge the unreceived first voting results, and the master node can directly determine whether the previous round, that is, the second consensus round, is a checkpoint round. That is, in the embodiment of the present application, as long as the master node receives the first preset number of first voting results, the master node can start to determine whether the last consensus round is a checkpoint round.
  • the first preset number may be two-thirds of the number of nodes, that is, if the master node receives the first voting result fed back by two-thirds of the nodes in the blockchain, the master node can determine Whether the second consensus round is a checkpoint round.
  • the first preset number may also be other numbers of nodes, such as more than half of the nodes, or four-fifths of the nodes, etc. The first preset number may be based on the block The actual setting of the chain is not limited here.
  • multiple consensus rounds are consecutive, and the checkpoint round can be customized, that is, any consensus round among the multiple consecutive consensus rounds can be designated as the checkpoint round .
  • the rules corresponding to the checkpoint round are usually set. For example, ten consensus rounds can be regarded as a cycle, that is, the tenth consensus round in every adjacent and consecutive ten consensus rounds can be regarded as a checkpoint round.
  • the master node will reach a consensus on the target transaction in the next consensus round after the checkpoint round.
  • the rules corresponding to the checkpoint round are usually configured when the blockchain is running, and the corresponding rules are broadcast to each node in the blockchain, so that each node can judge the current consensus round. Whether the times are checkpoint rounds. And when the blockchain starts to run, the consensus round also starts to run, and in the consensus round, it is possible to judge whether the target transaction has reached the consensus.
  • the node in the blockchain if the node in the blockchain is in the checkpoint round, the node generates the first voting result for the consensus proposal message, and also generates the hash value of the execution result of the target transaction, and assigns the first voting result to the consensus proposal message.
  • a voting result and the hash value of the target transaction execution result are sent to the master node together. If the node in the blockchain is not in the checkpoint round, the node will only generate the first vote for the consensus proposal message, without waiting for the generation of the target transaction execution result, only the first vote that does not include the transaction execution result The result can be sent to the master node.
  • the target node will generate the first voting result and the target transaction execution result, that is, the result of the target transaction execution result.
  • the hash value of the target transaction execution result is encapsulated in the first voting result, and sent to the master node at the same time as the first voting result is sent to the master node.
  • the master node After receiving the first voting result sent by the target node, the master node will aggregate the first voting results to form a first voting result set.
  • the first voting result set includes multiple first voting results, and each A voting result includes the hash value of the transaction execution result.
  • a schematic flowchart of an embodiment of a master node judging whether a target transaction reaches a consensus may include:
  • the master node determines whether the execution results of multiple transactions in the first consensus proposal message set generated in the second consensus round are consistent.
  • each node in the blockchain can determine whether the current consensus round it is in is the checkpoint round, if the second consensus round is the checkpoint round, then the second consensus round is the checkpoint round.
  • each node generates the first voting result for the consensus proposal message and the transaction execution result for the target transaction.
  • the master node will receive the first set of voting results including transaction execution results generated in the second consensus round, and the master node can determine whether the target transaction is based on the first set of voting results including transaction execution results. reach a consensus.
  • the master node will first determine whether the transaction execution results in the first voting result set are consistent, that is, determine whether the hash values of the transaction execution results generated by the target node in the second consensus round are consistent. If the hash values of the second preset number of transaction execution results are consistent, the master node can aggregate a checkpoint (Checkpoint) information, and aggregate the checkpoint information in the first voting result set, that is, the first voting result set at this time.
  • a voting result set includes not only the checkpoint information, but also the hash value of the transaction execution result of the target node, and a plurality of first voting results.
  • the second preset number may be two-thirds of the nodes, that is, if the master node determines that at least two-thirds of the nodes have the same hash value of the target transaction execution results, the master node It can be considered that the execution results of the target transactions of all other nodes are consistent.
  • judging whether the multiple transaction execution results in the first voting result set are consistent is actually judging whether the hash values of the multiple transaction execution results in the first voting result set are consistent. . If at least two-thirds of the transaction execution results are consistent, it can be considered that all other nodes have reached transaction consistency, that is, a consensus has been reached.
  • the second preset number may also be another number other than two-thirds of the number of nodes, for example, one-half of the number of nodes, or four-fifth of the number of nodes.
  • the specific value of the second preset number can be set according to the actual situation of the blockchain, which is not limited here.
  • the master node If the transaction execution results of the second preset number of nodes are consistent, the master node generates checkpoint information, and aggregates the checkpoint information into the first voting result set.
  • the master node When the master node detects that the transaction execution results of the second preset number of nodes are consistent, the master node will generate checkpoint information, which can indicate that in the previous consensus round, that is, the second consensus round, except for the master node The transaction execution results in other nodes are the same.
  • the master node determines whether the transaction execution result generated by itself according to the target transaction is consistent with the transaction execution result in the first voting result set generated in the second consensus round.
  • the master node after judging that other nodes have reached a consensus on the target transaction, the master node also needs to judge that the master node itself and other nodes have also reached a consensus in order to consider that all nodes on the entire blockchain have reached a consensus on the target transaction. consensus.
  • the master node also needs to judge whether the transaction execution result generated by itself according to the target transaction is consistent with the transaction execution result in the first voting result set generated in the second consensus round. And since the transaction execution results in the first voting result set generated in the second consensus round have been consistent, the master node judges that the transaction execution result generated by itself is the same as the transaction execution result in the first voting result set generated in the second consensus round. Whether the execution result of the transaction is consistent, in fact, it only needs to judge whether the transaction execution result generated by the master node itself is consistent with any transaction execution result in the first voting result set generated in the second consensus round.
  • the master node determines that the transaction execution result generated by itself is consistent with the transaction execution result in the first voting result set generated in the second consensus round, it can be determined that the master node and the target node
  • the target transaction reaches a consensus, and since the target node can be any node other than the master node among multiple nodes, it can be considered that multiple nodes in the blockchain reach an agreement on the target transaction and achieve consensus. That is, the target transaction is executed in a consistent order on all nodes of the blockchain, and the execution result of the target transaction is also consistent; transaction sequence consistency and state consistency are achieved.
  • the master node waits for this consensus to time out. Meanwhile, in the embodiment of the present application, the master node can be switched again to obtain a new master node, and the new master node can restart to reach a consensus on the target transaction.
  • the master node needs to re-aggregate the first voting results generated by the target node in the first consensus round to generate a second voting result set .
  • the aggregated second voting result set is aggregated in the first consensus round.
  • the judgment of the new master node after the switch has entered the next consensus round, that is, the third consensus round, and the third consensus round is the subsequent consensus round adjacent to the first consensus round Second-rate.
  • the new master node after the switch can rebuild the second consensus proposal block on the basis of the latest local block (that is, including the first consensus proposal block), and the new master node at this time includes the previous master node (that is, including the first consensus proposal block).
  • the second proposal block also needs to be encapsulated in the consensus proposal message together with the second set of voting results generated in the first consensus round and the target transaction.
  • the master node in the third consensus round broadcasts the consensus proposal message including the second voting result set to the target node, and restarts the consensus in the third consensus round.
  • the method for switching the master node may be: numbering multiple nodes in the blockchain according to the sequence of the chain structure; taking the first node in the chain structure as the initial Master node; when it is necessary to switch the master node, switch the master node in sequence according to the number.
  • the embodiment of the present application also provides a consensus method for a blockchain, wherein the blockchain includes multiple nodes, and the multiple nodes are connected to each other.
  • the blockchain When the blockchain is running, multiple consensus rounds will be set to achieve consensus on the transactions executed on the blockchain to ensure the consistency of the execution sequence of transactions on different nodes in the blockchain and the consistency of the execution results.
  • a consensus round multiple sections of the blockchain include a master node and a target node; the target node is also a plurality of nodes except the master node. any node among all other nodes of .
  • a consensus proposal message for the target transaction will be generated to achieve consensus on the target transaction.
  • a schematic flowchart of another embodiment of the blockchain consensus method provided by the embodiment of the present application may include:
  • the target node receives the first consensus proposal block from the master node.
  • the target node in each consensus round, will receive the first consensus proposal block from the master node; and the first consensus proposal block may include a consensus proposal message for the target transaction, and
  • the target node can be any node among all the nodes of the blockchain except the master node.
  • the target node determines whether the first consensus round it is in is a checkpoint round.
  • the target node after the target node receives the first consensus proposal block sent by the master node, the target node also needs to determine whether it is in a specific checkpoint round, that is, the target node needs to determine whether it is currently in the first consensus round. for a specific checkpoint round.
  • the target node If the first consensus round is a checkpoint round, the target node generates a transaction execution result corresponding to the target transaction.
  • the target node needs to generate
  • the target node sends the first voting result including the transaction execution result to the master node.
  • This application provides a blockchain consensus method.
  • a checkpoint round By designing a checkpoint round, the transaction execution results of all nodes are obtained only in the checkpoint round, and there is no need to wait for the transaction execution results of all nodes synchronously in each consensus round. , reducing the impact of transaction execution on the consensus and improving the stability of the consensus.
  • the checkpoint round can be flexibly customized, which improves the scalability of the consensus algorithm.
  • each node in the blockchain can determine whether the consensus round it is in is a checkpoint round, and the checkpoint round is usually set in advance.
  • ten consensus rounds can be regarded as a cycle, that is, the tenth consensus round in every adjacent and consecutive ten consensus rounds can be regarded as a checkpoint round.
  • the target node is in the preset checkpoint round, it needs to wait for the node to generate the transaction execution result for the target transaction.
  • the target node determines that the first consensus round it is in is not the preset checkpoint round, then the target node can directly vote for the master node in the current consensus round. That is, the target node can directly generate the first voting result for the consensus proposal message and feed it back to the master node in the first consensus round.
  • the first consensus proposal block may further include a first set of voting results generated by the target node for the consensus proposal message in the second consensus round, and the second consensus round is a plurality of consensus rounds A consensus round before the first consensus round.
  • the method may further include:
  • the target node determines whether the consensus proposal message includes checkpoint information; if the consensus proposal message includes checkpoint information, the target node determines whether it has reached a consensus on the target transaction according to the checkpoint information.
  • the consensus proposal message includes the first voting result set generated by multiple nodes in the second consensus round, and the target node can judge the transaction execution result generated by itself for the target transaction, Whether it is the same as the transaction execution result in the first voting result set in the consensus proposal message is used to judge whether the target node has reached a consensus on the target transaction.
  • the consensus proposal message received by the target node includes checkpoint information, it can be determined that in the previous consensus round, at least the transaction execution results between the second preset number of nodes are realized. Consensus is achieved; that is, transaction execution results between at least a second preset number of nodes achieve transaction sequence consistency and state consistency.
  • the target node is judging whether it has reached transaction consistency. At the time, it only needs to judge the transaction execution result generated by itself and any transaction execution result in the first voting result set. And in the embodiment of the present application, judging the consistency of the transaction execution results is actually judging whether the hash values of the transaction execution results are consistent.
  • the execution result of the target node is consistent with the transaction execution result in the first voting result set, it is possible to determine the difference between the local execution blockchain state of the target node and the first consensus proposal block Consensus was reached. Also, since the first consensus proposal block includes the hash values of all blocks located in the pre-order of the first consensus proposal block, it can be considered that the local execution status chain block of the target node is consistent with the entire network.
  • the target node can refuse to generate the first voting result and wait for the consensus to time out. Finally, the master node is switched, a new master node is obtained, and the newly generated new master node restarts the consensus for the consensus proposal message.
  • the target node if the first voting result set in the first consensus proposal block received by the target does not include checkpoint information, the target node needs to determine whether it is in a specific checkpoint round. If the target node is in a specific checkpoint round, the target node needs to wait for the transaction execution result in the newly generated proposal block before the end of this consensus round, and regenerate the first voting result for the consensus proposal message, which will include the transaction The first voting result of the execution result is sent to the master node.
  • the target node can directly generate the first voting result, And send it to the master node in the current consensus round. At this time, the first voting result does not include the transaction execution result generated by the target node.
  • FIG. 5 a flowchart of a specific embodiment of the consensus method of the blockchain provided by the embodiment of the present application is shown.
  • the multiple nodes of the blockchain in the current consensus round will be divided into the master node and the target node, and the target node can be multiple Any of all nodes in the node except the node.
  • the master node Before sending the consensus proposal message of each round of consensus, the master node will rebuild a first proposal block based on the latest local block. Due to the characteristics of the blockchain, the newly constructed first proposal block includes the information in all blocks before the first proposal block, so in the subsequent consensus process, only the first consensus proposal area needs to be verified information in the block.
  • the consensus proposal message when the first consensus proposal block is constructed, the consensus proposal message will encapsulate the first consensus proposal block, the first set of voting results generated in the previous consensus round, and the target transaction, and broadcast to the target node.
  • the nodes in the blockchain will generate the first voting result for the consensus proposal message in each consensus round; and if the consensus round is the preset checkpoint round, the first voting result will also include The transaction execution result generated by the target node for the target transaction.
  • the target node After receiving the consensus proposal message proposed by the master node, the target node will first determine whether the first voting result set in the consensus proposal message includes checkpoint information (ie, checkpoint information).
  • checkpoint information is generated by the master node in each consensus round in the corresponding consensus round, and the master node in the current round will generate checkpoint information only if the previous round is a checkpoint round.
  • multiple consensus rounds include the adjacent first consensus round and second consensus round, and the second consensus round is before the first consensus round, and only the second consensus round is the preset checkpoint round time, the master node in the first consensus round will generate checkpoint information in the first consensus round. At the same time, if the node is in the checkpoint round, multiple nodes in the blockchain will generate transaction execution results for the target transaction.
  • the target node determines that the first voting result set includes checkpoint information, the target node needs to determine whether the local target transaction execution result generated by itself for the target transaction is consistent with the transaction execution result in the first voting result set.
  • the target node judges that the execution result of the local target transaction is consistent with the execution result of the transaction in the first voting result set, it can be determined that the local execution result of the target node is consistent with the execution result of the entire network, that is, the target node has reached a consensus on the target transaction, that is, the target The node achieves transaction sequence consistency and state consistency for the target transaction.
  • the target node If the target node judges that its local execution result is inconsistent with the result of the entire network, the target node waits for the consensus to time out.
  • the target transaction is executed on the blockchain, the blockchain is in the first consensus round, and there is no first voting result set of the previous consensus round at this time; then this When the target node receives the consensus proposal message sent by the master node, it will directly determine whether it is in a specific checkpoint round, and will no longer determine whether the first voting result set includes checkpoint information. Or it can be said that there is no checkpoint information in the first voting result set because there is no first voting combination in the previous consensus round.
  • the target node If the first voting result set does not include checkpoint information, or the target node has reached a transaction consensus, the target node also needs to determine whether it is in a specific checkpoint round. If the target node itself is in a specific checkpoint round, the target node needs to wait for the transaction execution result generated by the latest block in the blockchain for the target transaction until this consensus round. That is, the transaction execution result generated for the target transaction for the first consensus proposal block.
  • the target node then votes for the master node, that is, the target node sends the first result voting information including the transaction execution result to the master node in the current consensus round. If the master node judges that it is not in a specific checkpoint round, the target node directly votes for the master node.
  • the master node in the current consensus round After the master node in the current consensus round receives the first preset number of first voting information from the target node, the master node needs to determine whether the previous consensus round in the current consensus round is a preset check Click rounds. If the last consensus round is a checkpoint round, the master node needs to aggregate the first voting information set that includes checkpoint information; if the last consensus round is not a checkpoint round, the master node aggregates a set of voting information that does not include checkpoint information. The first voting information set of information, and wait for this consensus to time out.
  • the master node when the master node aggregates the first voting information set including checkpoint information, the master node actually judges whether there is a second preset number of transaction execution results consistent, and if there is a second preset number of transaction execution results If they are consistent, the master node can aggregate the first voting information set including the checkpoint information.
  • the master node After the master node aggregates the first voting information set including the checkpoint information, the master node also needs to determine whether the transaction execution result generated by itself for the target transaction is related to the transaction execution result in the first voting result set including the checkpoint information. Consistent. If the two are consistent, it can be considered that the master node has reached the consistency of the transaction sequence and the state of the target transaction, that is, all nodes in the blockchain have reached a consensus on the target transaction. At this point, a new round of consensus can be restarted.
  • the master node waits for this consensus to time out.
  • the present application also provides a consensus device for a blockchain, which is applied to the blockchain, and the blockchain includes multiple nodes, and the multiple nodes are connected to each other; the blockchain has multiple consensus rounds during operation In order to achieve consensus on the transactions executed on the blockchain, multiple consensus rounds include checkpoint rounds.
  • multiple nodes include a master node and a target node, and the target node is one of multiple nodes. Any node among all nodes except the master node; the execution of the target transaction in the blockchain generates a consensus proposal message for the target transaction.
  • the embodiment of the present application also provides a consensus device of the blockchain, as shown in FIG. 6 , which is A schematic diagram of an embodiment of a blockchain consensus device provided by this embodiment of the application, the blockchain consensus device may include:
  • a first receiving module 601 the first receiving module 601 is configured to receive, in the first consensus round of the multiple consensus rounds, a first set of voting results generated by multiple nodes for the consensus proposal message in the second consensus round,
  • the second consensus round is a consensus round before the first consensus round.
  • Proposal block generation module 602 the proposal block generation module 602 is used to generate a first consensus proposal block for a consensus proposal message in the first consensus round, and the consensus proposal message includes the first consensus proposal block and the second consensus proposal block. The first set of voting results in the round and the target transaction.
  • the second receiving module 603, the second receiving module 603 is configured to receive the first voting result generated by the target node for the consensus proposal message.
  • the first judgment module 604 the first judgment module 604 is used for judging whether the second consensus round is a checkpoint round according to the first voting result;
  • the second judgment module 605 is used for judging whether the blockchain reaches a consensus on the target transaction according to the first voting result if the second consensus round is the checkpoint round.
  • the present application provides a consensus device for blockchain.
  • checkpoint rounds it is unnecessary to wait for the transaction execution results of all nodes synchronously in each consensus round, which reduces the impact of transaction execution on consensus and improves consensus. stability.
  • the newly created block includes the execution result and status of the previous block in the blockchain, and only the newly created block is checked for consistency, avoiding the waste of memory resources and computing resources.
  • the checkpoint round can be flexibly customized, which improves the scalability of the consensus algorithm.
  • the first judgment module 604 can be mainly used by the master node to judge whether it has received the first preset number of first voting results; if so, the master node determines that the second consensus round is checking Click rounds.
  • the target node if the second consensus round is a checkpoint round, then in the second consensus round, the target node generates a transaction execution result corresponding to the target transaction, and the second consensus round generates a transaction execution result corresponding to the target transaction.
  • the first voting result set includes transaction execution results, and there are multiple transaction execution results in the first voting result set generated in the second consensus round.
  • the second judgment module 605 can be mainly used to judge whether the execution results of multiple transactions in the first voting result set generated in the second consensus round are consistent if the second consensus round is a checkpoint round; The transaction execution results of the two preset number of nodes are consistent, then the master node generates checkpoint information, and aggregates the checkpoint information into the first voting result set generated in the second consensus round; the master node judges that it generates the checkpoint information according to the target transaction.
  • the embodiment of the present application also provides a consensus device of the blockchain, as shown in FIG. 7 , which is A schematic diagram of another embodiment of the consensus device of the blockchain provided by the embodiment of the present application.
  • the consensus device of the blockchain is applied to the blockchain, the blockchain includes multiple nodes, and the multiple nodes are connected to each other; the blockchain has multiple consensus rounds during operation to execute the execution on the blockchain.
  • a consensus is performed on transactions based on the transaction. Multiple consensus rounds include checkpoint rounds.
  • multiple nodes include a master node and a target node, and the target node is other than the master node among the multiple nodes. Any node among all nodes; after the target transaction is executed in the blockchain, a consensus proposal message for the target transaction is generated.
  • the consensus device of the blockchain may include:
  • the third receiving module 701 is configured to receive a consensus proposal message from the master node in the first consensus round among the multiple consensus rounds, and the consensus proposal message includes a plurality of nodes in the second consensus round
  • the first set of voting results generated for the consensus proposal message in the second consensus round is a consensus round before the first consensus round.
  • the third judging module 702 the third judging module 702 is used for judging whether the first consensus round it is in is a checkpoint round.
  • the obtaining module 703 is used to obtain the transaction execution result corresponding to the target transaction if the first consensus round is a checkpoint round, and the transaction execution result is encapsulated in the first vote generated by the target node in the first consensus round results.
  • a sending module 704 the sending module 704 is configured to send the first voting result including the transaction execution result to the master node.
  • the present application provides a consensus device for blockchain.
  • a checkpoint round By designing a checkpoint round, the transaction execution results of all nodes are obtained only in the checkpoint round, and there is no need to synchronously wait for the transaction execution results of all nodes in each consensus round. , reducing the impact of transaction execution on the consensus and improving the stability of the consensus.
  • the checkpoint round can be flexibly customized, which improves the scalability of the consensus algorithm.
  • the present application further provides a server that integrates any blockchain consensus device provided by the embodiments of the present application, as shown in FIG. 8 , which shows a schematic structural diagram of the server involved in the embodiments of the present application ,Specifically:
  • the server may include a processor 801 of one or more processing cores, a memory 802 of one or more computer-readable storage media, a power supply 803 and an input unit 804 and other components.
  • a processor 801 of one or more processing cores may include a processor 801 of one or more processing cores, a memory 802 of one or more computer-readable storage media, a power supply 803 and an input unit 804 and other components.
  • FIG. 8 does not constitute a limitation on the server, and may include more or less components than the one shown, or combine some components, or arrange different components. in:
  • the processor 801 is the control center of the server, using various interfaces and lines to connect various parts of the entire server, by running or executing the software programs and/or modules stored in the memory 802, and calling the data stored in the memory 802, Execute various functions of the server and process data to monitor the server as a whole.
  • the processor 801 may include one or more processing cores; preferably, the processor 801 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, etc. , the modem processor mainly deals with wireless communication. It can be understood that, the above-mentioned modulation and demodulation processor may not be integrated into the processor 801.
  • the memory 802 can be used to store software programs and modules, and the processor 801 executes various functional applications and data processing by running the software programs and modules stored in the memory 802 .
  • the memory 802 may mainly include a stored program area and a stored data area, wherein the stored program area may store an operating system, an application program (such as a sound playback function, an image playback function, etc.) required for at least one function, and the like; Data created by the use of the server, etc.
  • memory 802 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, memory 802 may also include a memory controller to provide processor 801 access to memory 802 .
  • the server also includes a power supply 803 for supplying power to various components.
  • the power supply 803 can be logically connected to the processor 801 through a power management system, so that functions such as charging, discharging, and power consumption management are implemented through the power management system.
  • the power source 803 may also include one or more DC or AC power sources, recharging systems, power failure detection circuits, power converters or inverters, power status indicators, and any other components.
  • the server may also include an input unit 804, which may be used to receive input numerical or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.
  • an input unit 804 which may be used to receive input numerical or character information and generate keyboard, mouse, joystick, optical or trackball signal input related to user settings and function control.
  • the server may also include a display unit and the like, which will not be described herein again.
  • the processor 801 in the server loads the executable files corresponding to the processes of one or more application programs into the memory 802 according to the following instructions, and the processor 801 executes the execution and stores them in the memory 802 applications to achieve various functions, as follows:
  • the master node receives the first set of voting results generated by multiple nodes for the consensus proposal message in the second consensus round, and the second consensus round is the first consensus round A previous consensus round; in the first consensus round, the master node generates the first consensus proposal block for the consensus proposal message, and the consensus proposal message includes the first consensus proposal block and the first consensus proposal block in the second consensus round.
  • the set of voting results and the target transaction the master node receives the first voting result generated by the target node for the consensus proposal message; the master node determines that the second consensus round is the checkpoint round according to the first voting result; if the second consensus round is In the checkpoint round, the master node judges whether the blockchain reaches a consensus on the target transaction according to the first voting result.
  • processor 801 in the server will load the executable file corresponding to the process of one or more application programs into the memory 802 according to the following instructions, and the processor 801 will run the application program stored in the memory 802 , so as to achieve various functions, as follows:
  • the target node receives the consensus proposal message from the master node, and the consensus proposal message includes the first votes generated by multiple nodes for the consensus proposal message in the second consensus round
  • the result set, the second consensus round is a consensus round before the first consensus round; the target node judges whether the first consensus round it is in is a checkpoint round; if the first consensus round is a checkpoint round Second, the target node obtains the transaction execution result corresponding to the target transaction, and the transaction execution result is encapsulated in the first voting result generated by the target node in the first consensus round; the target node sends the first voting result including the transaction execution result to the master node.
  • the present application also provides a computer-readable storage medium, which may include: a read-only memory (ROM, Read Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and the like.
  • the storage medium stores a computer program, and the computer program is loaded by the processor to execute steps in any blockchain consensus method provided by the embodiments of this application.
  • the computer program being loaded by the processor may perform the following steps:
  • the master node receives the first set of voting results generated by multiple nodes for the consensus proposal message in the second consensus round, and the second consensus round is the first consensus round A previous consensus round; in the first consensus round, the master node generates the first consensus proposal block for the consensus proposal message, and the consensus proposal message includes the first consensus proposal block and the first consensus proposal block in the second consensus round.
  • the set of voting results and the target transaction the master node receives the first voting result generated by the target node for the consensus proposal message; the master node determines that the second consensus round is the checkpoint round according to the first voting result; if the second consensus round is In the checkpoint round, the master node judges whether the blockchain reaches a consensus on the target transaction according to the first voting result.
  • the computer program can be loaded by the processor and can perform the following steps:
  • the target node receives the consensus proposal message from the master node, and the consensus proposal message includes the first votes generated by multiple nodes for the consensus proposal message in the second consensus round
  • the result set, the second consensus round is a consensus round before the first consensus round; the target node judges whether the first consensus round it is in is a checkpoint round; if the first consensus round is a checkpoint round Second, the target node obtains the transaction execution result corresponding to the target transaction, and the transaction execution result is encapsulated in the first voting result generated by the target node in the first consensus round; the target node sends the first voting result including the transaction execution result to the master node.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Retry When Errors Occur (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

提供一种区块链的共识方法、装置、服务器及存储介质。设计检查点轮次，无需在每个共识轮次等待所有节点的交易执行结果，减少交易执行对共识的影响，提高共识稳定性。新建区块包括区块链前序区块的执行结果及状态，仅对新建区块进行一致性校验，避免内存资源及计算资源的浪费。检查点轮次可自定义，提升共识算法可拓展性。

Description

一种区块链的共识方法、装置、服务器及存储介质 技术领域
本申请涉及区块链技术领域，具体涉及一种区块链的共识方法、装置、服务器及存储介质。
背景技术
在区块链系统中，一致性是不可或缺的一个重要属性，这其中又包含了交易序列一致性与状态一致性这两种一致性属性。为了保证区块链系统的一致性，通常需要引入共识算法来保证所有节点按照一致的顺序执行相同的交易序列(交易序列一致性)，除此之外，还需要额外引入一种状态对比的方案来保证所有节点的执行结果是一致的(状态一致性)。
现有技术下的共识算法，将共识与交易执行耦合，影响共识的稳定性；且区块链中的不同的主节点均在本地最新区块的基础上构建不同的提案区块，造成内存资源浪费。同时，需要实时记录下所有区块的内容以及执行结果，需要维护庞大的历史状态数，增加执行模块的设计复杂度。
技术问题
本申请提供一种区块链的共识方法，通过设计检查点轮次，使得无需在每一个共识轮次中都同步等待所有节点的交易执行结果，减少了交易执行对于共识的影响，提高了共识的稳定性。且由于会新建区块，新建的区块中包括区块链中前序区块的执行结果以及状态，仅对新建的区块进行一致性校验，避免了内存资源以及计算资源的浪费。同时检查点轮次可灵活自定义，提升了共识算法的可拓展性。
技术解决方案
一方面，本申请提供区块链的共识方法，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
所述方法包括：
在所述多个共识轮次中的第一共识轮次中，所述主节点接收所述多个节点在第二共识轮次针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
在所述第一共识轮次中，所述主节点针对所述共识提案消息生成第一共识提案区块，所述共识提案消息中包括所述第一共识提案区块、所述第二共识轮次中的第一投票结果集合以及所述目标交易；
所述主节点接收所述目标节点针对所述共识提案消息生成的第一投票结果；
所述主节点根据所述第一投票结果，判断所述第二共识轮次为所述检查点轮次；
若所述第二共识轮次为所述检查点轮次，所述主节点根据所述第一投票结果判断所述区块链针对所述目标交易是否达成共识。
在本申请一种可能的实现方式中，所述主节点根据所述第一投票结果，判断所述第二共识轮次为所述检查点轮次，包括：
所述主节点判断自身是否接收到第一预设数量的第一投票结果；
若是，则所述主节点确定所述第二共识轮次为所述检查点轮次。
在本申请一种可能的实现方式中，所述主节点判断自身是否接收到第一预设数量的第一投票结果，包括：
若是所述主节点接收到所述区块链中三分之二节点反馈的第一投票结构，所述主机判断所述第二共识轮次是否为所述检查点轮次。
在本申请一种可能的实现方式中，若所述第二共识轮次为所述检查点轮次，则在所述第二共识轮次内，所述目标节点生成与所述目标交易对应的交易执行结果，所述第二共识轮次中生成的第一投票结果集合中包括所述交易执行结果，第二共识轮次中生成的第一投票结果集合中的交易执行结果为多个；
所述若所述第二共识轮次为所述检查点轮次，所述主节点根据所述第一投票结果判断所述区块链针对所述目标交易是否达成共识，包括：
若所述第二共识轮次为所述检查点轮次，所述主节点判断所述第二共识轮次中生成的第一投票结果集合中的多个交易执行结果是否一致；
若第二预设数量的节点的交易执行结果一致，则所述主节点生成检查点信息，并将所述检查点信息聚合在所述第二共识轮次中生成的所述第一投票结果集合中；
所述主节点判断自身根据所述目标交易生成的交易执行结果，与所述第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致；
若所述主节点自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则确定所述区块链针对所述目标交易达成共识。
在本申请一种可能的实现方式中，所述主节点判断自身根据所述目标交易生成的交易执行结果，与所述第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致，包括：
判断所述主节点自身生成的交易执行结果，与所述第二共识轮次中生成的第一投票结果集合中的任一个交易执行结果之间是否一致。
在本申请一种可能的实现方式中，所述方法还包括：
若所述主节点自身的交易执行结果与所述第二共识轮次中生成的第一投票结果集合中的交易执行结果不一致，则所述主节点等待此次共识超时；
切换所述主节点，得到新主节点，所述新主节点针对所述目标交易重新达成共识。
在本申请一种可能的实现方式中，所述切换所述主节点的方法，包括：
将所述区块链中的多个节点按照链式结构的顺序编号；以所述链式结构中位于第一个的节点为初始主节点；当需要切换所述主节点时，按照编号的顺序依次切换所述主节点。
在本申请一种可能的实现方式中，所述方法还包括：若所述第二共识轮次不为所述检查点轮次，则所述主节点重新聚合所述其他节点在所述第一共识轮次生成的所述第一投票结果，生成第二投票结果集合；
切换所述主节点，得到新主节点，所述新主节点针对所述目标交易重新达成共识。
在本申请一种可能的实现方式中，所述方法还包括：
所述新主节点在所述第一提案区块的基础上构建第二提案区块，所述第二提案区块包括所述第二投票结果集合、所述共识提案消息以及所述目标交易。
另一方面，本申请提供一种区块链的共识方法，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
所述方法包括：在所述多个共识轮次中的第一共识轮次内，所述目标节点接收来自所述主节点的共识提案消息，所述共识提案消息中包括所述多个节点在第二共识轮次中针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
所述目标节点判断自身所处的第一共识轮次是否为所述检查点轮次；
若所述第一共识轮次为所述检查点轮次，所述目标节点获取与所述目标交易对应的交易执行结果，所述交易执行结果封装在所述目标节点在所述第一共识轮次中生成的所述第一投票结果中；
所述目标节点将包括所述交易执行结果的所述第一投票结果发送至所述主节点。
在本申请一种可能的实现方式中，在所述目标节点判断自身所处的第一共识轮次是否为所述检查点轮次之前，所述方法还包括：
所述目标节点判断所述共识提案消息中是否包括检查点信息；
若包括所述检查点信息，则所述目标节点根据所述检查点信息判断自身是否针对所述目标交易达成共识。
在本申请一种可能的实现方式中，所述方法还包括：
若所述第一共识轮次不为所述检查点轮次，所述目标节点针对所述共识提案消息生成第一投票结果，并发送至所述主节点；
其中，所述第一投票结果不包括所述目标节点获取的针对所述目标交易的交易执行结果。
另一方面，本申请还提供一种区块链的共识装置，应用于区块链，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
所述装置包括：
第一接收模块，所述第一接收模块用于在所述多个共识轮次中的第一共识轮次中，接收所述多个节点在第二共识轮次针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
提案区块生成模块，所述提案区块生成模块用于在所述第一共识轮次中，针对所述共识提案消息生成第一共识提案区块，所述共识提案消息中包括所述第一共识提案区块、所述第二共识轮次中的第一投票结果集合以及所述目标交易；
第二接收模块，所述第二接收模块用于接收所述目标节点针对所述共识提案消息生成的第一投票结果；
第一判断模块，所述第一判断模块用于根据所述第一投票结果，判断所述第二共识轮次为所述检查点轮次；
第二判断模块，所述第二判断模块用于若所述第二共识轮次为所述检查点轮次，根据所述第一投票结果判断所述区块链针对所述目标交易是否达成共识。
在本申请一种可能的实现方式中，所述第一判断模块主要用于主节点判断自身是否接收到第一预设数量的第一投票结果；若是，则主节点确定第二共识轮次为检查点轮次。
在本申请一种可能的实现方式中，所述第二判断模块主要用于若第二共识轮次为检查点轮次，主节点判断第二共识轮次中生成的第一投票结果集合中的多个交易执行结果是否一致；若第二预设数量的节点的交易执行结果一致，则主节点生成检查点信息，并将检查点信息聚合在第二共识轮次中生成的第一投票结果集合中；主节点判断自身根据目标交易 生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致；若主节点自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则确定区块链针对目标交易达成共识。
另一方面，本申请还提供一种区块链的共识装置，应用于区块链，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
所述装置包括：
第三接收模块，所述第三接收模块用于在所述多个共识轮次中的第一共识轮次内，接收来自所述主节点的共识提案消息，所述共识提案消息中包括所述多个节点在第二共识轮次中针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
第三判断模块，所述第三判断模块用于判断自身所处的第一共识轮次是否为所述检查点轮次；
获取模块，所述获取模块用于若所述第一共识轮次为所述检查点轮次，获取与所述目标交易对应的交易执行结果，所述交易执行结果封装在所述目标节点在所述第一共识轮次中生成的所述第一投票结果中；
发送模块，所述发送模块用于将包括所述交易执行结果的所述第一投票结果发送至所述主节点。
另一方面，本申请还提供一种服务器，所述服务器包括：
一个或多个处理器；
存储器；以及
一个或多个应用程序，其中所述一个或多个应用程序被存储于所述存储器中，并配置为由所述处理器执行以实现如上任一项所述的区块链的共识方法。
另一方面，本申请还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器进行加载，以执行如上任一项所述的区块链共识方法中的步骤。
有益效果
本申请提供一种区块链的共识方法，通过设计检查点轮次，使得无需在每一个共识轮次中都同步等待所有节点的交易执行结果，减少了交易执行对于共识的影响，提高了共识的稳定性。且由于会新建区块，新建的区块中包括区块链中前序区块的执行结果以及状态，仅对新建的区块进行一致性校验，避免了内存资源以及计算资源的浪费。同时检查点轮次可灵活自定义，提升了共识算法的可拓展性。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的区块链系统的场景示意图；
图2为本申请实施例中提供的区块链的共识方法的一个实施例流程示意图；
图3为本申请实施例提供的主节点判断目标交易是否达成共识的一实施例流程示意图；
图4为本申请实施例提供的区块链的共识方法另一实施例流程示意图；
图5为本申请实施例提供的区块链的共识方法一具体实施例流程图；
图6为本申请实施例提供的区块链的共识装置一实施例示意图；
图7为本申请实施例提供的区块链的共识装置另一实施例示意图；
图8示出了本申请实施例所涉及到的服务器的结构示意图。
本发明的实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个所述特征。在本发明的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
在本申请中，“示例性”一词用来表示“用作例子、例证或说明”。本申请中被描述为“示例性”的任何实施例不一定被解释为比其它实施例更优选或更具优势。为了使本领域任何技术人员能够实现和使用本发明，给出了以下描述。在以下描述中，为了解释的目的而列出了细节。应当明白的是，本领域普通技术人员可以认识到，在不使用这些特定细节的情况下也可以实现本发明。在其它实例中，不会对公知的结构和过程进行详细阐述，以避免不必要的细节使本发明的描述变得晦涩。因此，本发明并非旨在限于所示的实施例，而是与符合本申请所公开的原理和特征的最广范围相一致。
本申请实施例提供一种区块链的共识方法、装置、服务器及存储介质，以下分别进行详细说明。
如图1所示，为本申请实施例提供的区块链系统的场景示意图，该区块链系统可以包括多个节点100，和服务器200，每个节点100对应一个终端设备，节点100和服务器200网络连接，服务器200中集成有区块链的共识装置，节点100可以访问服务器200。
本发明实施例中服务器200主要用于在多个共识轮次中的第一共识轮次中，主节点接收多个节点在第二共识轮次针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次；在第一共识轮次中，主节点针对共识提案消息生成第一共识提案区块，共识提案消息中包括第一共识提案区块、第二共识轮次中的第一投票结果集合以及目标交易；主节点接收目标节点针对共识提案消息生成的第一投票结果；主节点根据第一投票结果，判断第二共识轮次为检查点轮次；若第二共识轮次为检查点轮次，主节点根据第一投票结果判断区块链针对目标交易是否达成共识。
或是用于在多个共识轮次中的第一共识轮次内，目标节点接收来自主节点的共识提案消息，共识提案消息中包括多个节点在第二共识轮次中针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次；目标节点判断自身所处的第一共识轮次是否为检查点轮次；若第一共识轮次为检查点轮次，目标节点获取与所目标交易对应的交易执行结果，交易执行结果封装在目标节点在第一共识轮次中生成的第一投票结果中；目标节点将包括交易执行结果的第一投票结果发送至主节点。
本发明实施例中，该服务器200可以是独立的服务器，也可以是服务器组成的服务器 网络或服务器集群，例如，本发明实施例中所描述的服务器200，其包括但不限于计算机、网络主机、单个网络服务器、多个网络服务器集或多个服务器构成的云服务器。其中，云服务器由基于云计算(Cloud Computing)的大量计算机或网络服务器构成。本发明的实施例中，服务器与节点之间可通过任何通信方式实现通信，包括但不限于，基于第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)、长期演进(Long Term Evolution，LTE)、全球互通微波访问(Worldwide Interoperability for Microwave Access，WiMAX)的移动通信，或基于TCP/IP协议族(TCP/IP Protocol Suite，TCP/IP)、用户数据报协议(User Datagram Protocol，UDP)的计算机网络通信等。
可以理解的是，本发明实施例中所使用的节点100对应的终端设备可以是既包括接收和发射硬件的设备，即具有能够在双向通信链路上，执行双向通信的接收和发射硬件的设备。这种终端设备可以包括：蜂窝或其他通信设备，其具有单线路显示器或多线路显示器或没有多线路显示器的蜂窝或其他通信设备。具体的节点100对应的终端设备具体可以是台式终端或移动终端，节点100对应的终端设备具体还可以是手机、平板电脑、笔记本电脑等中的一种。
本领域技术人员可以理解，图1中示出的应用环境，仅仅是与本申请方案一种应用场景，并不构成对本申请方案应用场景的限定，其他的应用环境还可以包括比图1中所示更多或更少的服务器，或者服务器网络连接关系，例如图1中仅示出1个服务器和2个节点，可以理解的，该区块链系统还可以包括一个或多个其他服务器，或/且一个或多个与服务器网络连接的节点，具体此处不作限定。
另外，如图1所示，该区块链系统还可以包括存储器300，用于存储数据，如存储主机数据，例如节点对应的终端设备运行时的主机状态数据等。
需要说明的是，图1所示的区块链系统的场景示意图仅仅是一个示例，本发明实施例描述的区块链系统以及场景是为了更加清楚的说明本发明实施例的技术方案，并不构成对于本发明实施例提供的技术方案的限定，本领域普通技术人员可知，随着区块链系统的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。
本申请实施例提供的区块链中包括多个节点，多个节点之间互相连接，可以互相进行广播。当一个交易在区块链中执行，实际上需要在区块链中的每个节点上都执行，因此需要保证相同的交易在多个节点上均按照一致的顺序执行，且所有节点的交易的执行结果需要保持一致。
因此，在本申请的实施例中，需要利用共识来保证多个节点上交易执行顺序的一致性以及交易执行结果的一致性。当交易在区块链上执行，即区块链在运行时，可以设置多个共识轮次对区块链上执行的交易进行共识，而在多个共识轮次中包括检查点轮次，当共识轮次到达检查点轮次时需要对交易进行共识。
需要说明的是，在一个共识轮次内，可以将多个节点划分为主节点和从节点，在一个确定的共识轮次内，主节点一般为一个；而在不同的共识轮次内，主节点可以不同。且在本申请的实施例中，区块链中的每一个节点都可以作为主节点，即主节点可以根据实际需要进行划分或更改。
当目标交易在区块链中的节点上执行结束后，节点中会生成针对目标交易的共识提案消息，以验证在每个节点上交易执行的顺序以及交易的执行结果是否一致。
如图2所示，为本申请实施例中区块链的共识方法的一个实施例流程示意图，该区块链的共识方法可以包括：
21、在多个共识轮次中的第一共识轮次中，主节点接收多个节点在第二共识轮次针对共识提案消息生成的第一投票结果集合。
在本申请的实施例中，一个共识轮次相当于一个时间段，在一个共识轮次中，会对当 前区块链中节点上的交易的执行情况进行共识，包括对交易的执行顺序以及交易的执行结果均进行共识。
而由于每个节点执行交易的时间是未知的，因此若是每一个共识轮次都进行共识，则可能会导致共识超时。因此在本申请的实施例中，无需在每一个共识轮次均进行共识，只需要在特定的检查点轮次进行共识即可。
在本申请的实施例中，一个共识轮次相当于一个时间段，而在区块链的运行过程中是可以包括多个共识轮次的；且由于时间是连续的，因此多个共识轮次之间也是连续的。在每一个共识轮次中，多个节点均可以生成针对共识提案消息生成的第一投票结果，其中第一投票结果为每个节点各自判断共识提案消息是否能够通过。而每个节点也可以获取交易的执行结果，但仅在特定的检查点轮次对交易的执行结果进行共识，将交易的执行与共识实现解耦，避免交易的执行影响共识的稳定性。
其中，在多个共识轮次中的第一共识轮次中，区块链中的多个节点可以划分为一个主节点和其他节点，而第一共识轮次中主节点可以接收多个节点在第二共识轮次时针对共识提案消息生成的第一投票结果集合。而第二共识轮次为第一共识轮次之前的一个共识轮次；即在第一共识轮次中，主节点会接收上一个共识轮次中的多个节点针对共识提案消息生成的第一投票结果集合。
即在本申请的实施例中，每一个共识轮次开始后，主节点均会接收与当前共识轮次相邻的上一个共识轮次中生成的第一投票结果集合。
22、在第一共识轮次中，主节点针对共识提案消息生成第一共识提案区块。
具体的，区块链是一个链式存储结构，区块就是链式存储结构中的数据元素，区块链由区块相互连接形成单向链式结构，其中第一个区块被称为创始区块。即区块链是一个链式结构，且区块链的特性包括链式结构中位于后序的区块中包括前序区块的哈希值。因此位于链式结构最末端的后序区块中可以包括链式结构上前序所有区块的哈希值，这保证了位于链式结构最末端的后序区块中可以包括链式结构上前序所有区块的信息。因此在进行共识时，仅验证链式结构上的最末端的区块即可。同时，进行共识时也不会影响前序区块中的交易的执行。
在第一共识轮次中，节点会重新开始新一轮的共识，此时主节点可以在当前本地最新区块的基础上针对共识提案消息新建一个第一提案区块。由于后序区块上包括链式结构中前序所有区块中的信息，因此在后续进行共识时，只需要验证新建的第一提案区块即可，无需验证链式结构上的所有区块，大大提高了共识的效率；也将区块链的共识与交易的执行实现了解耦。
由于需要进行新一轮的共识，因此可以将第一共识提案区块、第二共识轮次中生成的第一投票结果集合以及目标交易封装在共识提案消息中，并利用主节点广播给目标节点。
其中，主节点广播封装有第一共识提案区块、第二共识轮次中生成的第一投票结果集合以及目标交易的共识提案消息时，实际上需要广播给区块链中除自身之外的其他所有节点。
23、主节点接收目标节点针对共识提案消息生成的第一投票结果。
当主节点将封装有第一共识提案区块、第二共识轮次中生成的第一投票结果集合以及目标交易的共识提案消息广播给目标节点后，目标节点会再次针对共识提案消息进行投票，得到第一共识轮次中的第一投票结果，并将各自生成的第一投票结果反馈给主节点。即主节点会接收第一共识轮次中，目标节点针对共识提案消息生成的第一投票结果。
需要说明的是，在本申请的实施例中，其他节点为每个共识轮次中，除主节点自身之外区块链中的其他所有节点。因此主节点在每个共识轮次中接收到的第一投票结果实际上为多个。
24、主节点根据第一投票结果，判断第二共识轮次是否为检查点轮次。
当主节点接收到其他节点的第一投票结果后，主节点还需要判断第二轮次是否为检查点轮次；即主节点需要判断当前所处的共识轮次的上一个共识轮次是否为检查点轮次。
25、若第二共识轮次为检查点轮次，主节点根据第一投票结果判断区块链针对目标交易是否达成共识。
在本申请的实施例中，在交易执行过程中会设置多个共识轮次，只有当区块链处于检查点轮次时，才会在检查点轮次的下一个共识轮次中判断目标交易是否达成共识，无需在每个共识轮次均进行判断。
本申请提供一种区块链的共识方法，通过设计检查点轮次，使得无需在每一个共识轮次中都同步等待所有节点的交易执行结果，减少了交易执行对于共识的影响，提高了共识的稳定性。且由于会新建区块，新建的区块中包括区块链中前序区块的执行结果以及状态，仅对新建的区块进行一致性校验，避免了内存资源以及计算资源的浪费。同时检查点轮次可灵活自定义，提升了共识算法的可拓展性。
在本申请的实施例中，主节点根据第一投票结果，判断第二共识轮次是否为检查点轮次，可以包括：
主节点判断自身是否接收到第一预设数量的第一投票结果；若是，主节点确定第二共识轮次是否为检查点轮次。
具体的，在节点针对共识提案消息进行投票的过程中，每个节点投票所需的时间不同，因此节点将生成的第一投票结果发送给主节点具有一定的先后顺序。在第一共识轮次主节点接收目标节点的第一投票结果的过程中，主节点可以随时监控自身接收到的第一投票结果的数量、若是第一共识轮次中主节点接收到了第一预设数量的第一投票结果，那么此时主节点无需再判断未接收到的第一投票结果，主节点可以直接判断上一轮次即第二共识轮次是否为检查点轮次。即在本申请的实施例中，只要主节点接收到了第一预设数量的第一投票结果，主节点即可开始判断上一个共识轮次是否为检查点轮次。
在本申请的一些实施例中，第一预设数量可以为三分之二节点数量，即若是主节点接收到了区块链中三分之二节点反馈的第一投票结果，那么主节点可以判断第二共识轮次是否为检查点轮次。在本申请的其他实施例中，第一预设数量也可以为其他数量的节点，例如超过二分之一的节点，或是五分之四的节点等，第一预设数量可以根据区块链的实际情况设定，此处不做限定。
在本申请的实施例中，多个共识轮次之间是连续的，且检查点轮次是可以自定义的，即可以指定多个连续的共识轮次中任意共识轮次为检查点轮次。而在实际的区块链中，为了便于判断共识的时间，通常会设置检查点轮次对应的规则。例如，可以将十个共识轮次作为一个循环周期，即每相邻且连续的十个共识轮次中的第十个共识轮次作为检查点轮次。当共识轮次循环到检查点轮次后，主节点会在检查点轮次之后的下一个共识轮次对目标交易进行共识。
其中，检查点轮次对应的规则通常在区块链运行时就已经配置好，并将对应的规则广播给区块链中的每一个节点，使得每一个节点都可以判断当前所处的共识轮次是否为检查点轮次。且当区块链开始运行时，共识轮次也随之开始运行，在共识轮次中实现对目标交易是否达到共识进行判断。
在本申请的实施例中，若是区块链中的节点处于检查点轮次，则节点针对共识提案消息生成第一投票结果的同时，还会生成目标交易执行结果的哈希值，并将第一投票结果和目标交易执行结果的哈希值一并发送给主节点。而若是区块链中的节点不处于检查点轮次，则节点只会生成针对共识提案消息的第一投票结果，无需等待目标交易执行结果的生成，只将不包括交易执行结果的第一投票结果发送给主节点即可。
因此在本申请的实施例中，只有当上一个共识轮次为检查点轮次，才会在下一个共识轮次中对目标交易的执行结果进行共识；无需在每个共识轮次均等待所有节点的目标交易执行结果，浪费时间，影响共识。
在本申请的一些实施例中，若第二共识轮次为检查点轮次，则在第二共识轮次内，目标节点会生成第一投票结果以及目标交易执行结果，即目标交易执行结果的哈希值，而目标交易执行结果的哈希值封装在第一投票结果中，随着第一投票结果发送给主节点的同时一并发送给主节点。同时，主节点接收到目标节点发来的第一投票结果后，会将第一投票结果聚合起来形成第一投票结果集合，第一投票结果集合中包括多个第一投票结果，且每个第一投票结果中均包括交易执行结果的哈希值。
如图3所示，为本申请实施例提供的主节点判断目标交易是否达成共识的一实施例流程示意图，可以包括：
31、若第二共识轮次为检查点轮次，主节点判断第二共识轮次中生成的第一共识提案消息集合中的多个交易执行结果是否一致。
具体的，由于区块链中的每个节点均可以判断自身所处的当前共识轮次是不是检查点轮次，因此若是第二共识轮次为检查点轮次，则在第二共识轮次时，每个节点均生成了针对共识提案消息的第一投票结果，以及针对目标交易的交易执行结果。在第一共识轮次时，主节点会接收到第二共识轮次中生成的包括交易执行结果的第一投票结果集合，主节点可以根据包括交易执行结果的第一投票结果集合判断目标交易是否达成共识。
具体的，主节点先会判断接收到第一投票结果集合中的交易执行结果是否一致，即判断目标节点在第二共识轮次中生成的交易执行结果的哈希值是否一致。若是有第二预设数量的交易执行结果的哈希值一致，则主节点可以聚合出一个检查点(Checkpoint)信息，并将检查点信息聚合在第一投票结果集合中，即此时的第一投票结果集合中不仅包括检查点信息，也包括目标节点的交易执行结果的哈希值，以及多个第一投票结果。
在本申请的一些实施例中，第二预设数量可以为三分之二的节点，即若是主节点判断有至少三分之二的节点的目标交易执行结果的哈希值一致，则主节点可以认为其他所有节点的目标交易的执行结果一致。
需要说明的是，在上述实施例中，判断第一投票结果集合中的多个交易执行结果是否一致，实际上是依次判断第一投票结果集合中的多个交易执行结果的哈希值是否一致。若有至少三分之二的交易执行结果一致的，则可以认为其他所有节点之间达成了交易的一致性，即达成了共识。
在上述实施例中，第二预设数量也可以为除三分之二节点数量之外的其他数量，例如二分之一节点数量，或是五分之四节点数量。第二预设数量的具体值可以根据区块链的实际情况设定，此处不做限定。
32、若第二预设数量的节点的交易执行结果一致，则主节点生成检查点信息，并将检查点信息聚合在第一投票结果集合中。
当主节点检测到有第二预设数量的节点的交易执行结果一致，则主节点会生成检查点信息，该检查点信息可以表示上一个共识轮次即第二共识轮次中，除主节点之外的其他节点中的交易执行结果一致。
33、主节点判断自身根据目标交易生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致。
在上述实施例中，主节点在判断其他节点针对目标交易达成共识之后，还需要判断主节点自身与其他节点之间也达成了共识，才能认为整个区块链上的所有节点针对目标交易达成了共识。
因此，主节点还需要判断自身根据目标交易生成的交易执行结果，与第二共识轮次中 生成的第一投票结果集合中的交易执行结果是否一致。且由于第二共识轮次中生成的第一投票结果集合中的交易执行结果已经一致，因此主节点判断自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易的执行结果是否一致，实际上只需要判断主节点自身生成的交易执行结果与第二共识轮次中生成的第一投票结果集合中的任一个交易执行结果之间是否一致。
34、若主节点自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则确定区块链针对目标交易达成共识。
在本申请的实施例中，若是如果主节点判断自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则可以确定主节点与目标节点针对目标交易达成共识，而由于目标节点可以为多个节点中除主节点之外的其他任意节点，因此可以认为区块链中的多个节点之间针对目标交易达成一致，实现共识。即目标交易在区块链的所有节点上按照一致的顺序执行，且目标交易的执行结果也一致；达成了交易序列一致性以及状态一致性。
在上述实施例中，若是主节点自身生成的交易执行结果与第二共识轮次中生成的第一投票结果集合中的交易执行结果不一致，则可以确认主节点与目标节点之间没有达到共识。此时主节点等待此次共识超时。同时，在本申请的实施例中，可以重新切换主节点，得到新主节点，而新主节点可以针对目标交易重新开始达成共识。
在本申请的另一些实施例中，若是第二共识轮次不为检查点轮次，则主节点需要重新聚合目标节点在第一共识轮次生成的第一投票结果，生成第二投票结果集合。此时聚合得到的第二投票结果集合是在第一共识轮次中聚合得到的。同时，也可以重新切换的主节点，得到新主节点，而新主节点针对目标交易可以重新达成共识。
具体的，切换后的新的主节点对于共识的判断已经进入了下一个共识轮次，即第三共识轮次，而第三共识轮次为与第一共识轮次相邻的后序共识轮次。切换后的新的主节点可以在本地最新区块(即包括第一共识提案区块)的基础上重新构建第二共识提案区块，而此时的新主节点中包括上一任主节点(即第一共识轮次中的主节点)在第一共识轮次中生成的第二投票结果集合，由于区块链的特性使得第二提案区块中包括上一任主节点(即第一共识轮次中的主节点)在第一共识轮次中生成的第二投票结果集合。
在上述实施例中，第二提案区块还需要连同第一共识轮次中生成的第二投票结果集合，以及目标交易一起封装在共识提案消息中。而第三共识轮次中的主节点将此时包括第二投票结果集合的共识提案消息广播给目标节点，在第三共识轮次中重新开始共识。
需要说明的是，在本申请的实施例中，在一个共识轮次中仅有一个主节点，但区块链中的所有节点均可以作为主节点，因此可以在不同的共识轮次中切换主节点。而在本申请的一些实施例中，切换主节点的方法可以为：将区块链中的多个节点按照链式结构的顺序编号；以所述链式结构中位于第一个的节点为初始主节点；当需要切换主节点时，按照编号的顺序依次切换主节点。
本申请实施例还提供一种区块链的共识方法，其中区块链中包括多个节点，而多个节点之间互相连接。在区块链运行时，会设置有多个共识轮次对区块链上执行的交易进行共识，以保证交易在区块链中不同节点上执行序列的一致性以及执行结果的一致性。
而在多个共识轮次中包括有检查点轮次，在一个共识轮次中，区块链的多个节包括一个主节点和目标节点；目标节点同样为多个节点中除主节点之外的其他所有节点中的任意节点。而目标交易在区块链执行后会生成针对目标交易的共识提案消息以对目标交易实现共识。
如图4所示，为本申请实施例提供的区块链的共识方法另一实施例流程示意图，可以包括：
41、在多个共识轮次中的第一共识轮次内，目标节点接收来自主节点的第一共识提案区块。
在本申请的实施例中，每一个共识轮次中，目标节点将会接收来自主节点的第一共识提案区块；而第一共识提案区块中可以包括针对目标交易的共识提案消息，且目标节点可以为区块链的多个节点中除主节点之外的其他所有节点中的任意节点。
42、目标节点判断自身所处的第一共识轮次是否为检查点轮次。
其中，目标节点在接收到主节点发出的第一共识提案区块后，目标节点还需要判断自身是否处于特定的检查点轮次，即目标节点需要判断自身当前所处的第一共识轮次是否为特定的检查点轮次。
43、若第一共识轮次为检查点轮次，目标节点生成与目标交易对应的交易执行结果。
在本申请的实施例中，若目标节点自身处于特定的检查点轮次，则目标节点需要生成
44、目标节点将包括交易执行结果的第一投票结果发送至主节点。
本申请提供一种区块链的共识方法，通过设计检查点轮次，仅在检查点轮次获取所有节点的交易执行结果，无需在每一个共识轮次中都同步等待所有节点的交易执行结果，减少了交易执行对于共识的影响，提高了共识的稳定性。同时检查点轮次可灵活自定义，提升了共识算法的可拓展性。
在本申请的实施例中，区块链中的每一个节点都可以判断自身所处的共识轮次是否为检查点轮次，而检查点轮次通常也是提前设定好的。例如可以将十个共识轮次作为一个循环，即每相邻且连续的十个共识轮次中的第十个共识轮次作为检查点轮次。当目标节点处于预设的检查点轮次时，需要等待节点生成针对目标交易的交易执行结果。
因此若是目标节点判断到自身所处的第一共识轮次不是预设的检查点轮次，那么目标节点可以直接投票给当前共识轮次中的主节点。即目标节点可以直接生成针对共识提案消息的第一投票结果，并反馈给第一共识轮次中的主节点。
在本申请的实施例中，第一共识提案区块中还可以包括目标节点在第二共识轮次中针对共识提案消息生成的第一投票结果集合，而第二共识轮次为多个共识轮次中在第一共识轮次之前的一个共识轮次。
而在目标节点判断自身所处的第一共识轮次是否为检查点轮次之前，该方法还可以包括：
目标节点判断共识提案消息中是否包括检查点信息；若共识提案消息中包括检查点信息，则目标节点根据检查点信息判断自身是否针对目标交易达成共识。
具体的，在本申请的实施例中，共识提案消息中包括有多个节点在第二共识轮次中生成的第一投票结果集合，而目标节点可以判断自身针对目标交易生成的交易执行结果，与共识提案消息中的第一投票结果集合中的交易执行结果是否相同，以此来判断目标节点是否针对目标交易达成共识。
在上述实施例中，若是目标节点接收到的共识提案消息中包括有检查点信息，则可以确定在上一轮共识轮次中，至少有第二预设数量的节点之间的交易执行结果实现了共识；即至少有第二预设数量的节点之间的交易执行结果实现了交易序列一致性和状态一致性。
由于第一投票结果集合中的至少第二预设数量的交易执行结果之间达成了交易结果的一致性，即多个交易执行结果是一致的；因此目标节点在判断自身是否达成交易的一致性时，只需要将自身生成的交易执行结果与第一投票结果集合中的任一个交易执行结果进行判断即可。且在本申请的实施例中，判断交易执行结果的一致性，实际上是判断交易执行结果的哈希值是否一致。
在上述实施例中，若是判断了目标节点的执行结果与第一投票结果集合中的交易执行结果达成了一致，即可以确定目标节点的本地执行区块链状态与第一共识提案区块之间达 成了一致性。又由于第一共识提案区块中包括有位于第一共识提案区块前序的所有区块的哈希值，因此可以认为目标节点的本地执行状态链区块与全网达成了一致性。
而若是目标节点没有达成交易的一致性，则目标节点可以拒绝生成第一投票结果，并等待此次共识超时。最终切换主节点，得到新主节点，而重新生成的新主节点针对共识提案消息重新开始共识。
在本申请的另一些实施例中，若是目标接收到的第一共识提案区块中的第一投票结果集合，不包括检查点信息，则目标节点需要判断自身是否处于特定的检查点轮次。若是目标节点处于特定的检查点轮次，则目标节点需要等待本次共识轮次结束前最新生成的提案区块中的交易执行结果，并针对共识提案消息重新生成第一投票结果，将包括交易执行结果的第一投票结果发送给主节点。
在本申请的另一些实施例中，若是第一共识轮次不为检查点轮次，即目标节点当前所处的共识轮次不是检查点轮次，则目标节点可以直接生成第一投票结果，并发送给当前共识轮次中的主节点，此时的第一投票结果中不包括目标节点生成的交易执行结果。
如图5所示，为本申请实施例提供的区块链的共识方法一具体实施例流程图。如图5中所示，当交易执行结束，新的一轮共识轮次开始后，当前共识轮次中区块链的多个节点会分为主节点和目标节点，而目标节点可以为多个节点中除节点之外的其他所有节点中的任意节点。
而主节点在发送每轮共识的共识提案消息之前，会在本地最新的区块的基础上重新构建一个第一提案区块。由于区块链的特性，使得最新构建的第一提案区块中包括了位于第一提案区块之前的所有区块中的信息，因此在后续的共识过程中，仅需要验证第一共识提案区块中的信息即可。
在图5中，当第一共识提案区块构建完成后，而共识提案消息中会封装第一共识提案区块、上一轮共识轮次中产生的第一投票结果集合以及目标交易，并广播给目标节点。其中，区块链中的节点在每一次共识轮次中均会针对共识提案消息生成第一投票结果；且若是共识轮次为预设的检查点轮次，则第一投票结果中还会包括目标节点针对目标交易生成的交易执行结果。
而目标节点在接收到主节点提出的共识提案消息之后，首先会判断共识提案消息中的第一投票结果集合中，是否包括检查点信息(即checkpoint信息)。其中检查点信息是每个共识轮次中的主节点在对应的共识轮次中生成的，且只有上一个轮次为检查点轮次，当前轮次中的主节点才会生成检查点信息。
例如多个共识轮次中包括相邻的第一共识轮次和第二共识轮次，且第二共识轮次在第一共识轮次之前，只有第二共识轮次为预设的检查点轮次，第一共识轮次中的主节点才会在第一共识轮次中生成检查点信息。同时，若是节点处于检查点轮次，则区块链中的多个节点均会生成针对目标交易的交易执行结果。
若是目标节点判断出第一投票结果集合中包括检查点信息，则目标节点需要判断自身针对目标交易生成的本地目标交易执行结果与第一投票结果集合中的交易执行结果是否一致。
若是目标节点判断本地目标交易执行结果与第一投票结果集合中的交易执行结果一致，则可以确定目标节点的本地执行结果与全网执行结果一致，即目标节点针对目标交易达到了共识，即目标节点针对目标交易达成了交易序列一致性以及状态一致性。
而若是目标节点判断自身的本地执行结果与全网结果不一致，则目标节点等待此次共识超时。
在图5所示的实施例中，若是目标交易在区块链上执行时，区块链处于第一个共识轮次，此时不存在上一共识轮次的第一投票结果集合；则此时目标节点接收到主节点发出的 共识提案消息后，会直接判断自身是否处于特定的检查点轮次，而不再判断第一投票结果集合中是否包括检查点信息。或者也可以说是由于不存在上一共识轮次中的第一投票结合，因此第一投票结果集合中不存在检查点信息。
若是第一投票结果集合中不包括检查点信息，或是目标节点已经达成了交易共识，则目标节点还要判断自身是否处于特定的检查点轮次。若是目标节点自身处于特定的检查点轮次，则目标节点需要等待截止到本次共识轮次为止，区块链中最新区块针对目标交易生成的交易执行结果。即可以为第一共识提案区块针对目标交易生成的交易执行结果。
而目标节点再投票给主节点，即目标节点将包括交易执行结果的第一结果投票信息发送给当前共识轮次中的主节点。而若是主节点判断自身并未处于特定的检查点轮次，则目标节点直接投票给主节点。
而当前共识轮次中的主节点在接收到第一预设数量的来着目标节点的第一投票信息后，主节点需要判断位于当前共识轮次的上一个共识轮次是否为预设的检查点轮次。若上一个共识轮次为检查点轮次，则主节点需要聚合出包括检查点信息的第一投票信息集合；若上一个共识轮次不是检查点轮次，则主节点聚合出不包括检查点信息的第一投票信息集合，并等待此次共识超时。
在图5中，当主节点聚合包括检查点信息的第一投票信息集合时，主节点实际上是判断是否有第二预设数量的交易执行结果一致，若有第二预设数量的交易执行结果一致，则主节点可以聚合出包括检查点信息的第一投票信息集合。
而在主节点聚合出包括检查点信息的第一投票信息集合后，主节点还需要判断自身针对目标交易生成的交易执行结果，与包括检查点信息的第一投票结果集合中的交易执行结果是否一致。若两者一致，则可以认为主节点针对目标交易达成了交易序列的一致性以及状态的一致性，即区块链中的所有节点针对目标交易达成了共识。此时可以重新开始新一轮共识。
在图5中，若是主节点判断本地的交易执行结果与包括检查点信息的第一投票结果集合中的交易执行结果不一致，则主节点等待此次共识超时。
在图5中，在等待此次共识超时后，区块链中会进入主节点切换流程，选举出新主节点，而新主节点重新开始针对目标交易达成共识。
本申请还提供一种区块链的共识装置，应用于区块链，而区块链中包括多个节点，多个节点之间互相连接；区块链在运行时设有多个共识轮次以对区块链上执行的交易进行共识，多个共识轮次中包括检查点轮次，在一个共识轮次内，多个节点中包括一个主节点和目标节点，目标节点为多个节点中除主节点之外的其他所有节点中的任意节点；目标交易在区块链中执行后会生成针对目标交易的共识提案消息。
为了更好实施本申请实施例中区块链的共识方法，在区块链的共识方法基础之上，本申请实施例中还提供一种区块链的共识装置，如图6所示，为本申请实施例提供的区块链的共识装置一实施例示意图，该区块链的共识装置可以包括：
第一接收模块601，第一接收模块601用于在多个共识轮次中的第一共识轮次中，接收多个节点在第二共识轮次针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次。
提案区块生成模块602，提案区块生成模块602用于在第一共识轮次中，针对共识提案消息生成第一共识提案区块，共识提案消息中包括第一共识提案区块、第二共识轮次中的第一投票结果集合以及目标交易。
第二接收模块603，第二接收模块603用于接收目标节点针对共识提案消息生成的第一投票结果。
第一判断模块604，第一判断模块604用于根据第一投票结果，判断第二共识轮次是 否为检查点轮次；
第二判断模块605，第二判断模块605用于若第二共识轮次为检查点轮次，根据第一投票结果判断区块链针对目标交易是否达成共识。
本申请提供一种区块链的共识装置，通过设计检查点轮次，使得无需在每一个共识轮次中都同步等待所有节点的交易执行结果，减少了交易执行对于共识的影响，提高了共识的稳定性。且由于会新建区块，新建的区块中包括区块链中前序区块的执行结果以及状态，仅对新建的区块进行一致性校验，避免了内存资源以及计算资源的浪费。同时检查点轮次可灵活自定义，提升了共识算法的可拓展性。
在本申请的另一些实施例中，第一判断模块604主要可以用于主节点判断自身是否接收到第一预设数量的第一投票结果；若是，则主节点确定第二共识轮次为检查点轮次。
在本申请的另一些实施例中，若第二共识轮次为检查点轮次，则在第二共识轮次内，目标节点生成与目标交易对应的交易执行结果，第二共识轮次中生成的第一投票结果集合中包括交易执行结果，第二共识轮次中生成的第一投票结果集合中的交易执行结果为多个。
而第二判断模块605主要可以用于若第二共识轮次为检查点轮次，主节点判断第二共识轮次中生成的第一投票结果集合中的多个交易执行结果是否一致；若第二预设数量的节点的交易执行结果一致，则主节点生成检查点信息，并将检查点信息聚合在第二共识轮次中生成的第一投票结果集合中；主节点判断自身根据目标交易生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致；若主节点自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则确定区块链针对目标交易达成共识。
为了更好实施本申请实施例中区块链的共识方法，在区块链的共识方法基础之上，本申请实施例中还提供一种区块链的共识装置，如图7所示，为本申请实施例提供的区块链的共识装置另一实施例示意图。该区块链的共识装置应用于区块链，区块链中包括多个节点，多个节点之间互相连接；区块链在运行时设有多个共识轮次以对区块链上执行的交易进行共识，多个共识轮次中包括检查点轮次，在一个共识轮次内，多个节点中包括一个主节点和目标节点，目标节点为多个节点中除主节点之外的其他所有节点中的任意节点；目标交易在区块链中执行后会生成针对目标交易的共识提案消息。
如图7中所示，该区块链的共识装置可以包括：
第三接收模块701，第三接收模块701用于在多个共识轮次中的第一共识轮次内，接收来自主节点的共识提案消息，共识提案消息中包括多个节点在第二共识轮次中针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次。
第三判断模块702，第三判断模块702用于判断自身所处的第一共识轮次是否为检查点轮次。
获取模块703，获取模块703用于若第一共识轮次为检查点轮次，获取与目标交易对应的交易执行结果，交易执行结果封装在目标节点在第一共识轮次中生成的第一投票结果中。
发送模块704，发送模块704用于将包括交易执行结果的第一投票结果发送至主节点。
本申请提供一种区块链的共识装置，通过设计检查点轮次，仅在检查点轮次获取所有节点的交易执行结果，无需在每一个共识轮次中都同步等待所有节点的交易执行结果，减少了交易执行对于共识的影响，提高了共识的稳定性。同时检查点轮次可灵活自定义，提升了共识算法的可拓展性。
本申请还提供一种服务器，其集成了本申请实施例所提供的任一种区块链的共识装置，如图8所示，其示出了本申请实施例所涉及到的服务器的结构示意图，具体来讲：
该服务器可以包括一个或者一个以上处理核心的处理器801、一个或一个以上计算机 可读存储介质的存储器802、电源803和输入单元804等部件。本领域技术人员可以理解，图8中示出的服务器结构并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
处理器801是该服务器的控制中心，利用各种接口和线路连接整个服务器的各个部分，通过运行或执行存储在存储器802内的软件程序和/或模块，以及调用存储在存储器802内的数据，执行服务器的各种功能和处理数据，从而对服务器进行整体监控。可选的，处理器801可包括一个或多个处理核心；优选的，处理器801可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器801中。
存储器802可用于存储软件程序以及模块，处理器801通过运行存储在存储器802的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器802可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据服务器的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器802还可以包括存储器控制器，以提供处理器801对存储器802的访问。
服务器还包括给各个部件供电的电源803，优选的，电源803可以通过电源管理系统与处理器801逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源803还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
该服务器还可包括输入单元804，该输入单元804可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。
尽管未示出，服务器还可以包括显示单元等，在此不再赘述。具体在本实施例中，服务器中的处理器801会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器802中，并由处理器801来运行存储在存储器802中的应用程序，从而实现各种功能，如下：
在多个共识轮次中的第一共识轮次中，主节点接收多个节点在第二共识轮次针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次；在第一共识轮次中，主节点针对共识提案消息生成第一共识提案区块，共识提案消息中包括第一共识提案区块、第二共识轮次中的第一投票结果集合以及目标交易；主节点接收目标节点针对共识提案消息生成的第一投票结果；主节点根据第一投票结果，判断第二共识轮次为检查点轮次；若第二共识轮次为检查点轮次，主节点根据第一投票结果判断区块链针对目标交易是否达成共识。
或是服务器中的处理器801会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器802中，并由处理器801来运行存储在存储器802中的应用程序，从而实现各种功能，如下：
在多个共识轮次中的第一共识轮次内，目标节点接收来自主节点的共识提案消息，共识提案消息中包括多个节点在第二共识轮次中针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次；目标节点判断自身所处的第一共识轮次是否为检查点轮次；若第一共识轮次为检查点轮次，目标节点获取与所目标交易对应的交易执行结果，交易执行结果封装在目标节点在第一共识轮次中生成的第一投票结果中；目标节点将包括交易执行结果的第一投票结果发送至主节点。
本申请还提供一种计算机可读存储介质，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。 存储介质存储有计算机程序，该计算机程序被处理器进行加载，以执行本申请实施例所提供的任一种区块链的共识方法中的步骤。例如，所述计算机程序被处理器进行加载可以执行如下步骤：
在多个共识轮次中的第一共识轮次中，主节点接收多个节点在第二共识轮次针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次；在第一共识轮次中，主节点针对共识提案消息生成第一共识提案区块，共识提案消息中包括第一共识提案区块、第二共识轮次中的第一投票结果集合以及目标交易；主节点接收目标节点针对共识提案消息生成的第一投票结果；主节点根据第一投票结果，判断第二共识轮次为检查点轮次；若第二共识轮次为检查点轮次，主节点根据第一投票结果判断区块链针对目标交易是否达成共识。
或是所述计算机程序被处理器进行加载可以执行如下步骤：
在多个共识轮次中的第一共识轮次内，目标节点接收来自主节点的共识提案消息，共识提案消息中包括多个节点在第二共识轮次中针对共识提案消息生成的第一投票结果集合，第二共识轮次为第一共识轮次之前的一个共识轮次；目标节点判断自身所处的第一共识轮次是否为检查点轮次；若第一共识轮次为检查点轮次，目标节点获取与所目标交易对应的交易执行结果，交易执行结果封装在目标节点在第一共识轮次中生成的第一投票结果中；目标节点将包括交易执行结果的第一投票结果发送至主节点。
需要说明的是，本申请实施例方法由于是在电子设备中执行，各电子设备的处理对象均以数据或信息的形式存在，例如时间，实质为时间信息，可以理解的是，后续实施例中若提及尺寸、数量、位置等，均为对应的数据存在，以便电子设备进行处理，具体此处不作赘述。
以上对本申请实施例所提供的一种区块链的共识方法、装置、服务器及存储介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (18)

  1. 一种区块链的共识方法，其中，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
    所述方法包括：
    在所述多个共识轮次中的第一共识轮次中，所述主节点接收所述多个节点在第二共识轮次针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
    在所述第一共识轮次中，所述主节点针对所述共识提案消息生成第一共识提案区块，所述共识提案消息中包括所述第一共识提案区块、所述第二共识轮次中的第一投票结果集合以及所述目标交易；
    所述主节点接收所述目标节点针对所述共识提案消息生成的第一投票结果；
    所述主节点根据所述第一投票结果，判断所述第二共识轮次为所述检查点轮次；
    若所述第二共识轮次为所述检查点轮次，所述主节点根据所述第一投票结果判断所述区块链针对所述目标交易是否达成共识。
  2. 根据权利要求1所述的区块链的共识方法，其中，所述主节点根据所述第一投票结果，判断所述第二共识轮次为所述检查点轮次，包括：
    所述主节点判断自身是否接收到第一预设数量的第一投票结果；
    若是，则所述主节点确定所述第二共识轮次为所述检查点轮次。
  3. 根据权利要求2所述的区块链的共识方法，其中，所述主节点判断自身是否接收到第一预设数量的第一投票结果，包括：
    若是所述主节点接收到所述区块链中三分之二节点反馈的第一投票结构，所述主机判断所述第二共识轮次是否为所述检查点轮次。
  4. 根据权利要求1所述的区块链的共识方法，其中，若所述第二共识轮次为所述检查点轮次，则在所述第二共识轮次内，所述目标节点生成与所述目标交易对应的交易执行结果，所述第二共识轮次中生成的第一投票结果集合中包括所述交易执行结果，第二共识轮次中生成的第一投票结果集合中的交易执行结果为多个；
    所述若所述第二共识轮次为所述检查点轮次，所述主节点根据所述第一投票结果判断所述区块链针对所述目标交易是否达成共识，包括：
    若所述第二共识轮次为所述检查点轮次，所述主节点判断所述第二共识轮次中生成的第一投票结果集合中的多个交易执行结果是否一致；
    若第二预设数量的节点的交易执行结果一致，则所述主节点生成检查点信息，并将所述检查点信息聚合在所述第二共识轮次中生成的所述第一投票结果集合中；
    所述主节点判断自身根据所述目标交易生成的交易执行结果，与所述第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致；
    若所述主节点自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则确定所述区块链针对所述目标交易达成共识。
  5. 根据权利要求4所述的区块链的共识方法，其中，所述主节点判断自身根据所述目标交易生成的交易执行结果，与所述第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致，包括：
    判断所述主节点自身生成的交易执行结果，与所述第二共识轮次中生成的第一投票结果集合中的任一个交易执行结果之间是否一致。
  6. 根据权利要求4所述的区块链的共识方法，其中，所述方法还包括：
    若所述主节点自身的交易执行结果与所述第二共识轮次中生成的第一投票结果集合中的交易执行结果不一致，则所述主节点等待此次共识超时；
    切换所述主节点，得到新主节点，所述新主节点针对所述目标交易重新达成共识。
  7. 根据权利要求6所述的区块链的共识方法，其中，所述切换所述主节点的方法，包括：
    将所述区块链中的多个节点按照链式结构的顺序编号；以所述链式结构中位于第一个的节点为初始主节点；当需要切换所述主节点时，按照编号的顺序依次切换所述主节点。
  8. 根据权利要求1所述的区块链的共识方法，其中，所述方法还包括：
    若所述第二共识轮次不为所述检查点轮次，则所述主节点重新聚合所述其他节点在所述第一共识轮次生成的所述第一投票结果，生成第二投票结果集合；
    切换所述主节点，得到新主节点，所述新主节点针对所述目标交易重新达成共识。
  9. 根据权利要求8所述的区块链的共识方法，其中，所述方法还包括：
    所述新主节点在所述第一提案区块的基础上构建第二提案区块，所述第二提案区块包括所述第二投票结果集合、所述共识提案消息以及所述目标交易。
  10. 一种区块链的共识方法，其中，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
    所述方法包括：
    在所述多个共识轮次中的第一共识轮次内，所述目标节点接收来自所述主节点的共识提案消息，所述共识提案消息中包括所述多个节点在第二共识轮次中针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
    所述目标节点判断自身所处的第一共识轮次是否为所述检查点轮次；
    若所述第一共识轮次为所述检查点轮次，所述目标节点获取与所述目标交易对应的交易执行结果，所述交易执行结果封装在所述目标节点在所述第一共识轮次中生成的所述第一投票结果中；
    所述目标节点将包括所述交易执行结果的所述第一投票结果发送至所述主节点。
  11. 根据权利要求10所述的区块链的共识方法，其中，在所述目标节点判断自身所处的第一共识轮次是否为所述检查点轮次之前，所述方法还包括：
    所述目标节点判断所述共识提案消息中是否包括检查点信息；
    若包括所述检查点信息，则所述目标节点根据所述检查点信息判断自身是否针对所述目标交易达成共识。
  12. 根据权利要求11所述的区块链的共识方法，其中，所述方法还包括：
    若所述第一共识轮次不为所述检查点轮次，所述目标节点针对所述共识提案消息生成第一投票结果，并发送至所述主节点；
    其中，所述第一投票结果不包括所述目标节点获取的针对所述目标交易的交易执行结果。
  13. 一种区块链的共识装置，其中，应用于区块链，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易 的共识提案消息；
    所述装置包括：
    第一接收模块，所述第一接收模块用于在所述多个共识轮次中的第一共识轮次中，接收所述多个节点在第二共识轮次针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
    提案区块生成模块，所述提案区块生成模块用于在所述第一共识轮次中，针对所述共识提案消息生成第一共识提案区块，所述共识提案消息中包括所述第一共识提案区块、所述第二共识轮次中的第一投票结果集合以及所述目标交易；
    第二接收模块，所述第二接收模块用于接收所述目标节点针对所述共识提案消息生成的第一投票结果；
    第一判断模块，所述第一判断模块用于根据所述第一投票结果，判断所述第二共识轮次为所述检查点轮次；
    第二判断模块，所述第二判断模块用于若所述第二共识轮次为所述检查点轮次，根据所述第一投票结果判断所述区块链针对所述目标交易是否达成共识。
  14. 根据权利要求13所述的区块链共识装置，其中，所述第一判断模块主要用于主节点判断自身是否接收到第一预设数量的第一投票结果；若是，则主节点确定第二共识轮次为检查点轮次。
  15. 根据权利要求13所述的区块链的共识装置，其中，所述第二判断模块主要用于若第二共识轮次为检查点轮次，主节点判断第二共识轮次中生成的第一投票结果集合中的多个交易执行结果是否一致；若第二预设数量的节点的交易执行结果一致，则主节点生成检查点信息，并将检查点信息聚合在第二共识轮次中生成的第一投票结果集合中；主节点判断自身根据目标交易生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果是否一致；若主节点自身生成的交易执行结果，与第二共识轮次中生成的第一投票结果集合中的交易执行结果一致，则确定区块链针对目标交易达成共识。
  16. 一种区块链的共识装置，其中，应用于区块链，所述区块链中包括多个节点，所述多个节点之间互相连接；所述区块链在运行时设有多个共识轮次以对所述区块链上执行的交易进行共识，所述多个共识轮次中包括检查点轮次，在一个所述共识轮次内，所述多个节点中包括一个主节点和目标节点，所述目标节点为所述多个节点中除所述主节点之外的其他所有节点中的任意节点；目标交易在所述区块链中执行后会生成针对所述目标交易的共识提案消息；
    所述装置包括：
    第三接收模块，所述第三接收模块用于在所述多个共识轮次中的第一共识轮次内，接收来自所述主节点的共识提案消息，所述共识提案消息中包括所述多个节点在第二共识轮次中针对所述共识提案消息生成的第一投票结果集合，所述第二共识轮次为所述第一共识轮次之前的一个共识轮次；
    第三判断模块，所述第三判断模块用于判断自身所处的第一共识轮次是否为所述检查点轮次；
    获取模块，所述获取模块用于若所述第一共识轮次为所述检查点轮次，获取与所述目标交易对应的交易执行结果，所述交易执行结果封装在所述目标节点在所述第一共识轮次中生成的所述第一投票结果中；
    发送模块，所述发送模块用于将包括所述交易执行结果的所述第一投票结果发送至所述主节点。
  17. 一种服务器，其中，所述服务器包括：
    一个或多个处理器；
    存储器；以及
    一个或多个应用程序，其中所述一个或多个应用程序被存储于所述存储器中，并配置为由所述处理器执行以实现如权利要求1至9任一项所述的区块链的共识方法，或实现如权利要求10至12任一项所述的区块链的共识方法。
  18. 一种计算机可读存储介质，其中，其上存储有计算机程序，所述计算机程序被处理器进行加载，以执行如权利要求1至9任一项所述的区块链的共识方法中的步骤，或实现如权利要求10至12任一项所述的区块链的共识方法中的步骤。
PCT/CN2021/071152 2020-12-24 2021-01-12 一种区块链的共识方法、装置、服务器及存储介质 WO2022134233A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/340,102 US20230334930A1 (en) 2020-12-24 2023-06-23 Consensus method and apparatus for blockchain, server and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011548287.3 2020-12-24
CN202011548287.3A CN112669149B (zh) 2020-12-24 2020-12-24 一种区块链的共识方法、装置、服务器及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/340,102 Continuation US20230334930A1 (en) 2020-12-24 2023-06-23 Consensus method and apparatus for blockchain, server and storage medium

Publications (1)

Publication Number Publication Date
WO2022134233A1 true WO2022134233A1 (zh) 2022-06-30

Family

ID=75409950

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/071152 WO2022134233A1 (zh) 2020-12-24 2021-01-12 一种区块链的共识方法、装置、服务器及存储介质

Country Status (3)

Country Link
US (1) US20230334930A1 (zh)
CN (1) CN112669149B (zh)
WO (1) WO2022134233A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115760388A (zh) * 2022-11-07 2023-03-07 深圳市腾盟技术有限公司 基于区块链的共识方法、装置、设备及存储介质
CN116723200A (zh) * 2023-08-11 2023-09-08 杭州趣链科技有限公司 集群变更方法、装置、电子设备及计算机可读存储介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113452747B (zh) * 2021-05-13 2022-12-16 西安电子科技大学 可扩展和安全的共识方法、系统、存储介质、智能终端
CN113342902B (zh) * 2021-08-09 2021-11-12 腾讯科技（深圳）有限公司 区块链网络的数据处理方法、装置、计算机设备和介质
CN113850600B (zh) * 2021-12-01 2022-04-26 深圳前海微众银行股份有限公司 基于区块链的交易共识方法、装置、设备及存储介质
CN114422155B (zh) * 2022-03-30 2022-08-02 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质
CN114900529B (zh) * 2022-06-09 2024-08-23 上海万向区块链股份公司 区块敲定方法及系统
CN115186035B (zh) * 2022-09-13 2022-11-22 腾讯科技（深圳）有限公司 一种区块处理方法、相关系统及存储介质和服务器
CN115618426B (zh) * 2022-11-17 2023-04-28 山东区块链研究院 基于检查点的区块链数据防篡改方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109242685A (zh) * 2018-08-29 2019-01-18 众安信息技术服务有限公司 基于区块链的共识和验证方法及装置
CN109559120A (zh) * 2018-12-03 2019-04-02 国网电子商务有限公司 基于权重的区块链共识方法、系统、存储介质及电子设备
WO2020072659A1 (en) * 2018-10-02 2020-04-09 Mutualink, Inc. Consensus-based voting for network member identification employing blockchain-based identity signature mechanisms
CN111427957A (zh) * 2020-03-26 2020-07-17 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10586210B2 (en) * 2016-11-30 2020-03-10 International Business Machines Corporation Blockchain checkpoints and certified checkpoints
CN109118230B (zh) * 2018-08-29 2022-04-05 众安信息技术服务有限公司 基于区块链的信息处理方法和装置
US11334439B2 (en) * 2018-08-29 2022-05-17 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US11526487B2 (en) * 2019-05-17 2022-12-13 International Business Machines Corporation Database world state integrity validation
CN110727644B (zh) * 2019-09-29 2022-06-24 南京金宁汇科技有限公司 一种区块链数据裁剪的方法、系统及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109242685A (zh) * 2018-08-29 2019-01-18 众安信息技术服务有限公司 基于区块链的共识和验证方法及装置
WO2020072659A1 (en) * 2018-10-02 2020-04-09 Mutualink, Inc. Consensus-based voting for network member identification employing blockchain-based identity signature mechanisms
CN109559120A (zh) * 2018-12-03 2019-04-02 国网电子商务有限公司 基于权重的区块链共识方法、系统、存储介质及电子设备
CN111427957A (zh) * 2020-03-26 2020-07-17 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115760388A (zh) * 2022-11-07 2023-03-07 深圳市腾盟技术有限公司 基于区块链的共识方法、装置、设备及存储介质
CN115760388B (zh) * 2022-11-07 2023-11-21 深圳市腾盟技术有限公司 基于区块链的共识方法、装置、设备及存储介质
CN116723200A (zh) * 2023-08-11 2023-09-08 杭州趣链科技有限公司 集群变更方法、装置、电子设备及计算机可读存储介质
CN116723200B (zh) * 2023-08-11 2023-11-10 武汉趣链数字科技有限公司 集群变更方法、装置、电子设备及计算机可读存储介质

Also Published As

Publication number Publication date
CN112669149B (zh) 2024-06-04
CN112669149A (zh) 2021-04-16
US20230334930A1 (en) 2023-10-19

Similar Documents

Publication Publication Date Title
WO2022134233A1 (zh) 一种区块链的共识方法、装置、服务器及存储介质
WO2020024405A1 (zh) 基于分布式协调的测试方法、装置、服务器及存储介质
WO2019153488A1 (zh) 服务配置管理方法、装置、存储介质和服务器
CN108228102B (zh) 节点间数据迁移方法、装置、计算设备及计算机存储介质
CN103957237A (zh) 一种弹性云的体系结构
US11656902B2 (en) Distributed container image construction scheduling system and method
WO2021184177A1 (zh) 主节点选取方法、装置、电子设备以及存储介质
CN112231108A (zh) 任务处理方法、装置、计算机可读存储介质及服务器
WO2022007908A1 (zh) 网元设备间业务协同的方法和网元设备
CN102981857A (zh) 数据库集群的并行压缩海量数据装载方法
WO2024037629A1 (zh) 区块链的数据整合方法、装置、计算机设备及存储介质
WO2023050706A1 (zh) 一种数据库多写方法、装置及相关设备
CN111352716A (zh) 一种基于大数据的任务请求方法、装置、系统及存储介质
WO2024077881A1 (zh) 神经网络训练的调度方法、系统及计算机可读存储介质
CN111400041A (zh) 服务器配置文件的管理方法、装置及计算机可读存储介质
CN114760304B (zh) 算力信息的处理方法、处理系统及算力网关
CN111711669A (zh) 一种数据上传方法、装置、服务器及存储介质
CN112468589A (zh) 数据分发方法、装置、计算机设备和存储介质
CN115396479A (zh) 机器人与云平台命令交互的方法、系统及存储介质
CN107547593B (zh) 一种实现日志同步的方法、装置及分布式系统
CN112511595B (zh) 一种消息推送方法及消息服务系统
US20130013892A1 (en) Hierarchical multi-core processor, multi-core processor system, and computer product
CN116820527A (zh) 程序升级方法、装置、计算机设备和存储介质
CN113407384B (zh) peer节点指令传输的方法、装置、代理服务器及存储介质
CN114338763B (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: 21908252

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21908252

Country of ref document: EP

Kind code of ref document: A1