WO2023184881A1 - 提案共识执行方法、区块链系统、设备和存储介质 - Google Patents

提案共识执行方法、区块链系统、设备和存储介质 Download PDF

Info

Publication number
WO2023184881A1
WO2023184881A1 PCT/CN2022/118807 CN2022118807W WO2023184881A1 WO 2023184881 A1 WO2023184881 A1 WO 2023184881A1 CN 2022118807 W CN2022118807 W CN 2022118807W WO 2023184881 A1 WO2023184881 A1 WO 2023184881A1
Authority
WO
WIPO (PCT)
Prior art keywords
proposal
round
check information
information
node
Prior art date
Application number
PCT/CN2022/118807
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 WO2023184881A1 publication Critical patent/WO2023184881A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Definitions

  • This application relates to the field of blockchain technology, and in particular to a proposal consensus execution method, blockchain system, equipment and storage media.
  • the consensus protocol is responsible for consistently sorting the transactions received from the client to obtain the sorted transaction sequence, and the state machine only needs to be responsible for executing the sorted transaction sequence.
  • the consensus task of the consensus protocol has been completed after determining the consistency of the transaction sequence.
  • the same state machine executing the same transaction sequence will give the same execution result.
  • state machines are not guaranteed to be safe. Problems at the software level and hardware level may cause different nodes to run the same state machine and execute the same transaction sequence but obtain different execution results. For this reason, the consensus protocol is also necessary to verify the consistency of the execution results.
  • This application provides a proposal consensus execution method, blockchain system, equipment and storage media, which can completely decouple the consensus process from the execution process, and is solely responsible for the verification and consistency guarantee of the execution results through the inspection mechanism, thereby ensuring consensus activity and avoid waste of processing resources.
  • a proposal consensus execution method is provided, which is applied to a blockchain system.
  • the blockchain system includes multiple nodes.
  • the method includes:
  • Each node of the plurality of nodes performs the following operations:
  • the inspection information of the k-th proposal is generated based on the execution result of the k-th proposal among the k proposals, and the inspection information of the k-th proposal is stored in the local inspection information set, so K is a positive integer;
  • aggregate check information which includes check information with consistent execution results generated by at least some nodes among the plurality of nodes for the same proposal; perform inspection information in the local check information set with the aggregate check information. Compare to determine stable check information from the local check information set, and the execution results of the proposals to which the stable check information belongs are consistent.
  • the multiple nodes have one master node and multiple slave nodes in each round of consensus process, and the method further includes:
  • the i-th round master node generates the i-th round proposal and sends a proposal message carrying the i-th round proposal to the i-th round slave node, where the i is a positive integer;
  • the i+1-th round slave node determines that the proposal message is legal, it will send a vote for the i-th round proposal to the i+1-th round master node;
  • the i+1-th round master node generates the aggregate voting information of the i-th round proposal based on the i+1-th round slave node's vote for the i-th round proposal, generates the i+1-th round proposal, and sends the i-th round proposal to all
  • the i+1-th round slave node sends a proposal message carrying the i+1-th round proposal and the aggregate voting information of the i-th round proposal.
  • the obtaining aggregation check information includes:
  • the aggregate inspection information is generated based on the multiple inspection information.
  • the multiple nodes have one master node and multiple slave nodes in each round of consensus process.
  • the obtaining the aggregation check information includes:
  • the i+1-th round slave node After determining that the proposal message carrying the i-th round proposal is legal, the i+1-th round slave node carries the vote for the i-th round proposal and the latest generated check information in a message and sends it to the i-th round proposal.
  • the i+1th round master node After acquiring multiple check information belonging to the same proposal, with a quantity greater than or equal to the first quantity threshold, and with the same execution results, the i+1th round master node generates the aggregate check information based on the multiple check information. , the aggregation check information, the i+1th round proposal and the aggregate voting information of the ith round proposal are all carried in the proposal message and sent to the i+1th round slave node.
  • the multiple nodes have one master node and multiple slave nodes in each round of consensus process.
  • the obtaining the aggregation check information includes:
  • the latest generated inspection information is sent to the master node in the i+jth round, where j is a positive integer;
  • the aggregate check information is generated based on the multiple check information.
  • the aggregation check information, the i+jth round proposal and the aggregate voting information of the i+j-1th round proposal are all carried in the proposal message and sent to the i+jth round slave node.
  • the first quantity threshold is 2f+1, and f is the number of malicious nodes among the multiple nodes.
  • comparing the inspection information in the local inspection information set with the aggregate inspection information includes:
  • the target check information will be The information is set to the latest stability check information.
  • comparing the inspection information in the local inspection information set with the aggregate inspection information includes:
  • the local check information set contains target check information that belongs to the same proposal as the aggregate check information, and the execution result in the target check information is different from the execution result in the aggregate check information, perform block rollback operate.
  • the multiple nodes have one master node and multiple slave nodes in each round of consensus process, and the method further includes:
  • Each node of the plurality of nodes performs the following operations:
  • the check information of the first proposal is generated as configuration check information based on the execution result of the first proposal, and the configuration check information is stored in the The local check information set, the configuration block is constructed by the master node when processing the consensus cluster change transaction;
  • the multiple nodes have one master node and multiple slave nodes in each round of consensus process, and the method further includes:
  • Each node of the plurality of nodes performs the following operations:
  • the inspection information of the second proposal is generated as mandatory inspection information based on the execution result of the second proposal, and the mandatory inspection information is stored in the As for the local check information set, the verification block is constructed by the master node when the local check information set does not form the stable check information within a preset time period.
  • a blockchain system in a second aspect, includes multiple nodes.
  • the multiple nodes have one master node and multiple slave nodes in each round of consensus process.
  • the block chain system includes The chain system is used to implement the above proposal consensus execution method.
  • a computer device in a third aspect, includes a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the computer program is executed by the processor.
  • a computer-readable storage medium stores a computer program.
  • the computer program is executed by a processor, the above-mentioned proposal consensus execution method is implemented.
  • a computer program product containing instructions which when run on a computer causes the computer to execute the above steps of the proposed consensus execution method.
  • the node when the aggregate voting information of the proposal satisfies the submission rules, the node can submit the proposal and execute the proposal. That is, when the aggregate voting information of the proposal satisfies the submission rules, the node can mark the consensus of the proposal as completed without waiting for the execution result of the proposal. After each node submits a certain number of proposals, it can generate the inspection information of this proposal based on the execution result of the latest submitted proposal and store it in the local inspection information set. After that, the inspection information in the local inspection information set is compared with the aggregate inspection information. To verify whether the execution results of proposals to which the inspection information in the local inspection information set belongs are consistent, to determine stable inspection information from the local inspection information set.
  • the inspection mechanism is solely responsible for the verification and consistency guarantee of the execution results, ensuring the safety of the proposal execution.
  • the consensus process is completely decoupled from the execution process. Since there is no need to intersperse execution processes during the consensus process, the consensus time is predictable, and an appropriate timeout threshold can be used to ensure consensus liveness.
  • the proposal since the proposal will not be executed until it is submitted, it is ensured that the consensus of the proposal to be executed has been completed. At this time, the execution work will not be abandoned due to switching of consensus views and other reasons, so that processing resources will not be wasted.
  • Figure 1 is a schematic structural diagram of a blockchain system provided by an embodiment of the present application.
  • Figure 2 is a flow chart of a proposal consensus execution method provided by the embodiment of this application.
  • Figure 3 is a schematic diagram of a generation process of aggregated inspection information provided by an embodiment of the present application.
  • Figure 4 is a schematic diagram of another generation process of aggregated inspection information provided by an embodiment of the present application.
  • Figure 5 is a schematic diagram of another generation process of aggregated inspection information provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • phrases such as “one embodiment” or “some embodiments” used in this application mean that a particular feature, structure, or characteristic described in the embodiment is included in one or more embodiments of the application. Therefore, the phrases “in one embodiment”, “in some embodiments”, “in some other embodiments”, “in some other embodiments” etc. appearing in different places in this application are not necessarily References are made to the same embodiment, but rather to “one or more but not all embodiments” unless specifically stated otherwise. In addition, the terms “includes,” “includes,” “having,” and variations thereof all mean “including but not limited to,” unless otherwise specifically emphasized.
  • a blockchain system includes multiple nodes, each of which has a transaction pool for storing transactions. After any node among the multiple nodes receives the transaction from the client, it will share the transaction with other nodes, so that the multiple nodes store the transaction in the transaction pool, so that in the transaction pool of the multiple nodes The stored transactions are consistent and transactions in the transaction pool can be processed. For any pending transaction in the transaction pool, the transaction can be executed and stored in the blockchain after obtaining the consensus of the multiple nodes.
  • the consensus protocol is responsible for consistent sorting of transactions and obtaining the sorted transaction sequence.
  • the state machine only needs to be responsible for executing the sorted transaction sequence.
  • the consensus task of the consensus protocol has been completed after determining the consistency of the transaction sequence.
  • the same state machine executing the same transaction sequence will give the same execution result.
  • state machines are not guaranteed to be safe. Problems at the software level and hardware level may cause different nodes to run the same state machine and execute the same transaction sequence but obtain different execution results. For this reason, the consensus protocol is also necessary to verify the consistency of the execution results.
  • the HotStuff consensus algorithm PBFT (Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance) consensus algorithm, Raft consensus algorithm and other consensus algorithms based on the master node (Leader) are used to consensus on the transaction.
  • PBFT Practical Byzantine Fault Tolerance
  • Raft consensus algorithm and other consensus algorithms based on the master node (Leader) are used to consensus on the transaction.
  • the master node-based consensus algorithm requires a master node to lead the consensus process.
  • the master node is a node elected from multiple nodes in the blockchain system and is used to broadcast proposals generated based on transactions. In each round of consensus process, one node will be elected from the multiple nodes as the master node, and other nodes will be used as slave nodes. Proposal consensus is achieved through the master nodes and slave nodes in each round.
  • the following takes the PBFT algorithm as an example to illustrate the proposal consensus execution process in related technologies.
  • the process includes the following steps (1)-step (5):
  • the master node After the master node generates a proposal based on the pending transaction, it does not execute the proposal and directly broadcasts the proposal to the slave node.
  • the master node After the master node broadcasts the proposal, it enters the pre-prepared stage. At the same time, the slave node also enters the pre-prepared stage after receiving the proposal sent by the master node. At this time, both the master node and the slave node execute the proposal. (This process can be called pre-execution).
  • the execution change status ie, pre-execution result
  • a prepare message carrying the execution result is broadcast.
  • any node After any node receives the prepare message sent by other nodes, it compares the execution results carried in the prepare messages. After obtaining 2f+1 prepare messages with consistent execution results, it enters the prepared stage and broadcasts the commit carrying the execution results. (confirmation) message, where f is the number of tolerable Byzantine nodes.
  • any node After any node receives the commit message sent by other nodes, it compares the execution results carried in the commit message. After obtaining 2f+1 commit messages with consistent execution results, the consensus protocol submits the proposal and temporarily stores it. The execution change status is written into the blockchain.
  • a timeout is triggered and the master node switching process is entered. After the master node is switched, the switched master node will initiate a new proposal. After receiving the new proposal, the corresponding slave node will abandon the temporary execution change status and execute the new proposal instead.
  • the embodiments of this application provide a proposal consensus execution method that completely decouples the consensus process from the execution process, and is solely responsible for the verification and consistency guarantee of the execution results through the inspection mechanism, thereby ensuring consensus activity and avoiding the need to process resources. of waste.
  • Figure 1 is a schematic structural diagram of a blockchain system provided by an embodiment of the present application.
  • the blockchain system 100 refers to a system for sharing data between nodes.
  • the blockchain system 100 may include multiple nodes 101.
  • Each node 101 can receive input information when performing normal operations, and maintain shared data within the blockchain system 100 based on the received input information.
  • there may be an information connection between each node 101 in the blockchain system 100 and the nodes 101 may transmit information through the information connection.
  • the nodes 101 may transmit information through the information connection.
  • the nodes 101 in the blockchain system 100 obtain the input information according to the consensus algorithm and store the input information as data in the shared data. , making the data stored on all nodes 101 in the blockchain system 100 consistent. That is, each node 101 in the blockchain system 100 stores the same blockchain.
  • the blockchain system 100 has computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • the blockchain system 100 is a distributed shared ledger and database, which has the characteristics of decentralization, non-tampering, full traceability, traceability, collective maintenance, openness and transparency. These characteristics ensure that the blockchain is shared, open, authentic, complete, safe and reliable.
  • Multiple nodes 101 in the blockchain system 100 have one master node and multiple slave nodes in each round of consensus process.
  • the master node and multiple slave nodes in each round can execute the proposal described in the embodiment of Figure 2 below. Consensus execution method to achieve consensus and execution of each round of proposals.
  • FIG. 2 is a flow chart of a proposal consensus execution method provided by an embodiment of this application. This method is applied to blockchain systems, and specifically can be applied to consensus protocols in blockchain systems.
  • the blockchain system includes multiple nodes, which have a master node and multiple slave nodes in each round of consensus process.
  • the method includes the following steps.
  • Step 201 The i-th round master node generates the i-th round proposal and sends a proposal message carrying the i-th round proposal to the i-th round slave node, where i is a positive integer.
  • a masternode is a node elected from multiple nodes in the blockchain system for broadcasting proposals. In each round of consensus process, one node is elected as the master node and other nodes are used as slave nodes. The consensus of this round of proposals is achieved through the master node and multiple slave nodes in each round.
  • each of the multiple nodes in the blockchain system can be numbered, and then according to the numbering order of the multiple nodes, each node will take turns to be elected as the master node.
  • the master node can also be elected through other methods. , the embodiment of the present application does not limit this.
  • Malicious nodes refer to nodes that cause malicious attacks on the security of the blockchain system. That is, malicious nodes will hinder the consensus on the proposal.
  • the number of the multiple nodes is n
  • the number of malicious nodes in the multiple nodes is f
  • f is less than n/3, where "/" means “division by", for example, n It can be an integer greater than or equal to 4, and f can be a positive integer.
  • the i-th round proposal generated by the i-th round master node is generated based on the transactions pending in the i-th round.
  • the i-th round master node can construct a new block as the i-th round proposal based on the latest locally generated block based on the i-th round of pending transactions, and then carry the i-th round proposal in the proposal message. broadcast to other slave nodes so that other slave nodes can reach consensus on the i-th round proposal.
  • the i-th round master node can also use its own private key to sign the i-th round proposal, and carry the signature in the proposal message.
  • the proposal message broadcast by the i-th round master node can carry the i-th round proposal.
  • the proposal message broadcast by the i-th round master node can not only carry the i-th round proposal, but also the previous round (i.e. Aggregated voting information for proposals in round i-1 (also known as QC (quorum certificate, quorum certificate)).
  • the aggregate voting information of the i-1 round proposal includes the votes of each node for the i-1 round proposal of at least some of the nodes in the blockchain system, and each node's vote for the i-1 round proposal. Voting can include using its own private key to sign the summary information (i.e. hash value) of the i-1 round proposal.
  • Each node can vote for the i-1 round proposal after determining that it is legal. In this way, the aggregate voting information of the proposal in the i-1 round provides evidence of multiple votes for the legitimacy of the proposal in the i-1 round.
  • Step 202 If the i+1-th round slave node determines that the proposal message carrying the i-th round proposal is legal, it will send a vote for the i-th round proposal to the i+1-th round master node.
  • the i+1-th round slave node may include the i-th round master node and the i-th round slave node.
  • the i-th round master node After generating the proposal message carrying the i-th round proposal, it can verify the legitimacy of the proposal message, and when it is determined that the proposal message is legal, it will submit the proposal message to the i+1-th round.
  • the masternode sends votes for the i-th round proposal.
  • For the i-th round slave node after receiving the proposal message carrying the i-th round proposal sent by the i-th round master node, it can verify the legitimacy of the proposal message and determine that the proposal message is legal. , sending votes for the i-th round proposal to the i+1-th round master node.
  • Each node's vote for the i-th round proposal may include signing the summary information of the i-th round proposal using its own private key.
  • the operation of verifying the legality of the proposal message carrying the i-th round proposal is similar to the operation of verifying the legality of a certain proposal message in related technologies, and will not be elaborated in the embodiments of this application.
  • you can verify the signature of the master node carried in the proposal message and you can also verify the transactions included in the i-th round of proposals carried in the proposal message.
  • the proposal message can also be verified to carry the aggregate voting information of the previous round of proposals. For example, the signatures of each node included in the aggregate voting information can be verified.
  • the i+1-th round slave node after the i+1-th round slave node obtains the proposal message carrying the i-th round proposal, it only verifies the legality of the proposal message and does not verify the i-th round proposal. Execution processing, after the legality verification is passed, the vote for the i-th round proposal is sent to the i+1-th round master node. In this way, the execution process is avoided during the consensus process.
  • Step 203 The i+1-th round master node generates the aggregate voting information of the i-th round proposal based on the i+1-th round slave node’s vote for the i-th round proposal, generates the i+1-th round proposal, and submits the i+1-th round proposal to the i+1-th round slave node.
  • the node sends a proposal message carrying the aggregate voting information of the i+1th round proposal and the i-th round proposal.
  • the aggregate voting information of the i-th round proposal provides evidence of multiple votes for the legitimacy of the i-round proposal.
  • the aggregate voting information of the i-th round proposal may include the votes of a certain number of slave nodes in the i+1 round slave nodes for the i-th round proposal.
  • the i+1-th round master node may generate an aggregation of the i-th round proposals based on the multiple votes received for the i-th round proposal when the number of votes received is greater than or equal to the second quantity threshold.
  • Voting information may include the multiple votes, that is, including the votes of each node in the plurality of nodes whose number is greater than or equal to the second quantity threshold for the i-th round proposal.
  • the second quantity threshold can be set in advance.
  • the second quantity threshold can be 2f+1. In this way, if the number of multiple votes received for the i-th round proposal is greater than or equal to 2f+1, it means that there are at least 2f+1 node pairs in the blockchain system. After the i-th round of proposals is voted on, it can be ensured that f malicious nodes in the blockchain system cannot affect the consensus process of normal nodes.
  • the operation of the i+1th round master node to generate the i+1th round proposal is similar to the operation of the ith round master node to generate the ith round proposal, which will not be described again in the embodiment of this application.
  • Step 204 For each node among the multiple nodes, this node obtains the aggregate voting information of a proposal generated during the consensus process. If the aggregate voting information of this proposal satisfies the submission rules, the proposal is submitted and executed. .
  • Each node among the multiple nodes can obtain the aggregate voting information of a certain proposal through the above-mentioned steps 201 to 203.
  • the aggregate voting information of the previous round of proposals can be obtained during each round of consensus.
  • the master node in each round can generate the aggregate voting information of the previous round of proposals, and the slave nodes in each round can receive the aggregate voting information of the previous round of proposals carried in the proposal message sent by the master node. In this way, each node can obtain the aggregate voting information of the proposal.
  • submission rules can be set in advance.
  • the submission rules can be 3-chain submission rules, etc.
  • the aggregate voting information of a certain proposal satisfies the submission rules, indicating that a sufficient number of nodes have voted for the proposal, that is, the consensus on the proposal has been completed, and therefore the proposal can be submitted at this time.
  • chain refers to the chain consensus process.
  • the 3-chain submission rule refers to: after obtaining the aggregate voting information of each round of proposals in three consecutive rounds of proposals, submit the earliest proposal generated among the three rounds of proposals. In this case, if the aggregate voting information of each round of proposals in three consecutive rounds of proposals is obtained, it means that the earliest proposal generated in these three rounds of proposals has reached the finalized state, that is, a sufficient number of trusted nodes have completed the verification process. The consensus of this earliest generated round of proposals, so this earliest generated round of proposals can be submitted.
  • a node When a node submits this proposal, it marks that the consensus on this proposal has been completed. At this time, the execution module (also called a state machine) can be asynchronously notified to execute this proposal. Moreover, after the node submits the proposal, it does not wait for the execution result of the proposal and directly continues the next round of consensus process. In this way, consensus can be decoupled from execution.
  • the execution module also called a state machine
  • Step 205 For each node in the plurality of nodes, every time this node submits k proposals, the inspection information of the k-th proposal is generated based on the execution result of the k-th proposal among the k proposals, and the k-th proposal is The inspection information of each proposal is stored in the local inspection information set.
  • k is a positive integer, and k can be set in advance, such as k can be 1, 5, 10, etc. In this way, after each node submits a certain number of proposals, it can asynchronously wait for the execution result of the latest submitted proposal by the execution module, and then generate the inspection information of this proposal based on the execution result of this proposal.
  • the check information of this proposal is information used to check the execution consistency of this proposal.
  • the check information of this proposal can include the block number, block round, and execution result of this proposal. It can further include block execution height, the node's signature of the execution result of this proposal using its own private key, etc.
  • the block number can be the hash value of the block included in this proposal
  • the block round can be the consensus round in which this proposal is located
  • the block execution height can be the block chain after adding the block included in this proposal.
  • the execution result of this proposal can include the root hash value of the world state after executing this proposal.
  • Each node has a local set of inspection information.
  • the node's local check information set stores the check information of the proposals generated by the node that have been submitted and have obtained execution results. Subsequently, the node can verify the execution of the proposals to which these check information belongs based on the check information in the node's local check information set. Whether the results are consistent will be specifically described in step 206 below.
  • Step 206 For each node in the plurality of nodes, the node obtains aggregated inspection information, and compares the inspection information in the local inspection information set with the aggregated inspection information to determine stable inspection information from the local inspection information set.
  • the aggregate check information includes check information with consistent execution results generated by at least some nodes among the plurality of nodes for the same proposal. That is, the proposal to which the aggregate check information belongs has achieved execution consistency to a certain extent.
  • the aggregate check information of a proposal includes the check information generated by each node of at least some nodes in the plurality of nodes whose number is greater than or equal to the first quantity threshold for this proposal, that is, the aggregate check information of a proposal It includes multiple inspection information whose quantity is greater than or equal to the first quantity threshold, and the multiple inspection information is generated by multiple different nodes, and each inspection information in the multiple inspection information includes the same execution result.
  • the first quantity threshold can be set in advance.
  • the first quantity threshold can be 2f+1.
  • the aggregate check information of a proposal is obtained, it means that at least 2f+1 nodes in the blockchain system have generated check information with consistent execution results for this proposal. That is, at least 2f+1 nodes in the blockchain system will obtain the same execution result after executing this proposal, thus ensuring that f malicious nodes in the blockchain system cannot affect the execution process of normal nodes.
  • the check information in a node's local check information set is the check information of proposals that the node has submitted and has obtained execution results.
  • the proposal to which this aggregation check information belongs is a proposal that has achieved execution consistency on a certain number of nodes. Therefore, the check information in the local check information set of the node can be compared with the aggregate check information to determine whether there is a proposal to which a certain check information belongs in the node's local check information set that has execution consistency, that is, to determine whether the proposal to which the check information belongs has reached execution consistency. Whether there is stable check information in the local check information set of the node, and the execution results of the proposals to which the stable check information belongs are consistent, that is, the stable check information is credible check information.
  • the blockchain is a chain block structure
  • the node determines the stability check information, it can not only confirm that the execution results of the proposal to which the stability check information belongs are consistent, but also can also determine that the round is lower than the proposal The execution results of other proposals in this round are also consistent. Since the node generates the check information of the k-th proposal every time k proposals are submitted and stores it in the local check information set, the node actually selects the execution result of one proposal for every k proposals for verification, and implements this The purpose of indirectly verifying the execution results of other k-1 proposals is to achieve phased consistency checks, which can improve the efficiency of execution result verification and reduce the processing pressure of nodes while ensuring the accuracy of execution result verification.
  • the node when the aggregate voting information of the proposal satisfies the submission rules, the node can submit the proposal and execute the proposal. That is, when the aggregate voting information of the proposal satisfies the submission rules, the node can mark the consensus of the proposal as completed without waiting for the execution result of the proposal. After each node submits a certain number of proposals, it can generate the inspection information of this proposal based on the execution result of the latest submitted proposal and store it in the local inspection information set. After that, the inspection information in the local inspection information set is compared with the aggregate inspection information. To verify whether the execution results of proposals to which the inspection information in the local inspection information set belongs are consistent, to determine stable inspection information from the local inspection information set. In this case, the inspection mechanism is solely responsible for the verification and consistency guarantee of the execution results, ensuring the safety of the proposal execution.
  • the consensus process is completely decoupled from the execution process.
  • the consensus time is predictable and is only related to the consensus message body and node size. Therefore, an appropriate timeout threshold can be used to ensure consensus activity.
  • the proposal since the proposal will not be executed until it is submitted, it is ensured that the consensus of the proposal to be executed has been completed. At this time, the execution work will not be abandoned due to switching of consensus views and other reasons, so that processing resources will not be wasted.
  • the operation of obtaining the aggregation check information by each node among the plurality of nodes can be implemented in a variety of ways. Three possible ways are described below.
  • the first possible way for each node in the plurality of nodes, every time this node generates a piece of inspection information, it sends the latest generated inspection information to other nodes. Moreover, when this node obtains multiple check information belonging to the same proposal, the quantity is greater than or equal to the first quantity threshold, and the execution results are the same, it generates aggregate check information of this proposal based on the multiple check information.
  • all nodes cross-broadcast the inspection information of the proposals generated by themselves. After each node collects a certain number of inspection information belonging to a certain proposal with consistent execution results, it can aggregate the inspection information into this Aggregated inspection information for a proposal.
  • all the check information included in the aggregate check information carries the same block number, block round, block execution height and execution result, and carries different node signatures. That is, the proposal information in all the inspection information included in the aggregated inspection information is the same, but the signature information is different.
  • a node can generate this proposal based on multiple check information sent by other nodes that belong to the same proposal and are greater than or equal to the first quantity threshold and have the same execution results. aggregated check information.
  • the node can compare the execution results in the check information belonging to this proposal generated by itself with the check information belonging to this proposal sent by other nodes. If the execution results in are the same, and the sum of the number of check information belonging to this proposal generated by itself and the number of check information belonging to this proposal sent by other nodes is greater than or equal to the first quantity threshold, according to the The inspection information belonging to this proposal and the inspection information belonging to this proposal sent by other nodes generate the aggregate inspection information of this proposal.
  • FIG. 3 the generation process of aggregated inspection information is shown in FIG. 3 .
  • node A, node B, node C and node D broadcast the inspection information 1 belonging to proposal 1 for the first time, node A obtained four inspection information 1 and generated aggregate inspection information 1 based on these four inspection information 1; node B obtained When three check information 1 are received, aggregate check information 1 is generated based on these three check information 1; node C obtains three check information 1, and aggregate check information 1 is generated based on these three check information 1; node D obtains two checks Information 1. Node D did not generate aggregation check information due to insufficient quantity.
  • node A, node B, node C and node D broadcast the inspection information 2 belonging to proposal 2 for the second time, node A obtained four inspection information 2 and generated aggregate inspection information 2 based on these four inspection information 2; node A B obtained an inspection information 2. Due to insufficient quantity, node B did not generate aggregate inspection information; node C obtained four inspection information 2 and generated aggregate inspection information 2 based on these four inspection information 2; node D obtained an inspection information 2. Node D did not generate aggregation check information due to insufficient quantity. Afterwards, node A, node B, node C and node D broadcast the inspection information 3 belonging to proposal 3 for the third time. Node A obtained an inspection information 3.
  • node A did not generate aggregate inspection information; node B obtained When a check information 3 is received, node B does not generate aggregate check information due to insufficient quantity; node C obtains two check information 3, and node C does not generate aggregate check information due to insufficient quantity; node D obtains four check information 3, Aggregated inspection information 3 is generated based on these four inspection information 3. Afterwards, node A, node B, node C and node D broadcast the inspection information 4 belonging to proposal 4 for the fourth time. Node A obtained two inspection information 4. Due to insufficient quantity, node A did not generate aggregate inspection information; node B Two pieces of check information 4 were obtained. Due to insufficient quantity, node B did not generate aggregate check information. Node C obtained two pieces of check information 4. Due to insufficient quantity, node C did not generate aggregate check information. Node D obtained two pieces of check information. 4. Node D did not generate aggregation check information due to insufficient quantity.
  • a timeout mechanism can be added to the aggregation process of inspection information. That is, if a node does not generate aggregated inspection information within a certain period of time, it can try to re-broadcast the latest generation to other nodes. inspection information.
  • the i+1-th round slave node After determining that the proposal message carrying the i-th round proposal is legal, the i+1-th round slave node will send the vote for the i-th round proposal and the latest generated check information in one message. Give the i+1th round master node. After obtaining multiple check information belonging to the same proposal, the number of which is greater than or equal to the first quantity threshold, and the execution results are the same, the master node of the i+1th round generates the aggregate check information of this proposal based on the multiple check information. The aggregation check information, the i+1 round proposal and the aggregate voting information of the i round proposal are all carried in the proposal message and sent to the i+1 round slave node. The i+1-th round slave node receives a proposal message carrying the aggregation check information, the i+1-th round proposal, and the aggregate voting information of the i-th round proposal.
  • the slave node unicasts the inspection information to the master node in the same round.
  • the master node is responsible for aggregating the inspection information, and then broadcasts the aggregated inspection information to the slave nodes in the same round. That is, the slave node can send the latest generated check information along with each round of voting to the master node in the same round.
  • the master node broadcasts the proposal message to the slave nodes in the same round, it includes the latest generated aggregation check information. In this way, the processing pressure on the slave node can be reduced.
  • the master node in the i+1th round may receive multiple check information sent by the slave node in the i+1th round that belong to the same proposal, the number is greater than or equal to the first quantity threshold, and the execution results are the same. , based on the multiple inspection information, the aggregate inspection information of this proposal is generated.
  • the master node in the i+1th round can generate the check information belonging to this proposal with the same execution result.
  • the execution results in the check information belonging to this proposal sent by the slave node in the i+1th round are the same, and the number of check information belonging to this proposal generated by itself is the same as the check information belonging to this proposal sent by the slave node in the i+1th round.
  • the proposal is generated based on the check information belonging to this proposal generated by itself and the check information belonging to this proposal sent from the node in the i+1th round. Aggregate inspection information.
  • Figure 4 shows the generation process of aggregated inspection information.
  • node A, node B, node C and node D all generated check information locally.
  • node B, node C and node D are the second round of consensus process.
  • node A is the master node in the second round of consensus process. Therefore, slave node B, slave node C and slave node D send votes with check information to master node A.
  • master node A obtains When the four inspection information are reached, aggregate inspection information can be generated based on these four inspection information.
  • master node A broadcasts the aggregation check information attached to the proposal message to slave node C and slave node D.
  • slave node C and slave node D Aggregation check information was obtained.
  • node A, node C and node D are slave nodes in the third round of consensus process, and node B is the master node in the third round of consensus process. Therefore, slave node A, slave node C and slave node D send votes with inspection information to master node B. At this time, master node B obtains four inspection information. Based on these four inspection information, aggregate inspection information can be generated.
  • master node B broadcasts the aggregation check information attached to the proposal message to slave node A, slave node C, and slave node D.
  • the aggregation check information, the i+j round proposal and the aggregate voting information of the i+j-1 round proposal are all carried in the proposal message and sent to the i+j round slave node.
  • the i+j-th round slave node receives a proposal message carrying the aggregation check information, the i+j-th round proposal, and the i+j-1 round proposal's aggregate voting information.
  • j is a positive integer, and j can be preset, such as j can be 1, 2, 3, etc.
  • j 1
  • the slave node sends the check information to the master node of the same round; when j is greater than or equal to 2, the slave node sends the check information to the master nodes of the next rounds.
  • the slave node after the slave node generates the check information, it can directly send the check information to the master node of the same round or the next few rounds of master nodes without waiting for the proposal voting time. At this time, the voting and check information can be sent. are parallel, thus increasing flexibility. Moreover, when the slave node sends the check information to the master nodes in the next rounds, the processing pressure of the master node in the same round can be reduced.
  • the master node of the i+jth round can, after receiving multiple check information sent by other nodes belonging to the same proposal, with a quantity greater than or equal to the first quantity threshold, and with the same execution result, based on these multiple checks.
  • CheckInfo generates aggregated checkin information for this proposal.
  • the master node in the i+jth round can generate the check information belonging to this proposal and the execution result in it is the same as the execution result sent by other nodes.
  • the execution results in the inspection information of this proposal are the same, and the sum of the number of inspection information belonging to this proposal generated by itself and the number of inspection information belonging to this proposal sent by other nodes is greater than or equal to the first quantity threshold
  • the aggregated check information of this proposal is generated based on the check information generated by itself and belonging to this proposal and the check information sent by other nodes belonging to this proposal.
  • Figure 5 shows the generation process of aggregated inspection information.
  • node B, node C and node D are the slave nodes in the second round of consensus process
  • node A is the master node in the second round of consensus process.
  • the votes sent from node B, slave node C and slave node D to master node A do not carry check information.
  • master node A broadcasts the proposal message to slave node B, slave node C and slave node D.
  • slave node B, slave node C and slave node D has generated check information locally.
  • slave node B is the master node in the third round of consensus process
  • slave node C and slave node D send check information to slave node B.
  • slave node B has obtained three checks. Information, based on these three inspection information, aggregate inspection information can be generated.
  • the votes sent from slave node A, slave node C, and slave node D to master node B in the third round of consensus process do not come with check information.
  • master node B broadcasts the aggregation check information attached to the proposal message to slave node A, slave node C and slave node D.
  • slave node A, slave node The aggregation check information is obtained from node C and slave node D.
  • the proposals to which the stability check information belongs are proposals whose execution results have been verified to be consistent. That is, after comparing the aggregated check information with all the check information in the local check information set, it can be determined which check information in the local check information set belongs to proposals that have achieved consistency in execution results. At this time, the proposal can be The inspection information of the proposal is determined to be stable inspection information.
  • the node's operation of comparing the inspection information in the local inspection information set with the aggregate inspection information can include the following four situations:
  • the first case If there is target check information in the local check information set that belongs to the same proposal as the aggregate check information, and the execution result in the target check information is the same as the execution result in the aggregate check information, then the target check information is set to Latest stability check information.
  • the target check information in the local check information set and the aggregate check information belong to the same proposal, and the execution results are the same, it means that the execution result of the current node for the proposal to which the target check information belongs is the same as the execution result of a certain number of other nodes for this proposal. If they are the same, it can be determined that the execution results of the proposal are consistent, and thus the target check information can be determined to be stable check information.
  • the node Since the execution results of the proposal to which the stability check information belongs are consistent, the execution results of other proposals with rounds lower than the proposal are also consistent. Therefore, optionally, the node is setting a new stable After checking the information, you can persist the latest stability check information, and then clean up the cache of relevant proposals whose rounds are lower than the round to which the stability check information belongs. For example, you can clean up the consensus cache (including but not limited to block tree, aggregate voting information etc.), and the node can also clear the inspection information of proposals whose rounds in the local inspection information set are lower than the rounds of the proposals to which the stable inspection information belongs.
  • the consensus cache including but not limited to block tree, aggregate voting information etc.
  • the second case If the round of the proposal to which the latest stable check information in the local check information set belongs is higher than the round of the proposal to which the aggregate check information belongs, the processing of the aggregate check information will be ignored and the operation will end.
  • the third case If there is no inspection information belonging to the same proposal as the aggregated inspection information in the local inspection information set, the block synchronization operation will be performed.
  • the process of a node performing a block synchronization operation is similar to the process of a node performing a block synchronization operation in related technologies, and this will not be elaborated in the embodiments of this application.
  • a node performs a block synchronization operation, it obtains proposal-related information from other nodes in an attempt to synchronize to the execution results of the proposal to which the aggregate check information belongs, and then attempts to synchronize to the check information of the proposal to which the aggregate check information belongs.
  • the fourth situation If there is target check information in the local check information set that belongs to the same proposal as the aggregate check information, but the execution result in the target check information is different from the execution result in the aggregate check information, the block rollback operation is performed. .
  • the process of a node performing a block rollback operation is similar to the process of a node performing a block rollback operation in related technologies, and this will not be elaborated in the embodiments of this application.
  • the target check information in the local check information set and the aggregate check information belong to the same proposal, but the execution results are different, it means that the execution result of the current node for the proposal to which the target check information belongs is different from the execution results of a certain number of other nodes for this proposal. If it is different, it can be determined that the execution of the proposal by the current node is likely to cause an error, thus triggering a block rollback. When a node performs a block rollback operation, it will re-execute the proposal in an attempt to synchronize to the execution results in the aggregate check information.
  • the node can not only generate check information every time k proposals are submitted, but also when the consensus cluster changes, when submitting the corresponding proposal containing the configuration block (config block) , directly generate check information as configuration check information.
  • the configuration block is a special consensus block used to change the consensus configuration and trigger changes to the consensus cluster.
  • the configuration check information can include information related to changes in the consensus configuration, such as the list of consensus cluster members that can include new changes.
  • the master node can construct a configuration block when processing a consensus cluster change transaction, generate a first proposal containing the configuration block, and then proceed to the proposal consensus process through the above steps 201 to 204.
  • any node can generate the check information of the first proposal as the configuration check information based on the execution result of the first proposal when the submitted proposal is the first proposal that contains the configuration block, and transfer the configuration check information to Store it in the local check information set, and then implement the verification of the execution results in the configuration check information in the local check information set through step 206.
  • the node before the configuration check information in the local check information set reaches stability, that is, when the configuration check information in the local check information set has not become stable check information, the node is only allowed to submit proposals with empty content, and does not submit them. Substantial proposals, that is, no proposals other than proposals with empty content will be submitted.
  • the proposal consensus will continue with the configuration block as the initial block, that is, the consensus of a new generation (epoch) will begin. .
  • a proposal containing a proof block can be added to the consensus process.
  • the checking information is directly generated as mandatory checking information.
  • the verification block is a special consensus block that does not contain transactions, and verification blocks cannot be created repeatedly under certain conditions. For example, verification blocks cannot be created repeatedly within the 3-chain, that is, after creating a verification block No verification blocks can be created in the subsequent three consecutive rounds of consensus. That is to say, after generating a proposal containing a verification block, the three consecutive rounds of proposals generated can no longer contain verification blocks.
  • the master node when the master node finds that stable check information has not been formed for a long time, that is, when the master node checks the local check information set and does not form stable check information within a preset time period, it constructs a verification block and generates the third verification block containing the verification block. Two proposals are made, and then the proposal consensus process is carried out through the above steps 201 to 204. In this case, any node can generate the check information of the second proposal as mandatory check information based on the execution result of the second proposal when the submitted proposal is a second proposal that contains a verification block, and the mandatory check information will be It is stored in the local check information set, and then through step 206, the execution results in the mandatory check information in the local check information set are verified.
  • the mandatory check information is forcibly generated by verifying the block and stored in the local check information set. Since the verification block generally does not contain transactions, the execution difficulty is low and it is easy to achieve consistency. Therefore, the mandatory check information in the local check information set can be stabilized in a short time, thereby maintaining the activity of the check mechanism.
  • the consensus process and the execution process can be completely decoupled. Since the execution module needs to be consistent in theory, inconsistent execution results should not affect the consensus result. Therefore, in the embodiment of this application, the consensus protocol can mark the final consistency of the proposal after submitting the proposal without waiting for the proposal.
  • the verification mechanism is solely responsible for the verification and consistency guarantee of the execution results. In this way, on the one hand, it does not affect the consensus activity. Since there is no need to intersperse execution processes during the consensus process, the consensus time is predictable and is only related to the consensus message body and node size. Therefore, an appropriate timeout threshold can be used to ensure consensus activity. On the other hand, resource utilization is high. Since the proposal will be executed after the consensus submission is completed, that is, the consensus protocol has ensured that the block to be executed has been agreed upon, so the execution work will not be abandoned due to consensus view switching and other reasons, and there will be no waste of execution resources.
  • FIG. 6 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • the computer device 6 includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and executable on the processor 60.
  • the processor 60 executes the computer program 62, the above embodiments are implemented. Steps in the proposal consensus execution method.
  • the computer device 6 may be a general computer device or a special purpose computer device.
  • the computer device 6 may be a server cluster including multiple servers, such as a blockchain system including multiple nodes.
  • FIG. 6 is only an example of the computer device 6 and does not constitute a limitation on the computer device 6. It may include more or less components than shown in the figure, or some components may be combined, or different components may be used. , for example, it can also include input and output devices, network access devices, etc.
  • the processor 60 can be a central processing unit (Central Processing Unit, CPU).
  • the processor 60 can also be other general-purpose processors, digital signal processors (Digital Signal Processor, DSP), or application specific integrated circuits (Application Specific Integrated Circuit, ASIC). , off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • a general purpose processor may be a microprocessor or any conventional processor.
  • the memory 61 may be an internal storage unit of the computer device 6 in some embodiments, such as a hard disk or memory of the computer device 6 . In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), or a secure digital (SD) equipped on the computer device 6. card, flash card, etc. Further, the memory 61 may also include both an internal storage unit of the computer device 6 and an external storage device. The memory 61 is used to store operating systems, application programs, boot loaders, data and other programs. The memory 61 may also be used to temporarily store data that has been output or is to be output.
  • an external storage device of the computer device 6 such as a plug-in hard disk, a smart memory card (Smart Media Card, SMC), or a secure digital (SD) equipped on the computer device 6. card, flash card, etc.
  • SD secure digital
  • the memory 61 may also include both an internal storage unit of the computer device 6 and an external storage device
  • Embodiments of the present application also provide a computer device.
  • the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor.
  • the processor executes the computer program.
  • Embodiments of the present application also provide a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program.
  • the steps in the above method embodiments can be implemented.
  • the embodiment of the present application provides a computer program product, which, when run on a computer, causes the computer to perform the steps in each of the above method embodiments.
  • Integrated units may be stored in a computer-readable storage medium if they are implemented in the form of software functional units and sold or used as independent products. Based on this understanding, this application can implement all or part of the processes in the above method embodiments by instructing relevant hardware through a computer program.
  • the computer program can be stored in a computer-readable storage medium, and the computer program can be used when being processed. When the processor executes, the steps of each of the above method embodiments can be implemented.
  • the computer program includes computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc.
  • the computer-readable medium may at least include: any entity or device capable of carrying computer program code to the camera device/terminal device, recording media, computer memory, ROM (Read-Only Memory), RAM (Random Access Memory) , Random Access Memory), CD-ROM (Compact Disc Read-Only Memory, read-only disk), tapes, floppy disks and optical data storage devices, etc.
  • the computer-readable storage media mentioned in this application may be non-volatile storage media, in other words, may be non-transitory storage media.
  • the disclosed apparatus/computer equipment and methods can be implemented in other ways.
  • the apparatus/computer equipment embodiments described above are only illustrative.
  • the division of modules or units is only a logical function division.
  • there may be other division methods, such as multiple units or components. can be combined or can be integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the device or unit may be electrical, mechanical or other forms.
  • a unit described as a separate component may or may not be physically separate.
  • a component shown as a unit may or may not be a physical unit, that is, it may be located in one place, or it may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种提案共识执行方法、区块链系统、设备和存储介质，属于区块链技术领域。该方法包括：若一个提案的聚合投票信息满足提交规则，则提交该提案，且执行该提案；每提交k个提案，根据该k个提案中的第k个提案的执行结果生成该第k个提案的检查信息，将该第k个提案的检查信息存储至本地检查信息集；获取聚合检查信息，聚合检查信息包括多个节点针对同一提案生成的执行结果一致的检查信息；将本地检查信息集与聚合检查信息进行比较，以确定稳定检查信息，稳定检查信息所属的提案的执行结果具有一致性。本申请将共识过程与执行过程完全解耦，通过检查机制单独负责执行结果的验证与一致性保证，从而可确保共识活性，避免处理资源的浪费。

Description

提案共识执行方法、区块链系统、设备和存储介质
本申请要求于2022年03月30日在中国专利局提交的、申请号为202210323741.8、申请名称为“提案共识执行方法、区块链系统、设备和存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及区块链技术领域，特别涉及一种提案共识执行方法、区块链系统、设备和存储介质。
背景技术
在区块链系统中，共识协议负责对从客户端接收到的交易进行一致性排序，得到排序后的交易序列，状态机只需负责对排序后的交易序列进行执行。从表面来看，共识协议在确定交易序列的一致性后，其共识任务就已经完成了，相同的状态机执行相同的交易序列将会给出相同的执行结果。然而，状态机并非是保证安全的，在软件层面和硬件层面上的问题都有可能导致不同节点运行相同的状态机执行相同的交易序列却得出不同的执行结果。为此，共识协议对执行结果的一致性的验证也是必要的。
技术问题
本申请提供了一种提案共识执行方法、区块链系统、设备和存储介质，可以将共识过程与执行过程完全解耦，通过检查机制单独负责执行结果的验证与一致性保证，从而可以确保共识活性，且避免处理资源的浪费。
技术解决方案
第一方面，提供了一种提案共识执行方法，应用于区块链系统，所述区块链系统包括多个节点，所述方法包括：
所述多个节点中的每个节点执行以下操作：
获取在共识过程中生成的一个提案的聚合投票信息，若所述一个提案的聚合投票信息满足提交规则，则提交所述一个提案，且执行所述一个提案，所述提交所述一个提案是指标记所述一个提案的共识已完成；
每提交k个提案，根据所述k个提案中的第k个提案的执行结果生成所述第k个提案的检查信息，将所述第k个提案的检查信息存储至本地检查信息集，所述k为正整数；
获取聚合检查信息，所述聚合检查信息包括所述多个节点中的至少部分节点针对同一提案生成的执行结果一致的检查信息；将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，以从所述本地检查信息集中确定稳定检查信息，所述稳定检查信息所属的提案的执行结果具有一致性。
可选地，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述方法还包括：
第i轮主节点生成所述第i轮提案，向所述第i轮从节点发送携带有所述第i轮提案的提案消息，所述i为正整数；
第i+1轮从节点若确定所述提案消息具备合法性，则向所述第i+1轮主节点发送针对所述第i轮提案的投票；
所述第i+1轮主节点根据所述第i+1轮从节点针对所述第i轮提案的投票生成所述第i轮提案的聚合投票信息，生成第i+1轮提案，向所述第i+1轮从节点发送携带有所述第i+1轮提案和所述第i轮提案的聚合投票信息的提案消息。
可选地，所述获取聚合检查信息，包括：
每生成一个检查信息，向其他节点发送最新生成的所述一个检查信息；
在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息的情况下，根据所述多个检查信息生成所述聚合检查信息。
可选地，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述获取聚合检查信息，包括：
第i+1轮从节点在确定携带有第i轮提案的提案消息具备合法性后，将针对所述第i轮提案的投票和最新生成的检查信息携带于一个消息中发送给所述第i+1轮主节点；
所述第i+1轮主节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息后，根据所述多个检查信息生成所述聚合检查信息，将所述聚合检查信息、所述第i+1轮提案和所述第i轮提案的聚合投票信息均携带于提案消息中发送给所述第i+1轮从节点。
可选地，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述获取聚合检查信息，包括：
第i+1轮从节点每生成一个检查信息，将最新生成的所述一个检查信息发送给第i+j轮主节点，所述j为正整数；
所述第i+j轮主节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息后，根据所述多个检查信息生成所述聚合检查信息，将所述聚合检查信息、所述第i+j轮提案和所述第i+j-1轮提案的聚合投票信息均携带于提案消息中发送给所述第i+j轮从节点。
可选地，所述第一数量阈值为2f+1，所述f为所述多个节点中恶意节点的数量。
可选地，所述将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，包括：
若所述本地检查信息集中存在与所述聚合检查信息属于同一提案的目标检查信息，且所述目标检查信息中的执行结果与所述聚合检查信息中的执行结果相同，则将所述目标检查信息设置为最新的所述稳定检查信息。
可选地，所述将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，包括：
若所述本地检查信息集中最新的所述稳定检查信息所属的提案的轮次高于所述聚合检查信息所属的提案的轮次，则结束操作；
若所述本地检查信息集中不存在与所述聚合检查信息属于同一提案的检查信息，则执行区块同步操作；
若所述本地检查信息集中存在与所述聚合检查信息属于同一提案的目标检查信息，且所述目标检查信息中的执行结果与所述聚合检查信息中的执行结果不同，则执行区块回滚操作。
可选地，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述方法还包括：
所述多个节点中的每个节点执行以下操作：
在提交的提案为包含有配置区块的第一提案的情况下，根据所述第一提案的执行结果生成所述第一提案的检查信息作为配置检查信息，将所述配置检查信息存储至所述本地检 查信息集，所述配置区块是所述主节点在处理共识集群变更交易时构建的；
在所述本地检查信息集中的所述配置检查信息未成为所述稳定检查信息的情况下，不提交除内容为空的提案之外的其他提案；在所述本地检查信息集中的所述配置检查信息成为所述稳定检查信息后，以所述配置区块为初始区块继续进行提案共识。
可选地，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述方法还包括：
所述多个节点中的每个节点执行以下操作：
在提交的提案为包含有验证区块的第二提案的情况下，根据所述第二提案的执行结果生成所述第二提案的检查信息作为强制检查信息，将所述强制检查信息存储至所述本地检查信息集，所述验证区块是所述主节点在所述本地检查信息集在预设时长内未形成所述稳定检查信息时构建的。
第二方面，提供了一种区块链系统，所述区块链系统包括多个节点，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述区块链系统用于执行上述的提案共识执行方法。
第三方面，提供了一种计算机设备，所述计算机设备包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述的提案共识执行方法。
第四方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述的提案共识执行方法。
第五方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述的提案共识执行方法的步骤。
有益效果
在本申请中，节点在提案的聚合投票信息满足提交规则时，即可提交这个提案，且执行这个提案。也即，节点在该提案的聚合投票信息满足提交规则时，即可标记该提案的共识已完成，而无需等待该提案的执行结果。节点每提交一定数量的提案后，可根据最新提交的这个提案的执行结果生成这个提案的检查信息并存储至本地检查信息集，之后，将本地检查信息集中的检查信息与聚合检查信息进行比较，来验证本地检查信息集中的检查信息所属的提案的执行结果是否具有一致性，以从本地检查信息集中确定稳定检查信息。这种情况下，通过检查机制单独负责执行结果的验证与一致性保证，保证了提案执行安全性。如此，将共识过程与执行过程完全解耦。由于不需要在共识过程中穿插执行流程，所以共识时间是可预知的，从而可使用一个恰当的超时阈值来确保共识活性。并且，由于提案提交后才会执行，所以确保了待执行的提案已经共识完毕，此时执行工作不会因共识视图的切换等原因而被抛弃，从而不会浪费处理资源。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种区块链系统的结构示意图；
图2是本申请实施例提供的一种提案共识执行方法的流程图；
图3是本申请实施例提供的一种聚合检查信息的生成过程的示意图；
图4是本申请实施例提供的另一种聚合检查信息的生成过程的示意图；
图5是本申请实施例提供的又一种聚合检查信息的生成过程的示意图；
图6是本申请实施例提供的一种计算机设备的结构示意图。
本发明的实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
应当理解的是，本申请提及的“多个”是指两个或两个以上。在本申请的描述中，除非另有说明，“/”表示或的意思，比如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，比如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，为了便于清楚描述本申请的技术方案，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。
在本申请中描述的“一个实施例”或“一些实施例”等语句意味着在本申请的一个或多个实施例中包括该实施例描述的特定特征、结构或特点。由此，在本申请中的不同之处出现的“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等语句不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。此外，术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
在对本申请实施例进行详细地解释说明之前，先对本申请实施例的应用场景予以说明。
区块链系统包括多个节点，该多个节点中的每个节点都有用于存储交易的交易池。该多个节点中的任意一个节点在从客户端接收到交易后，会将该交易共享给其他节点，以便该多个节点都在交易池中存储该交易，如此该多个节点的交易池中存储的交易一致，可对交易池中的交易进行处理。对于交易池中任意一个待处理的交易来说，该交易在得到该多个节点的共识之后，可被执行，以被存储至区块链。
在区块链系统中，共识协议负责对交易进行一致性排序，得到排序后的交易序列，状态机只需负责对排序后的交易序列进行执行。从表面来看，共识协议在确定交易序列的一致性后，其共识任务就已经完成了，相同的状态机执行相同的交易序列将会给出相同的执行结果。然而，状态机并非是保证安全的，在软件层面和硬件层面上的问题都有可能导致不同节点运行相同的状态机执行相同的交易序列却得出不同的执行结果。为此，共识协议对执行结果的一致性的验证也是必要的。
一般地，采用HotStuff共识算法、PBFT(Practical Byzantine Fault Tolerance，实用拜占庭容错)共识算法、Raft共识算法等基于主节点(Leader)的共识算法来对交易进行共识，在共识之后，执行交易，以将交易存储至区块链。基于主节点的共识算法中需要一个主节点来主导共识过程，主节点是从区块链系统中的多个节点中选举出来的节点，用于广播根据交易生成的提案。在每一轮共识过程中，均会从该多个节点中选举出一个节点作为主节点，将其他节点作为从节点，通过每一轮的主节点和从节点来实现提案共识。
下面以PBFT算法为例，来对相关技术中的提案共识执行过程进行说明，该过程包括 如下步骤(1)-步骤(5)：
(1)主节点在根据待处理的交易生成提案后，不执行该提案，直接向从节点广播该提案。
(2)主节点广播该提案后进入pre-prepared(预准备)阶段，同时从节点在接收到主节点发送的该提案后也进入pre-prepared阶段，此时主节点和从节点均执行该提案(此过程可称为预执行)，执行变更状态(即预执行结果)暂存在缓存中而不写入区块链中，该提案执行完成后，广播携带有执行结果的prepare(准备)消息。
(3)任意一个节点接收到其他节点发送的prepare消息后，比较prepare消息中携带的执行结果，当获取到2f+1个执行结果一致的prepare消息后，进入prepared阶段，广播携带执行结果的commit(确认)消息，其中，f为可容忍的拜占庭节点数。
(4)任意一个节点接收到其他节点发送的commit消息后，比较commit消息中携带的执行结果，当获取到2f+1个执行结果一致的commit消息后，共识协议提交该提案，并将暂存的执行变更状态写入区块链中。
(5)任意一个节点若在限制时间(即超时阈值)内没有获取到足够数量的执行结果一致的commit消息，则触发超时，并进入主节点切换流程。在主节点切换之后，切换后的主节点会发起新的提案，相应的从节点在接收到新的提案后，会放弃暂存的执行变更状态，转而执行新的提案。
上述方案虽然使得共识协议对执行结果的一致性进行了验证，但是存在以下三个问题：
第一、共识与执行高度耦合。提案的执行过程包含在共识过程中，共识需要同步等待执行结果，从而导致处理资源利用率和共识效率均较低。
第二、无法保证共识活性。由于提案的执行时间是不可预知的，所以共识协议很难确定一个合适的超时阈值，若提案的执行时间过长会导致共识超时频繁，甚至失去活性。
第三、浪费处理资源。由于共识可能在预执行完成后超时，而超时触发主节点切换后会放弃先前的预执行结果，这会导致先前的预执行工作失去意义，严重浪费了处理资源。
为此，本申请实施例提供了一种提案共识执行方法，将共识过程与执行过程完全解耦，通过检查机制单独负责执行结果的验证与一致性保证，从而可以确保共识活性，且避免处理资源的浪费。
下面对本申请实施例涉及的区块链系统的相关内容予以说明。
图1是本申请实施例提供的一种区块链系统的结构示意图。
参见图1，区块链系统100是指用于进行节点与节点之间数据共享的系统，区块链系统100中可以包括多个节点101。每个节点101在进行正常工作时可以接收到输入信息，并基于接收到的输入信息维护区块链系统100内的共享数据。为了保证区块链系统100内的信息互通，区块链系统100中的每个节点101之间可以存在信息连接，节点101之间可以通过该信息连接进行信息传输。比如，当区块链系统100中的任意节点101接收到输入信息时，区块链系统100中的其他节点101便根据共识算法获取该输入信息，将该输入信息作为共享数据中的数据进行存储，使得区块链系统100中全部节点101上存储的数据一致。也即，区块链系统100中的每个节点101均存储一条相同的区块链。
区块链系统100具有分布式数据存储、点对点传输、共识机制、加密算法等计算机技术。区块链系统100是一个分布式的共享账本和数据库，具有去中心化、不可篡改、全程 留痕、可以追溯、集体维护、公开透明等特点。这些特点保证了区块链的共享开放、真实完整和安全可靠。
区块链系统100中的多个节点101在每一轮共识过程中存在一个主节点和多个从节点，每一轮的主节点和多个从节点可以执行下文图2实施例所述的提案共识执行方法，来实现对每一轮提案的共识和执行。
下面对本申请实施例提供的提案共识执行方法进行详细地解释说明。
图2是本申请实施例提供的一种提案共识执行方法的流程图。该方法应用于区块链系统，具体可以应用于区块链系统中的共识协议。区块链系统包括多个节点，该多个节点在每一轮共识过程中存在一个主节点和多个从节点。
参见图2，该方法包括以下步骤。
步骤201：第i轮主节点生成第i轮提案，向第i轮从节点发送携带有第i轮提案的提案消息，i为正整数。
主节点是从区块链系统中的多个节点中选举出来的节点，用于广播提案。在每一轮共识过程中都会选举一个节点作为主节点，将其他节点作为从节点，通过每一轮的主节点和多个从节点实现这一轮提案的共识。
从区块链系统中的多个节点中选举主节点的操作可以参考相关技术，本申请实施例对此不进行详细阐述。比如，可以给区块链系统中的多个节点中的每个节点进行编号，然后按照该多个节点的编号顺序，依次由各个节点轮流当选主节点，当然，也可以通过其他方式选举主节点，本申请实施例对此不作限定。
需注意的是，区块链系统中的多个节点中有可能会存在恶意节点，恶意节点是指对区块链系统的安全造成恶意攻击的节点，也即，恶意节点会阻碍对提案的共识。可选地，该多个节点的数量为n个，该多个节点中的恶意节点的数量为f个，f小于n/3，其中“/”表示“除以”的意思，示例地，n可以为大于或等于4的整数，f可以为正整数。
第i轮主节点生成的第i轮提案是根据第i轮待处理的交易生成的。示例地，第i轮主节点可以根据第i轮待处理的交易，在本地最新生成的区块的基础上构建一个新的区块作为第i轮提案，然后将第i轮提案携带于提案消息中广播给其他从节点，以便其他从节点对第i轮提案进行共识。
可选地，第i轮主节点还可以使用自身的私钥对第i轮提案进行签名，将该签名也携带于提案消息中。
可选地，在i为1的情况下，即在第一轮提案的共识过程中，第i轮主节点广播的提案消息中可以携带第i轮提案。
在i大于或等于2的情况下，即在第二轮提案以及后续提案的共识过程中，第i轮主节点广播的提案消息中不仅可以携带第i轮提案，还可以携带上一轮(即第i-1轮)提案的聚合投票信息(也可称为QC(quorum certificate，法定人数证书))。第i-1轮提案的聚合投票信息包括区块链系统中的多个节点中的至少部分节点中每个节点针对第i-1轮提案的投票，每个节点针对第i-1轮提案的投票可以包括使用自身的私钥对第i-1轮提案的摘要信息(即哈希值)的签名，每个节点在确定第i-1轮提案具备合法性后可以对其进行投票。如此，第i-1轮提案的聚合投票信息为第i-1轮提案的合法性提供了多票的证据。
步骤202：第i+1轮从节点若确定携带有第i轮提案的提案消息具备合法性，则向第i+1 轮主节点发送针对第i轮提案的投票。
第i+1轮从节点中可能包括第i轮主节点和第i轮从节点。对于第i轮主节点，其在生成携带有第i轮提案的提案消息后，就可以验证该提案消息的合法性，且在确定该提案消息具备合法性的情况下，向第i+1轮主节点发送针对第i轮提案的投票。对于第i轮从节点，其在接收到第i轮主节点发送的携带有第i轮提案的提案消息后，可以验证该提案消息的合法性，且在确定该提案消息具备合法性的情况下，向第i+1轮主节点发送针对第i轮提案的投票。每个节点针对第i轮提案的投票可以包括使用自身的私钥对第i轮提案的摘要信息的签名。
验证携带有第i轮提案的提案消息的合法性的操作与相关技术中验证某个提案消息的合法性的操作类似，本申请实施例对此不进行详细阐述。例如，可以验证该提案消息中携带的主节点的签名，还可以验证该提案消息中携带的第i轮提案中包含的交易，如可以验证该交易是否存在重复打包问题、验证该交易的用户签名等，此外，还可以验证该提案消息中携带上一轮提案的聚合投票信息，如可以验证该聚合投票信息中包含的各个节点的签名。
值得说明的是，本申请实施例中，第i+1轮从节点在获取到携带有第i轮提案的提案消息后，仅对该提案消息的合法性做验证，而不对第i轮提案做执行处理，在合法性验证通过后，即将针对第i轮提案的投票发送给第i+1轮主节点。如此，避免了在共识过程中穿插执行流程。
步骤203：第i+1轮主节点根据第i+1轮从节点针对第i轮提案的投票生成第i轮提案的聚合投票信息，生成第i+1轮提案，向第i+1轮从节点发送携带有第i+1轮提案和第i轮提案的聚合投票信息的提案消息。
第i轮提案的聚合投票信息为第i轮提案的合法性提供了多票的证据。第i轮提案的聚合投票信息可以包括第i+1轮从节点中的一定数量的从节点针对第i轮提案的投票。
可选地，第i+1轮主节点可以在接收到的针对第i轮提案的多个投票的数量大于或等于第二数量阈值的情况下，根据该多个投票生成第i轮提案的聚合投票信息。此时第i轮提案的聚合投票信息可以包括该多个投票，即包括数量大于或等于第二数量阈值的多个节点中的每个节点针对第i轮提案的投票。
第二数量阈值可以预先进行设置。例如，第二数量阈值可以为2f+1，如此，若接收到的针对第i轮提案的多个投票的数量大于或等于2f+1，说明区块链系统中至少有2f+1个节点对第i轮提案进行了投票，则能够保证区块链系统中的f个恶意节点不能对正常节点的共识过程造成影响。
其中，第i+1轮主节点生成第i+1轮提案的操作与第i轮主节点生成第i轮提案的操作类似，本申请实施例对此不再赘述。
步骤204：对于该多个节点中的每一个节点，这个节点获取在共识过程中生成的一个提案的聚合投票信息，若这个提案的聚合投票信息满足提交规则，则提交这个提案，且执行这个提案。
该多个节点中的每个节点可以通过上述步骤201-步骤203来得到某个提案的聚合投票信息，具体来讲，可以在每一轮共识过程中获取到上一轮提案的聚合投票信息。比如，每一轮的主节点可以生成上一轮提案的聚合投票信息，每一轮的从节点可以接收主节点发送的提案消息中携带的上一轮提案的聚合投票信息。如此，各个节点都可以获取到提案的聚 合投票信息。
提交规则可以预先进行设置，比如，该提交规则可以是3-chain提交规则等。某个提案的聚合投票信息满足提交规则，表明已经有足够数量的节点对这个提案进行投票，即已完成对这个提案的共识，因而此时可以提交这个提案。
其中，chain是指链式共识过程。该3-chain提交规则是指：在获取到连续三轮提案中每轮提案的聚合投票信息的情况下，提交这三轮提案中最早生成的一轮提案。这种情况下，若获取到了连续三轮提案中每轮提案的聚合投票信息，说明这三轮提案中最早生成的一轮提案已达到最终确定状态，即已有足够数量的可信节点完成对此最早生成的一轮提案的共识，因而可以提交此最早生成的一轮提案。
节点提交这个提案即是标记这个提案的共识已完成，此时可以异步通知执行模块(也可称为状态机)执行这个提案。并且，节点提交这个提案后，不等待这个提案的执行结果，直接继续进行下一轮共识过程。如此，可将共识与执行解耦。
其中，节点执行这个提案的操作与相关技术中某个节点执行某个提案的操作类似，本申请实施例对此不进行详细阐述。
步骤205：对于该多个节点中的每一个节点，这个节点每提交k个提案，根据该k个提案中的第k个提案的执行结果生成该第k个提案的检查信息，将该第k个提案的检查信息存储至本地检查信息集。
k为正整数，且k可以预先进行设置，如k可以为1、5、10等。如此，节点在每提交一定数量的提案后，就可以异步等待执行模块对最新提交的这个提案的执行结果，然后根据这个提案的执行结果生成这个提案的检查信息。
这个提案的检查信息是用于检查这个提案的执行一致性的信息。示例地，这个提案的检查信息可以包括区块编号、区块轮次和这个提案的执行结果，进一步还可以包括区块执行高度、节点使用自身的私钥对这个提案的执行结果的签名等。其中，区块编号可以是这个提案包含的区块的哈希值，区块轮次可以是这个提案所在的共识轮次，区块执行高度可以是区块链在添加这个提案包含的区块后的高度，这个提案的执行结果可以包括执行这个提案后世界状态的根哈希值。
每个节点都具有本地检查信息集。节点的本地检查信息集中存储有该节点生成的其所提交且已获得执行结果的提案的检查信息，后续该节点可以根据该节点的本地检查信息集中的检查信息验证这些检查信息所属的提案的执行结果是否具有一致性，具体在如下步骤206进行说明。
步骤206：对于该多个节点中的每一个节点，这个节点获取聚合检查信息，将本地检查信息集中的检查信息与该聚合检查信息进行比较，以从本地检查信息集中确定稳定检查信息。
聚合检查信息包括该多个节点中的至少部分节点针对同一提案生成的执行结果一致的检查信息，也即，聚合检查信息所属的提案已在一定程度上取得了执行一致性。示例地，一个提案的聚合检查信息包括该多个节点中数量大于或等于第一数量阈值的至少部分节点中的每个节点针对这一提案生成的检查信息，也即，一个提案的聚合检查信息包括数量大于或等于第一数量阈值的多个检查信息，且该多个检查信息是多个不同的节点生成的，该多个检查信息中每个检查信息中包括的执行结果相同。
第一数量阈值可以预先进行设置。例如，第一数量阈值可以为2f+1，如此，若获取到 一个提案的聚合检查信息，说明区块链系统中至少有2f+1个节点均针对这个提案生成了执行结果一致的检查信息，即区块链系统中至少有2f+1个节点在执行这个提案后得到了相同的执行结果，从而能够保证区块链系统中的f个恶意节点不能对正常节点的执行过程造成影响。
节点的本地检查信息集中的检查信息是该节点已提交且已获得执行结果的提案的检查信息。该聚合检查信息所属的提案是已取得一定数量的节点执行一致性的提案。因而可将该节点的本地检查信息集中的检查信息与该聚合检查信息进行比较，以确定该节点的本地检查信息集中是否存在某个检查信息所属的提案已具备执行一致性，也即，确定该节点的本地检查信息集中是否存在稳定检查信息，该稳定检查信息所属的提案的执行结果具有一致性，即该稳定检查信息是可信的检查信息。
另外，由于区块链是链式块状结构，所以节点在确定稳定检查信息后，不仅可以确定稳定检查信息所属的提案的执行结果具有一致性，相应的，也可以确定轮次低于该提案的轮次的其他提案的执行结果也具有一致性。由于节点是每提交k个提案时生成其中的第k个提案的检查信息并存储至本地检查信息集，所以节点实际上是每k个提案来选取一个提案的执行结果进行验证，并以此实现间接验证其他k-1个提案的执行结果的目的，如此，实现了阶段性的一致性检查，可以在保证执行结果验证准确度的情况下，提高执行结果验证效率，且降低节点的处理压力。
值得说明的是，本申请实施例中，节点在提案的聚合投票信息满足提交规则时，即可提交这个提案，且执行这个提案。也即，节点在该提案的聚合投票信息满足提交规则时，即可标记该提案的共识已完成，而无需等待该提案的执行结果。节点每提交一定数量的提案后，可根据最新提交的这个提案的执行结果生成这个提案的检查信息并存储至本地检查信息集，之后，将本地检查信息集中的检查信息与聚合检查信息进行比较，来验证本地检查信息集中的检查信息所属的提案的执行结果是否具有一致性，以从本地检查信息集中确定稳定检查信息。这种情况下，通过检查机制单独负责执行结果的验证与一致性保证，保证了提案执行安全性。
如此，将共识过程与执行过程完全解耦。这种情况下，由于不需要在共识过程中穿插执行流程，所以共识时间是可预知的，只与共识消息体以及节点规模等有关，从而可以使用一个恰当的超时阈值来确保共识活性。并且，由于提案提交后才会执行，所以确保了待执行的提案已经共识完毕，此时执行工作不会因共识视图的切换等原因而被抛弃，从而不会浪费处理资源。
其中，该多个节点中的每个节点获取聚合检查信息的操作可以有多种实现方式，下面对三种可能的方式进行说明。
第一种可能的方式：对于该多个节点中的每一个节点，这个节点每生成一个检查信息，向其他节点发送最新生成的这个检查信息。并且，这个节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息的情况下，根据这多个检查信息生成这一提案的聚合检查信息。
在这种方式中，是所有节点交叉广播自身生成的提案的检查信息，每个节点在收集到属于某一提案的一定数量的执行结果一致的检查信息后，就可以将这些检查信息聚合成这一提案的聚合检查信息。
示例地，聚合检查信息包括的所有检查信息携带有相同的区块编号、区块轮次、区块 执行高度和执行结果，且携带有不同的节点签名。也即，聚合检查信息包括的所有检查信息中的提案信息相同，但签名信息不同。
可选地，节点可以在接收到其他节点发送的属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息的情况下，根据这多个检查信息生成这一提案的聚合检查信息。
或者，节点可以在接收到其他节点发送的属于同一提案且执行结果相同的检查信息后，在自身生成的属于这一提案的检查信息中的执行结果与其他节点发送的属于这一提案的检查信息中的执行结果相同，且自身生成的属于这一提案的检查信息的数量与其他节点发送的属于这一提案的检查信息的数量之和大于或等于第一数量阈值的情况下，根据自身生成的属于这一提案的检查信息和其他节点发送的属于这一提案的检查信息生成这一提案的聚合检查信息。
例如，如图3所示，图3中示出了聚合检查信息的生成过程。节点A、节点B、节点C和节点D第一次广播属于提案1的检查信息1后，节点A获取到了四个检查信息1，根据这四个检查信息1生成聚合检查信息1；节点B获取到了三个检查信息1，根据这三个检查信息1生成聚合检查信息1；节点C获取到了三个检查信息1，根据这三个检查信息1生成聚合检查信息1；节点D获取到了两个检查信息1，因数量不足，节点D未生成聚合检查信息。之后，节点A、节点B、节点C和节点D第二次广播属于提案2的检查信息2后，节点A获取到了四个检查信息2，根据这四个检查信息2生成聚合检查信息2；节点B获取到了一个检查信息2，因数量不足，节点B未生成聚合检查信息；节点C获取到了四个检查信息2，根据这四个检查信息2生成聚合检查信息2；节点D获取到了一个检查信息2，因数量不足，节点D未生成聚合检查信息。之后，节点A、节点B、节点C和节点D第三次广播属于提案3的检查信息3后，节点A获取到了一个检查信息3，因数量不足，节点A未生成聚合检查信息；节点B获取到了一个检查信息3，因数量不足，节点B未生成聚合检查信息；节点C获取到了两个检查信息3，因数量不足，节点C未生成聚合检查信息；节点D获取到了四个检查信息3，根据这四个检查信息3生成聚合检查信息3。之后，节点A、节点B、节点C和节点D第四次广播属于提案4的检查信息4后，节点A获取到了两个检查信息4，因数量不足，节点A未生成聚合检查信息；节点B获取到了两个检查信息4，因数量不足，节点B未生成聚合检查信息；节点C获取到了两个检查信息4，因数量不足，节点C未生成聚合检查信息；节点D获取到了两个检查信息4，因数量不足，节点D未生成聚合检查信息。
值得注意的是，本申请实施例中，可以在检查信息的聚合过程中加入超时机制，也即，若某个节点在一定时间内未生成聚合检查信息，则可以尝试重新向其他节点广播最新生成的检查信息。
第二种可能的方式：第i+1轮从节点在确定携带有第i轮提案的提案消息具备合法性后，将针对第i轮提案的投票和最新生成的检查信息携带于一个消息中发送给第i+1轮主节点。第i+1轮主节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息后，根据这多个检查信息生成这一提案的聚合检查信息，将该聚合检查信息、第i+1轮提案和第i轮提案的聚合投票信息均携带于提案消息中发送给第i+1轮从节点。第i+1轮从节点接收携带有该聚合检查信息、第i+1轮提案和第i轮提案的聚合投票信息的提案消息。
在这种方式中，是从节点向同一轮主节点单播检查信息，主节点负责对检查信息进行聚合，然后将聚合检查信息广播给同一轮从节点。也即，从节点可以在每轮投票时附带最新生成的检查信息，将其发送给同一轮主节点。同时，主节点在向同一轮从节点广播提案消息时，附带最新生成的聚合检查信息。如此，可以降低从节点处理压力。
可选地，第i+1轮主节点可以在接收到第i+1轮从节点发送的属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息的情况下，根据这多个检查信息生成这一提案的聚合检查信息。
或者，第i+1轮主节点可以在接收到第i+1轮从节点发送的属于同一提案且执行结果相同的检查信息后，在自身生成的属于这一提案的检查信息中的执行结果与第i+1轮从节点发送的属于这一提案的检查信息中的执行结果相同，且自身生成的属于这一提案的检查信息的数量与第i+1轮从节点发送的属于这一提案的检查信息的数量之和大于或等于第一数量阈值的情况下，根据自身生成的属于这一提案的检查信息和第i+1轮从节点发送的属于这一提案的检查信息生成这一提案的聚合检查信息。
例如，如图4所示，图4示出了聚合检查信息的生成过程。在第一轮共识过程中，在第一轮提案的投票过程中，节点A、节点B、节点C和节点D均在本地生成了检查信息，假设节点B、节点C和节点D是第二轮共识过程中的从节点，节点A是第二轮共识过程中的主节点，因而从节点B、从节点C和从节点D将附带检查信息的投票发送给主节点A，此时主节点A获取到了四个检查信息，根据这四个检查信息可以生成聚合检查信息。在第二轮共识过程中，在第二轮提案的广播过程中，主节点A将聚合检查信息附带在提案消息中广播给从节点C和从节点D，此时从节点C和从节点D就获取到了聚合检查信息。在第二轮提案的投票过程中，假设节点A、节点C和节点D是第三轮共识过程中的从节点，节点B是第三轮共识过程中的主节点，因而从节点A、从节点C和从节点D将附带检查信息的投票发送给主节点B，此时主节点B获取到了四个检查信息，根据这四个检查信息可以生成聚合检查信息。在第三轮共识过程中，在第三轮提案的广播过程中，主节点B将聚合检查信息附带在提案消息中广播给从节点A、从节点C和从节点D。
第三种可能的方式：第i+1轮从节点每生成一个检查信息，将最新生成的这个检查信息发送给第i+j轮主节点。第i+j轮主节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息后，根据这多个检查信息生成这一提案的聚合检查信息，将该聚合检查信息、第i+j轮提案和第i+j-1轮提案的聚合投票信息均携带于提案消息中发送给第i+j轮从节点。第i+j轮从节点接收携带有该聚合检查信息、第i+j轮提案和第i+j-1轮提案的聚合投票信息的提案消息。
j为正整数，且j可以预先设置，如j可以为1、2、3等。在j为1时，从节点是将检查信息发送给同一轮主节点；在j大于或等于2时，从节点是将检查信息发送给下几轮主节点。
在这种方式中，从节点生成检查信息后，可以直接将该检查信息发送给同一轮主节点或下几轮主节点，而无需等待提案投票时机的到来，此时投票与检查信息的发送可以是并行的，如此，可以提高灵活性。并且，在从节点将检查信息发送给下几轮主节点的情况下，可以减轻同一轮主节点的处理压力。
可选地，第i+j轮主节点可以在接收到其他节点发送的属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息的情况下，根据这多个检查信息生成这 一提案的聚合检查信息。
或者，第i+j轮主节点可以在接收到其他节点发送的属于同一提案且执行结果相同的检查信息后，在自身生成的属于这一提案的检查信息中的执行结果与其他节点发送的属于这一提案的检查信息中的执行结果相同，且自身生成的属于这一提案的检查信息的数量与其他节点发送的属于这一提案的检查信息的数量之和大于或等于第一数量阈值的情况下，根据自身生成的属于这一提案的检查信息和其他节点发送的属于这一提案的检查信息生成这一提案的聚合检查信息。
例如，如图5所示，图5示出了聚合检查信息的生成过程。在第一轮共识过程中，在第一轮提案的投票过程中，假设节点B、节点C和节点D是第二轮共识过程中的从节点，节点A是第二轮共识过程中的主节点，此时从节点B、从节点C和从节点D向主节点A发送的投票不附带检查信息。在第二轮共识过程中，在第二轮提案的广播过程中，主节点A将提案消息广播给从节点B、从节点C和从节点D，同时，从节点B、从节点C和从节点D均在本地生成了检查信息，假设从节点B是第三轮共识过程中的主节点，则从节点C和从节点D向从节点B发送检查信息，此时从节点B获取到了三个检查信息，根据这三个检查信息可以生成聚合检查信息。在第二轮提案的投票过程中，第三轮共识过程中的从节点A、从节点C和从节点D向主节点B发送的投票不附带检查信息。在第三轮共识过程中，在第三轮提案的广播过程中，主节点B将聚合检查信息附带在提案消息中广播给从节点A、从节点C和从节点D，此时从节点A、从节点C和从节点D就获取到了聚合检查信息。
稳定检查信息所属的提案是已验证执行结果一致性的提案。也即，将该聚合检查信息与本地检查信息集中的所有检查信息进行比较后，就可以确定出本地检查信息集中的哪些检查信息所属的提案已取得执行结果的一致性，此时就可以将该提案的检查信息确定为稳定检查信息。
其中，节点将本地检查信息集中的检查信息与该聚合检查信息进行比较的操作可以包括如下四种情况：
第一种情况：若本地检查信息集中存在与该聚合检查信息属于同一提案的目标检查信息，且目标检查信息中的执行结果与该聚合检查信息中的执行结果相同，则将目标检查信息设置为最新的稳定检查信息。
若本地检查信息集中的目标检查信息与该聚合检查信息属于同一提案、且其中的执行结果相同，说明当前节点对目标检查信息所属的提案的执行结果与一定数量的其他节点对此提案的执行结果相同，则可以确定该提案的执行结果具有一致性，从而可以确定目标检查信息为稳定检查信息。
由于在稳定检查信息所属的提案的执行结果具有一致性的情况下，轮次低于该提案的轮次的其他提案的执行结果也具有一致性，因此，可选地，节点在设置新的稳定检查信息后，可以持久化最新的稳定检查信息，然后清理轮次低于稳定检查信息所属的提案的轮次的相关提案缓存，如可以清理共识缓存(包括但不限于区块树、聚合投票信息等)，并且，节点还可以清理本地检查信息集中轮次低于稳定检查信息所属的提案的轮次的提案的检查信息。
第二种情况：若本地检查信息集中最新的稳定检查信息所属的提案的轮次高于该聚合检查信息所属的提案的轮次，则忽略该聚合检查信息的处理，结束操作。
若本地检查信息集中最新的稳定检查信息所属的提案的轮次高于该聚合检查信息所属 的提案的轮次，说明节点已验证了该聚合检查信息所属的提案的执行结果的一致性，所以此时节点无需进行操作。
第三种情况：若本地检查信息集中不存在与该聚合检查信息属于同一提案的检查信息，则执行区块同步操作。
节点执行区块同步操作的过程与相关技术中某个节点进行区块同步的过程类似，本申请实施例对此不进行详细阐述。
若本地检查信息集中不存在与该聚合检查信息属于同一提案的检查信息，说明当前节点很有可能丢失了对该聚合检查信息所属的提案的执行，因而此时可以触发区块同步。节点执行区块同步操作时，从其他节点处获取提案的相关信息，以尝试同步到该聚合检查信息所属的提案的执行结果，继而尝试同步到该聚合检查信息所属的提案的检查信息。
第四种情况：若本地检查信息集中存在与该聚合检查信息属于同一提案的目标检查信息，但是目标检查信息中的执行结果与该聚合检查信息中的执行结果不同，则执行区块回滚操作。
节点执行区块回滚操作的过程与相关技术中某个节点进行区块回滚的过程类似，本申请实施例对此不进行详细阐述。
若本地检查信息集中的目标检查信息与该聚合检查信息属于同一提案、但其中的执行结果不同，说明当前节点对目标检查信息所属的提案的执行结果与一定数量的其他节点对此提案的执行结果不同，则可以确定当前节点对该提案的执行很有可能发生错误，因而可以触发区块回滚。节点执行区块回滚操作时，会重新执行该提案，以尝试同步至该聚合检查信息中的执行结果。
进一步地，本申请实施例中，节点不仅可以在每提交k个提案时生成检查信息，还可以在发生共识集群变更的情况下，在提交相应的包含有配置区块(config block)的提案时，直接生成检查信息作为配置检查信息。配置区块是特殊的共识区块，用于更改共识配置，触发共识集群的变更。配置检查信息可以包含共识配置变更的相关信息，如可以包含新变更的共识集群成员列表。
具体来讲，主节点可以在处理共识集群变更交易时构建配置区块，且生成包含有该配置区块的第一提案，然后通过上述步骤201-步骤204进行提案共识流程。这种情况下，任意一个节点可以在提交的提案为包含有配置区块的第一提案的情况下，根据第一提案的执行结果生成第一提案的检查信息作为配置检查信息，将配置检查信息存储至本地检查信息集，然后通过步骤206实现对本地检查信息集中的配置检查信息中的执行结果的验证。这种情况下，节点在本地检查信息集中的配置检查信息达到稳定前，即在本地检查信息集中的配置检查信息未成为稳定检查信息的情况下，只允许提交内容为空的提案，而不提交实质的提案，即不提交除内容为空的提案之外的其他提案。待本地检查信息集中的配置检查信息稳定后，即在本地检查信息集中的配置检查信息成为稳定检查信息后，以配置区块为初始区块继续进行提案共识，即开始新世代(epoch)的共识。
值得说明的是，由于共识集群变更会影响提案的共识过程，因而在处理共识集群变更交易的过程中，对于在共识集群变更交易之后待处理的其他交易，即对于在第一提案之后生成的其他提案，在第一提案执行成功前(即在共识集群变更完成前)，不允许提交这些提案，以此保证区块链的安全性。
进一步地，为了保证检查机制的活性，可以在共识过程中加入包含有验证区块(proof  block)的提案，在提交包含有验证区块的提案时，直接生成检查信息作为强制检查信息。验证区块是特殊的共识区块，可不包含交易，且在一定条件下不可以重复创建验证区块，比如，在3-chain内不可重复创建验证区块，也即，在创建一个验证区块之后的连续三轮共识过程中不能再创建验证区块，也就是说，在生成包含有验证区块的一个提案之后连续生成的三轮提案不能再包含验证区块。
具体地，当主节点发现长时间未形成稳定检查信息时，即主节点在本地检查信息集在预设时长内未形成稳定检查信息时，构建验证区块，且生成包含有该验证区块的第二提案，然后通过上述步骤201-步骤204进行提案共识流程。这种情况下，任意一个节点可以在提交的提案为包含有验证区块的第二提案的情况下，根据第二提案的执行结果生成第二提案的检查信息作为强制检查信息，将强制检查信息存储至本地检查信息集，然后通过步骤206实现对本地检查信息集中的强制检查信息中的执行结果的验证。
值得说明的是，本申请实施例中，在长时间未形成稳定检查信息的情况下，通过验证区块来强制生成强制检查信息并存储至本地检查信息集中。由于验证区块一般不包含交易，所以执行难度较低，容易达到一致，所以便于本地检查信息集中的强制检查信息在短时间内达到稳定，从而可以保持检查机制的活性。
在本申请实施例中，可将共识过程与执行过程完全解耦。由于执行模块在理论上是需要保证一致的，因此执行结果不一致时不应该影响共识结果，因而本申请实施例中共识协议在提交提案后就可以标记该提案的最终一致性，而无需等待该提案的执行结果，本申请实施例中通过检查机制单独负责执行结果的验证与一致性保证。如此，一方面，不影响共识活性。由于不需要在共识过程中穿插执行流程，共识时间是可以预知的，只与共识消息体以及节点规模等有关，因此可以使用一个恰当的超时阈值来确保共识活性。另一方面，资源利用率高。由于提案先完成共识提交后才会执行，即此时共识协议已经确保了待执行的区块已经共识完毕，因而执行工作不会因为共识视图切换等原因而被抛弃，不会造成执行资源浪费。
图6为本申请实施例提供的一种计算机设备的结构示意图。如图6所示，计算机设备6包括：处理器60、存储器61以及存储在存储器61中并可在处理器60上运行的计算机程序62，处理器60执行计算机程序62时实现上述实施例中的提案共识执行方法中的步骤。
计算机设备6可以是一个通用计算机设备或一个专用计算机设备。在具体实现中，计算机设备6可以是包括有多个服务器的服务器集群，如可以是包括有多个节点的区块链系统。本领域技术人员可以理解，图6仅仅是计算机设备6的举例，并不构成对计算机设备6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，比如还可以包括输入输出设备、网络接入设备等。
处理器60可以是中央处理单元(Central Processing Unit，CPU)，处理器60还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者也可以是任何常规的处理器。
存储器61在一些实施例中可以是计算机设备6的内部存储单元，比如计算机设备6的硬盘或内存。存储器61在另一些实施例中也可以是计算机设备6的外部存储设备，比如计 算机设备6上配备的插接式硬盘、智能存储卡(Smart Media Card，SMC)、安全数字(Secure Digital，SD)卡、闪存卡(Flash Card)等。进一步地，存储器61还可以既包括计算机设备6的内部存储单元也包括外部存储设备。存储器61用于存储操作系统、应用程序、引导装载程序(Boot Loader)、数据以及其他程序等。存储器61还可以用于暂时地存储已经输出或者将要输出的数据。
本申请实施例还提供了一种计算机设备，该计算机设备包括：至少一个处理器、存储器以及存储在该存储器中并可在该至少一个处理器上运行的计算机程序，该处理器执行该计算机程序时实现上述任意各个方法实施例中的步骤。
本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时可实现上述各个方法实施例中的步骤。
本申请实施例提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述各个方法实施例中的步骤。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述方法实施例中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，该计算机程序包括计算机程序代码，该计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。该计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-Only Memory，只读光盘)、磁带、软盘和光数据存储设备等。本申请提到的计算机可读存储介质可以为非易失性存储介质，换句话说，可以是非瞬时性存储介质。
应当理解的是，实现上述实施例的全部或部分步骤可以通过软件、硬件、固件或者其任意结合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。该计算机指令可以存储在上述计算机可读存储介质中。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装 置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (15)

  1. 一种提案共识执行方法，其特征在于，应用于区块链系统，所述区块链系统包括多个节点，所述方法包括：
    所述多个节点中的每个节点执行以下操作：
    获取在共识过程中生成的一个提案的聚合投票信息，若所述一个提案的聚合投票信息满足提交规则，则提交所述一个提案，且执行所述一个提案，所述提交所述一个提案是指标记所述一个提案的共识已完成；
    每提交k个提案，根据所述k个提案中的第k个提案的执行结果生成所述第k个提案的检查信息，将所述第k个提案的检查信息存储至本地检查信息集，所述k为正整数；
    获取聚合检查信息，所述聚合检查信息包括所述多个节点中的至少部分节点针对同一提案生成的执行结果一致的检查信息；将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，以从所述本地检查信息集中确定稳定检查信息，所述稳定检查信息所属的提案的执行结果具有一致性。
  2. 如权利要求1所述的方法，其特征在于，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述方法还包括：
    第i轮主节点生成所述第i轮提案，向所述第i轮从节点发送携带有所述第i轮提案的提案消息，所述i为正整数；
    第i+1轮从节点若确定所述提案消息具备合法性，则向所述第i+1轮主节点发送针对所述第i轮提案的投票；
    所述第i+1轮主节点根据所述第i+1轮从节点针对所述第i轮提案的投票生成所述第i轮提案的聚合投票信息，生成第i+1轮提案，向所述第i+1轮从节点发送携带有所述第i+1轮提案和所述第i轮提案的聚合投票信息的提案消息。
  3. 如权利要求1所述的方法，其特征在于，所述获取聚合检查信息，包括：
    每生成一个检查信息，向其他节点发送最新生成的所述一个检查信息；
    在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息的情况下，根据所述多个检查信息生成所述聚合检查信息。
  4. 如权利要求3所述的方法，其特征在于，所述向其他节点发送最新生成的所述一个检查信息之后，还包括：
    若在向所述其他节点发送最新生成的所述一个检查信息后的指定时长内未生成所述聚合检查信息，则重新向所述其他节点发送最新生成的所述一个检查信息。
  5. 如权利要求1所述的方法，其特征在于，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述获取聚合检查信息，包括：
    第i+1轮从节点在确定携带有第i轮提案的提案消息具备合法性后，将针对所述第i轮提案的投票和最新生成的检查信息携带于一个消息中发送给所述第i+1轮主节点；
    所述第i+1轮主节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执 行结果相同的多个检查信息后，根据所述多个检查信息生成所述聚合检查信息，将所述聚合检查信息、所述第i+1轮提案和所述第i轮提案的聚合投票信息均携带于提案消息中发送给所述第i+1轮从节点。
  6. 如权利要求1所述的方法，其特征在于，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述获取聚合检查信息，包括：
    第i+1轮从节点每生成一个检查信息，将最新生成的所述一个检查信息发送给第i+j轮主节点，所述j为正整数；
    所述第i+j轮主节点在获取到属于同一提案的、数量大于或等于第一数量阈值、且执行结果相同的多个检查信息后，根据所述多个检查信息生成所述聚合检查信息，将所述聚合检查信息、所述第i+j轮提案和所述第i+j-1轮提案的聚合投票信息均携带于提案消息中发送给所述第i+j轮从节点。
  7. 如权利要求3-6任一所述的方法，其特征在于，所述第一数量阈值为2f+1，所述f为所述多个节点中恶意节点的数量。
  8. 如权利要求1-6任一所述的方法，其特征在于，所述将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，包括：
    若所述本地检查信息集中存在与所述聚合检查信息属于同一提案的目标检查信息，且所述目标检查信息中的执行结果与所述聚合检查信息中的执行结果相同，则将所述目标检查信息设置为最新的所述稳定检查信息。
  9. 如权利要求8所述的方法，其特征在于，所述将所述目标检查信息设置为最新的所述稳定检查信息之后，还包括：
    清理轮次低于最新的所述稳定检查信息所属的提案的轮次的提案缓存，以及清理所述本地检查信息集中轮次低于最新的所述稳定检查信息所属的提案的轮次的提案的检查信息。
  10. 如权利要求8所述的方法，其特征在于，所述将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，包括：
    若所述本地检查信息集中最新的所述稳定检查信息所属的提案的轮次高于所述聚合检查信息所属的提案的轮次，则结束操作；
    若所述本地检查信息集中不存在与所述聚合检查信息属于同一提案的检查信息，则执行区块同步操作；
    若所述本地检查信息集中存在与所述聚合检查信息属于同一提案的目标检查信息，且所述目标检查信息中的执行结果与所述聚合检查信息中的执行结果不同，则执行区块回滚操作。
  11. 如权利要求1-6任一所述的方法，其特征在于，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述方法还包括：
    所述多个节点中的每个节点执行以下操作：
    在提交的提案为包含有配置区块的第一提案的情况下，根据所述第一提案的执行结果生成所述第一提案的检查信息作为配置检查信息，将所述配置检查信息存储至所述本地检查信息集，所述配置区块是所述主节点在处理共识集群变更交易时构建的；
    在所述本地检查信息集中的所述配置检查信息未成为所述稳定检查信息的情况下，不提交除内容为空的提案之外的其他提案；在所述本地检查信息集中的所述配置检查信息成为所述稳定检查信息后，以所述配置区块为初始区块继续进行提案共识。
  12. 如权利要求1-6任一所述的方法，其特征在于，所述多个节点在每一轮共识过程中存在一个主节点和多个从节点，所述方法还包括：
    所述多个节点中的每个节点执行以下操作：
    在提交的提案为包含有验证区块的第二提案的情况下，根据所述第二提案的执行结果生成所述第二提案的检查信息作为强制检查信息，将所述强制检查信息存储至所述本地检查信息集，所述验证区块是所述主节点在所述本地检查信息集在预设时长内未形成所述稳定检查信息时构建的。
  13. 一种区块链系统，其特征在于，所述区块链系统包括多个节点，所述多个节点中的每个节点用于：
    获取在共识过程中生成的一个提案的聚合投票信息，若所述一个提案的聚合投票信息满足提交规则，则提交所述一个提案，且执行所述一个提案，所述提交所述一个提案是指标记所述一个提案的共识已完成；
    每提交k个提案，根据所述k个提案中的第k个提案的执行结果生成所述第k个提案的检查信息，将所述第k个提案的检查信息存储至本地检查信息集，所述k为正整数；
    获取聚合检查信息，所述聚合检查信息包括所述多个节点中的至少部分节点针对同一提案生成的执行结果一致的检查信息；将所述本地检查信息集中的检查信息与所述聚合检查信息进行比较，以从所述本地检查信息集中确定稳定检查信息，所述稳定检查信息所属的提案的执行结果具有一致性。
  14. 一种计算机设备，其特征在于，所述计算机设备包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至12任一项所述的方法。
  15. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至12任一项所述的方法。
PCT/CN2022/118807 2022-03-30 2022-09-14 提案共识执行方法、区块链系统、设备和存储介质 WO2023184881A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210323741.8 2022-03-30
CN202210323741.8A CN114422155B (zh) 2022-03-30 2022-03-30 提案共识执行方法、区块链系统、设备和存储介质

Publications (1)

Publication Number Publication Date
WO2023184881A1 true WO2023184881A1 (zh) 2023-10-05

Family

ID=81264466

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/118807 WO2023184881A1 (zh) 2022-03-30 2022-09-14 提案共识执行方法、区块链系统、设备和存储介质

Country Status (2)

Country Link
CN (1) CN114422155B (zh)
WO (1) WO2023184881A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117527266A (zh) * 2024-01-05 2024-02-06 杭州趣链科技有限公司 异步网络共识方法、装置、电子设备及可读存储介质
CN118400095A (zh) * 2024-06-27 2024-07-26 杭州高新区(滨江)区块链与数据安全研究院 一种区块链系统的共识方法及装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422155B (zh) * 2022-03-30 2022-08-02 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质
CN118784658A (zh) * 2023-04-07 2024-10-15 腾讯科技（深圳）有限公司 区块链的共识方法、装置、计算机可读介质及电子设备
CN116723200B (zh) * 2023-08-11 2023-11-10 武汉趣链数字科技有限公司 集群变更方法、装置、电子设备及计算机可读存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN110995439A (zh) * 2019-11-20 2020-04-10 上海链颉科技有限公司 区块链共识方法、电子装置及存储介质
CN111427957A (zh) * 2020-03-26 2020-07-17 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质
CN112669149A (zh) * 2020-12-24 2021-04-16 杭州趣链科技有限公司 一种区块链的共识方法、装置、服务器及存储介质
CN114422155A (zh) * 2022-03-30 2022-04-29 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109964446B (zh) * 2018-06-08 2022-03-25 北京大学深圳研究生院 一种基于投票的共识方法
US11201751B2 (en) * 2018-07-18 2021-12-14 iComply Investor Services Inc. System and method for off-chain cryptographic transaction verification
CN109165945B (zh) * 2018-09-07 2021-04-16 腾讯科技（深圳）有限公司 代表节点设备选举方法、装置、计算机设备及存储介质
CN111382456B (zh) * 2020-06-01 2020-10-23 腾讯科技（深圳）有限公司 提案消息处理方法、装置、设备以及存储介质
CN111931220B (zh) * 2020-09-24 2021-01-01 腾讯科技（深圳）有限公司 区块链网络的共识处理方法、装置、介质及电子设备
CN112182113B (zh) * 2020-10-23 2024-06-25 网易（杭州）网络有限公司 区块链共识方法、系统、电子设备及存储介质
CN113127569A (zh) * 2021-05-11 2021-07-16 中国工商银行股份有限公司 用于区块链系统的共识方法、装置、电子设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN110995439A (zh) * 2019-11-20 2020-04-10 上海链颉科技有限公司 区块链共识方法、电子装置及存储介质
CN111427957A (zh) * 2020-03-26 2020-07-17 财付通支付科技有限公司 区块链投票信息校验方法、装置、设备以及存储介质
CN112669149A (zh) * 2020-12-24 2021-04-16 杭州趣链科技有限公司 一种区块链的共识方法、装置、服务器及存储介质
CN114422155A (zh) * 2022-03-30 2022-04-29 杭州趣链科技有限公司 提案共识执行方法、区块链系统、设备和存储介质

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117527266A (zh) * 2024-01-05 2024-02-06 杭州趣链科技有限公司 异步网络共识方法、装置、电子设备及可读存储介质
CN117527266B (zh) * 2024-01-05 2024-05-17 杭州趣链科技有限公司 异步网络共识方法、装置、电子设备及可读存储介质
CN118400095A (zh) * 2024-06-27 2024-07-26 杭州高新区(滨江)区块链与数据安全研究院 一种区块链系统的共识方法及装置

Also Published As

Publication number Publication date
CN114422155B (zh) 2022-08-02
CN114422155A (zh) 2022-04-29

Similar Documents

Publication Publication Date Title
WO2023184881A1 (zh) 提案共识执行方法、区块链系统、设备和存储介质
CN110800005B (zh) 分片式、许可式、分布式分类账
CN110915166B (zh) 区块链
US11411721B2 (en) Systems and methods for selecting and utilizing a committee of validator nodes in a distributed system
US20210026745A1 (en) Methods, systems, and computer readable media for providing byzantine fault tolerance
Kotla et al. Zyzzyva: Speculative byzantine fault tolerance
Dolev et al. Early stopping in Byzantine agreement
KR102019211B1 (ko) 비잔틴 장애를 극복 가능한 블록체인 생성 방법
Yanovich et al. Exonum: Byzantine fault tolerant protocol for blockchains
CN111414413A (zh) 区块链背书验证
JP7212172B2 (ja) 投票集計を伴うトポロジードリブンビザンチンフォールトトレラント合意プロトコル
US20200394162A1 (en) Operation management method for distributed ledger system, operation management system for distributed ledger system, and operation management program for distributed ledger system
Abraham et al. Dfinity consensus, explored
CN112395113B (zh) 实用拜占庭容错共识方法及装置、可读存储介质
CN116132052A (zh) 跨链交易方法、装置、电子设备及存储介质
CN114157550B (zh) 一种基于无冲突事务合并的联盟区块链系统
Hentschel et al. Flow: Separating Consensus and Compute--Execution Verification
Zhao A byzantine fault tolerant distributed commit protocol
CN116009940A (zh) 共识集群的变更方法、装置、计算机设备及介质
CN116232893A (zh) 分布式系统的共识方法、装置、电子设备及存储介质
CN114499874A (zh) 一种应用于工业互联网的拜占庭容错共识优化方法
CN116710919A (zh) 区块链机器网络加速引擎
CN116846916B (zh) 数据同步方法、装置、电子设备及计算机可读存储介质
CN117527266B (zh) 异步网络共识方法、装置、电子设备及可读存储介质
CN115438053A (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: 22934700

Country of ref document: EP

Kind code of ref document: A1