CN114422155B

CN114422155B - Proposal consensus execution method, block chain system, device and storage medium

Info

Publication number: CN114422155B
Application number: CN202210323741.8A
Authority: CN
Inventors: 邱炜伟; 黄方蕾; 张珂杰; 端豪; 尚璇
Original assignee: Hangzhou Qulian Technology Co Ltd
Current assignee: Hangzhou Qulian Technology Co Ltd
Priority date: 2022-03-30
Filing date: 2022-03-30
Publication date: 2022-08-02
Anticipated expiration: 2042-03-30
Also published as: CN114422155A; WO2023184881A1

Abstract

The application discloses a proposal consensus execution method, a block chain system, equipment and a storage medium, and belongs to the technical field of block chains. The method comprises the following steps: if the aggregated voting information of a proposal meets the submission rule, submitting the proposal and executing the proposal; generating the check information of the kth proposal according to the execution result of the kth proposal in the k proposals every time the k proposals are submitted, and storing the check information of the kth proposal into a local check information set; acquiring aggregation check information, wherein the aggregation check information comprises check information with consistent execution results generated by a plurality of nodes aiming at the same proposal; the local check information set is compared with the aggregate check information to determine stable check information, and execution results of proposals to which the stable check information belongs have consistency. The application completely decouples the consensus process and the execution process, and is solely responsible for verifying the execution result and ensuring the consistency through a checking mechanism, so that the consensus activity can be ensured, and the waste of processing resources is avoided.

Description

Proposal consensus execution method, block chain system, device and storage medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a proposed consensus execution method, a blockchain system, a device, and a storage medium.

Background

In the block chain system, the consensus protocol is responsible for carrying out consistency sequencing on the transactions received from the client to obtain a sequenced transaction sequence, and the state machine is only responsible for executing the sequenced transaction sequence. Apparently, after the consensus protocol determines the consistency of the transaction sequence, the consensus task is completed, and the same state machine executing the same transaction sequence will give the same execution result. However, state machines are not secure, and problems at both the software and hardware levels may cause different nodes to run the same state machine to execute the same transaction sequence but to yield different execution results. For this reason, the consensus protocol is also necessary for verification of the consistency of the execution results.

Disclosure of Invention

The application provides a proposal consensus execution method, a block chain system, equipment and a storage medium, which can completely decouple a consensus process from an execution process, and are independently responsible for verification and consistency guarantee of execution results through a checking mechanism, thereby ensuring consensus activity and avoiding waste of processing resources. The technical scheme is as follows:

in a first aspect, a proposal consensus execution method is provided, which is applied to a blockchain system, where the blockchain system includes a plurality of nodes, and the method includes:

each node of the plurality of nodes performs the following operations:

acquiring aggregated voting information of a proposal generated in a consensus process, if the aggregated voting information of the proposal meets a submission rule, submitting the proposal and executing the proposal, wherein submitting the proposal means marking that consensus of the proposal is completed;

generating check information of a kth proposal according to an execution result of the kth proposal in the k proposals every time the kth proposal is submitted, and storing the check information of the kth proposal into a local check information set, wherein k is a positive integer;

acquiring aggregated check information, wherein the aggregated check information comprises check information of consistent execution results generated by at least part of nodes aiming at the same proposal; comparing 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, wherein the execution results of the proposals to which the stable inspection information belongs have consistency.

In the present application, when the aggregate voting information of a proposal satisfies a submission rule, the node can submit the proposal and execute the proposal. That is, when the aggregated voting information of the proposal satisfies the submission rule, the node may mark that the consensus of the proposal is completed without waiting for the execution result of the proposal. After a node submits a certain number of proposals, check information of the proposal can be generated according to the execution result of the newly submitted proposal and stored in a local check information set, and then the check information in the local check information set is compared with the aggregated check information to verify whether the execution results of the proposals to which the check information in the local check information set belongs have consistency, so as to determine stable check information from the local check information set. In this case, the checking mechanism is solely responsible for verifying the execution result and ensuring the consistency, thereby ensuring the safety of proposal execution. In this way, the consensus process is completely decoupled from the execution process. Since there is no need to intersperse flow execution during consensus, the consensus time is predictable, so that an appropriate timeout threshold can be used to ensure consensus activity. And because the proposal is executed after being submitted, the proposal to be executed is ensured to be identified completely, and the execution work can not be abandoned due to the switching of the identified view and other reasons, thereby not wasting the processing resource.

Optionally, the plurality of nodes have one master node and a plurality of slave nodes in each round of consensus process, and the method further includes:

generating the proposal of the ith round by the master node of the ith round, and sending a proposal message carrying the proposal of the ith round to the slave node of the ith round, wherein i is a positive integer;

if the i + 1-th round slave node determines that the proposal message is legal, sending a vote aiming at the i-th round proposal to the i + 1-th round master node;

and the master node in the (i + 1) th round generates the aggregated voting information of the proposal in the (i) th round according to the voting of the slave nodes in the (i + 1) th round aiming at the proposal in the (i) th round, generates the proposal in the (i + 1) th round, and sends proposal information carrying the aggregated voting information of the proposal in the (i + 1) th round and the proposal in the (i) th round to the slave nodes in the (i + 1) th round.

Optionally, the acquiring the aggregated check information includes:

when one piece of check information is generated, the newly generated check information is sent to other nodes;

and under the condition that a plurality of pieces of inspection information belonging to the same proposal, the number of which is greater than or equal to a first number threshold value and the execution results of which are the same are obtained, generating the aggregation inspection information according to the plurality of pieces of inspection information.

Optionally, the obtaining of the aggregated inspection information by the plurality of nodes includes:

after determining that the proposal message carrying the proposal of the ith round has validity, the (i + 1) th round slave node carries the vote aiming at the proposal of the ith round and the latest generated check information in a message and sends the message to the (i + 1) th round master node;

after acquiring a plurality of pieces of check information which belong to the same proposal, are larger than or equal to a first quantity threshold and have the same execution result, the master node in the (i + 1) th round generates the aggregation check information according to the plurality of pieces of check information, and carries the aggregation check information, the (i + 1) th round proposal and the aggregation voting information of the (i) th round proposal in proposal messages to send to the (i + 1) th round slave node.

generating one piece of checking information by the slave node in the (i + 1) th round, and sending the newly generated checking information to the master node in the (i + j) th round, wherein j is a positive integer;

after acquiring a plurality of pieces of inspection information which belong to the same proposal, are larger than or equal to a first quantity threshold and have the same execution result, the master node in the (i + j) th round generates the aggregation inspection information according to the plurality of pieces of inspection information, and carries the aggregation inspection information, the aggregation voting information of the (i + j) th round proposal and the (i + j-1) th round proposal in proposal messages to be sent to the slave node in the (i + j) th round.

Optionally, the first number threshold is 2f +1, and f is the number of malicious nodes in the plurality of nodes.

Optionally, the comparing the inspection information in the local inspection information set with the aggregated inspection information includes:

if target inspection information belonging to the same proposal as the aggregation inspection information exists in the local inspection information set, and the execution result in the target inspection information is the same as the execution result in the aggregation inspection information, setting the target inspection information as the latest stable inspection information.

if the round of the proposal to which the latest stable inspection information belongs in the local inspection information set is higher than the round of the proposal to which the aggregated inspection information belongs, ending the operation;

if the local checking information set does not have checking information belonging to the same proposal as the aggregation checking information, executing block synchronization operation;

and if the local check information set contains target check information belonging to the same proposal as the aggregation check information and the execution result in the target check information is different from the execution result in the aggregation check information, executing block rollback operation.

each node of the plurality of nodes performs the following operations:

generating check information of the first proposal as configuration check information according to an execution result of the first proposal and storing the configuration check information into the local check information set when the submitted proposal is the first proposal containing a configuration block, wherein the configuration block is constructed when the main node processes a consensus cluster change transaction;

in the case that the configuration check information in the local check information set does not become the stable check information, not submitting other proposals except for a proposal with empty content; and after the configuration checking information in the local checking information set becomes the stable checking information, continuing to perform proposal consensus by taking the configuration block as an initial block.

each node of the plurality of nodes performs the following operations:

and under the condition that the submitted proposal is a second proposal containing a verification block, generating check information of the second proposal as mandatory check information according to an execution result of the second proposal, and storing the mandatory check information into the local check information set, wherein the verification block is constructed by the main node when the local check information set does not form the stable check information within a preset time.

In a second aspect, a blockchain system is provided, where the blockchain system includes a plurality of nodes, and each node has a master node and a plurality of slave nodes in each round of consensus process, and the blockchain system is configured to perform the proposed consensus execution method.

In a third aspect, a computer device is provided, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and which when executed by the processor implements the proposed consensus execution method described above.

In a fourth aspect, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the proposed consensus execution method described above.

In a fifth aspect, a computer program product comprising instructions is provided, which when run on a computer, causes the computer to perform the steps of the proposed consensus method described above.

It is to be understood that, for the beneficial effects of the second aspect, the third aspect, the fourth aspect and the fifth aspect, reference may be made to the description of the first aspect, and details are not described herein again.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

Fig. 1 is a schematic structural diagram of a blockchain system according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of a proposed consensus execution method provided by an embodiment of the present application;

fig. 3 is a schematic diagram of a generation process of aggregated check information according to an embodiment of the present application;

fig. 4 is a schematic diagram of another generation process of aggregated check information provided by an embodiment of the present application;

fig. 5 is a schematic diagram of a generation process of still another aggregate check information provided by an embodiment of the present application;

fig. 6 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

It should be understood that reference to "a plurality" in this application means two or more. In the description of the present application, "/" means "or" unless otherwise stated, for example, a/B may mean a or B; "and/or" herein is only an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, for the convenience of clearly describing the technical solutions of the present application, the terms "first", "second", and the like are used to distinguish the same items or similar items having substantially the same functions and actions. Those skilled in the art will appreciate that the terms "first," "second," and the like do not denote any order or importance, but rather the terms "first," "second," and the like do not denote any order or importance.

The statement that "one embodiment" or "some embodiments" or the like are described in this application mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise. Furthermore, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to," unless expressly specified otherwise.

Before explaining the embodiments of the present application in detail, an application scenario of the embodiments of the present application will be described.

The blockchain system includes a plurality of nodes, each node of the plurality of nodes having a transaction pool for storing transactions. After receiving the transaction from the client, any one of the nodes shares the transaction to other nodes, so that the nodes store the transaction in the transaction pool, and thus the transactions stored in the transaction pools of the nodes are consistent and can be processed. For any pending transaction in the transaction pool, the transaction may be executed to be stored to the blockchain after obtaining the consensus of the plurality of nodes.

In the block chain system, the consensus protocol is responsible for carrying out consistency sequencing on the transactions to obtain a sequenced transaction sequence, and the state machine is only responsible for executing the sequenced transaction sequence. Apparently, after the consensus protocol determines the consistency of the transaction sequence, the consensus task is completed, and the same state machine executing the same transaction sequence will give the same execution result. However, state machines are not secure, and problems at both the software and hardware levels may cause different nodes to run the same state machine to execute the same transaction sequence but to yield different execution results. For this reason, the consensus protocol is also necessary for verification of the consistency of the execution results.

Generally, a host stuff consensus algorithm, a PBFT (physical Byzantine Fault tolerant) consensus algorithm, a raw consensus algorithm, or other master node (Leader) -based consensus algorithms are used to agree on a transaction, and after agreement, the transaction is executed to store the transaction to a block chain. The consensus algorithm based on the master node requires a master node to dominate the consensus process, and the master node is a node selected from a plurality of nodes in the blockchain system and used for broadcasting a proposal generated according to a transaction. In each round of consensus process, one node is selected from the plurality of nodes as a master node, and other nodes are taken as slave nodes, so that the proposal consensus is realized through the master node and the slave nodes in each round.

The following takes the PBFT algorithm as an example to describe the implementation process of the proposal consensus in the related art, which includes the following steps (1) to (5):

(1) after the host node generates a proposal according to the transaction to be processed, the host node does not execute the proposal and directly broadcasts the proposal to the slave nodes.

(2) The master node broadcasts the proposal and then enters a pre-prepared stage, and the slave node also enters the pre-prepared stage after receiving the proposal sent by the master node, at this time, the master node and the slave node both execute the proposal (the process can be called pre-execution), the execution change state (namely the pre-execution result) is temporarily stored in the cache and is not written into the block chain, and after the execution of the proposal is completed, a prepare message carrying the execution result is broadcasted.

(3) After any node receives the prefix messages sent by other nodes, the execution results carried in the prefix messages are compared, after 2f +1 prefix messages with consistent execution results are obtained, a prefix stage is entered, and commit (acknowledgement) messages carrying the execution results are broadcasted, wherein f is the tolerable number of Byzantine nodes.

(4) After any node receives the commit messages sent by other nodes, the execution results carried in the commit messages are compared, and after 2f +1 commit messages with consistent execution results are obtained, the consensus protocol submits the proposal and writes the temporarily stored execution change state into the block chain.

(5) If any node does not acquire a sufficient number of commit messages with consistent execution results within the limited time (namely, the timeout threshold), triggering timeout and entering the main node switching process. After the master node is switched, the switched master node initiates a new proposal, and after receiving the new proposal, the corresponding slave node abandons the temporarily stored execution change state and executes the new proposal.

Although the above scheme enables the consensus protocol to verify the consistency of the execution results, the following three problems exist:

first, consensus and execution are highly coupled. The execution process of the proposal is included in the consensus process, and the consensus needs to synchronously wait for the execution result, thereby resulting in lower processing resource utilization rate and consensus efficiency.

Second, consensus activity cannot be guaranteed. Since the execution time of the proposal is unpredictable, it is difficult for the consensus protocol to determine an appropriate timeout threshold, which may result in frequent or even inactive consensus timeouts if the execution time of the proposal is too long.

And thirdly, processing resources are wasted. Since the consensus may be overtime after the pre-execution is completed, and the overtime triggering of the master node switching may give up the previous pre-execution result, which may cause the previous pre-execution work to lose meaning, and waste processing resources seriously.

Therefore, the embodiment of the application provides a proposal consensus execution method, which completely decouples the consensus process and the execution process, and is solely responsible for verification and consistency guarantee of the execution result through a checking mechanism, so that consensus activity can be ensured, and waste of processing resources is avoided.

The following describes the related contents of the block chain system related to the embodiments of the present application.

Fig. 1 is a schematic structural diagram of a blockchain system according to an embodiment of the present disclosure.

Referring to fig. 1, a blockchain system 100 refers to a system for data sharing between nodes, and a plurality of nodes 101 may be included in the blockchain system 100. Each node 101 may receive input information while operating normally and maintain shared data within the blockchain system 100 based on the received input information. In order to ensure information intercommunication in the blockchain system 100, there may be an information connection between each node 101 in the blockchain system 100, and information transmission between the nodes 101 may be performed through the information connection. For example, when an input message is received by any node 101 in the blockchain system 100, other nodes 101 in the blockchain system 100 acquire the input message according to the consensus algorithm, and store the input message as data in the shared data, so that the data stored in all nodes 101 in the blockchain system 100 are consistent. That is, each node 101 in the blockchain system 100 stores one identical blockchain.

The blockchain system 100 has computer technologies such as distributed data storage, point-to-point transmission, consensus mechanisms, encryption algorithms, etc. The blockchain system 100 is a distributed shared ledger and database, and has the characteristics of decentralization, non-tampering, whole-course trace-keeping, traceability, collective maintenance, public transparency and the like. The characteristics ensure that the block chain is shared openly, real and complete, safe and reliable.

The plurality of nodes 101 in the blockchain system 100 have one master node and a plurality of slave nodes in each round of consensus process, and the master node and the plurality of slave nodes in each round may perform the proposal consensus execution method described in the embodiment of fig. 2 below to realize the consensus and execution of each round of proposal.

The implementation of the proposed consensus provided in the embodiments of the present application is explained in detail below.

Fig. 2 is a flowchart of a proposed consensus execution method according to an embodiment of the present application. The method is applied to the block chain system, and particularly can be applied to a consensus protocol in the block chain system. The block chain system comprises a plurality of nodes, wherein a main node and a plurality of slave nodes exist in each round of consensus process.

Referring to fig. 2, the method includes the following steps.

Step 201: and the ith round master node generates an ith round proposal and sends a proposal message carrying the ith round proposal to the ith round slave node, wherein i is a positive integer.

The master node is a node selected from a plurality of nodes in the blockchain system for broadcasting the proposal. In each round of consensus process, one node is selected as a master node, other nodes are selected as slave nodes, and the consensus of the round of proposal is realized through the master node and the slave nodes in each round.

The operation of selecting a master node from a plurality of nodes in a blockchain system may refer to the related art, which is not described in detail in the embodiments of the present application. For example, each node in a plurality of nodes in the blockchain system may be numbered, and then the master nodes are selected by the nodes in turn according to the numbering sequence of the plurality of nodes, and of course, the master nodes may also be selected in other manners, which is not limited in this embodiment of the present application.

It should be noted that there may be a malicious node in a plurality of nodes in the blockchain system, where the malicious node is a node that causes a malicious attack on the security of the blockchain system, that is, the malicious node may block the consensus on the proposal. Optionally, the number of the plurality of nodes is n, the number of malicious nodes in the plurality of nodes is f, and f is smaller than f

For example, n may be an integer greater than or equal to 4, and f may be a positive integer.

The proposal of the ith round generated by the master node of the ith round is generated according to the transaction to be processed in the ith round. For example, the master node in the ith round may construct a new block based on the latest local generated block according to the transaction in the ith round to be processed as the proposal in the ith round, and then broadcast the proposal in the proposal message carried by the ith round to other slave nodes, so that the other slave nodes can commonly identify the proposal in the ith round.

Optionally, the ith round master node may also use its own private key to sign the ith round proposal, and the signature is also carried in the proposal message.

Optionally, in the case that i is 1, that is, in the process of consensus of the first round of proposals, the proposal message broadcast by the ith round master node may carry the ith round of proposals.

In the case that i is greater than or equal to 2, that is, in the process of identifying the second round of proposals and the subsequent proposals, the proposal message broadcast by the ith round master node may carry not only the ith round of proposals, but also aggregated voting information (also referred to as QC (quorum certificate)) of one round (i.e., the (i-1) th round of proposals). The aggregated voting information of the i-1 th round proposal comprises a vote of each node in at least part of nodes in the blockchain system for the i-1 th round proposal, the vote of each node for the i-1 th round proposal can comprise a signature of summary information (namely a hash value) of the i-1 th round proposal by using a private key of the node, and each node can vote the i-1 th round proposal after determining that the proposal is legal. Thus, the aggregated voting information for the i-1 th round of proposal provides evidence of multiple votes for the legitimacy of the i-1 th round of proposal.

Step 202: and if the (i + 1) th round slave node determines that the proposal message carrying the (i) th round proposal is legal, sending a vote aiming at the (i) th round proposal to the (i + 1) th round master node.

The (i + 1) th slave node may comprise an ith master node and an ith slave node. For the ith round master node, after generating a proposal message carrying the ith round proposal, the validity of the proposal message can be verified, and under the condition that the proposal message is determined to have validity, the voting aiming at the ith round proposal is sent to the (i + 1) th round master node. For the ith round slave node, after receiving the proposal message carrying the ith round proposal sent by the ith round master node, the validity of the proposal message can be verified, and under the condition that the validity of the proposal message is determined, the voting aiming at the ith round proposal is sent to the (i + 1) th round master node. The voting by each node for the ith round proposal may include signing the summary information of the ith round proposal with its own private key.

The operation of verifying the validity of the proposal message carrying the ith round of proposal is similar to the operation of verifying the validity of a certain proposal message in the related art, and the embodiment of the application does not describe in detail. For example, the signature of the master node carried in the proposal message may be verified, the transaction contained in the i-th round of proposal carried in the proposal message may also be verified, for example, whether the transaction has a repeated packaging problem, a user signature of the transaction, etc. may be verified, and in addition, the aggregated voting information carried in the proposal message in the previous round of proposal may also be verified, for example, the signature of each node contained in the aggregated voting information may be verified.

It should be noted that, in this embodiment of the application, after obtaining the proposal message carrying the proposal in the i +1 th round, the slave node in the i +1 th round only verifies the legitimacy of the proposal message, but does not perform processing on the proposal in the i th round, and after the legitimacy verification is passed, the slave node in the i +1 th round sends the vote for the proposal in the i th round to the master node in the i +1 th round. Therefore, the process of alternate execution in the consensus process is avoided.

Step 203: and the master node in the (i + 1) th round generates the aggregated voting information of the proposal in the (i) th round according to the voting of the slave nodes in the (i + 1) th round aiming at the proposal in the (i) th round, generates the proposal in the (i + 1) th round, and sends proposal information carrying the aggregated voting information of the proposal in the (i + 1) th round and the proposal in the (i) th round to the slave nodes in the (i + 1) th round.

The aggregated voting information of the ith round of proposal provides evidence of multiple votes for the legitimacy of the ith round of proposal. The aggregated voting information of the ith round of proposals may include votes of a number of slave nodes in the (i + 1) th round of slave nodes for the ith round of proposals.

Alternatively, the (i + 1) th round master node may generate the aggregated voting information of the ith round proposal according to the plurality of votes when the number of the received plurality of votes for the ith round proposal is greater than or equal to the second number threshold. The aggregated voting information of the ith round of proposals at this time may include the plurality of votes, i.e., the votes for the ith round of proposals that include each of the plurality of nodes whose number is greater than or equal to the second number threshold.

The second number threshold may be set in advance. For example, the second number threshold may be 2f +1, so that if the number of the received votes for the ith round of proposal is greater than or equal to 2f +1, which indicates that at least 2f +1 nodes in the blockchain system vote for the ith round of proposal, it can be ensured that f malicious nodes in the blockchain system cannot influence the consensus process of the normal nodes.

The operation of generating the i +1 th round proposal by the i +1 th round master node is similar to the operation of generating the i th round proposal by the i th round master node, and the embodiment of the application is not repeated here.

Step 204: for each of the plurality of nodes, the node obtains aggregated voting information of a proposal generated in the consensus process, submits the proposal if the aggregated voting information of the proposal satisfies the submission rule, and executes the proposal.

Each node in the plurality of nodes may obtain the aggregated voting information of a proposal through the above steps 201 to 203, and specifically, may obtain the aggregated voting information of the last proposal in each round of consensus process. For example, the master node of each round may generate the aggregated voting information of the proposal of the previous round, and the slave node of each round may receive the aggregated voting information of the proposal of the previous round carried in the proposal message sent by the master node. Thus, each node can acquire the aggregated voting information of the proposal.

The submission rule may be preset, for example, the submission rule may be a 3-chain submission rule. The aggregated voting information of a proposal satisfies the submission rule, which indicates that there are a sufficient number of nodes voting for the proposal, i.e., the consensus on the proposal is completed, so that the proposal can be submitted at this time.

Wherein, chain refers to a chain consensus process. The 3-chain submission rule refers to: in the case where the aggregated voting information of each of the three successive rounds of proposals is acquired, the earliest proposal of the three rounds of proposals is submitted. In this case, if the aggregated voting information of each of the three successive rounds of proposals is obtained, it indicates that the earliest proposal in the three rounds of proposals has reached the final confirmation state, that is, there are a sufficient number of trusted nodes to complete the consensus on the earliest proposal, so that the earliest proposal can be submitted.

The node submits the proposal by marking the consensus of the proposal to be completed, and the execution module (also called a state machine) can be asynchronously notified to execute the proposal. And after the node submits the proposal, the node directly continues to perform the next round of consensus process without waiting for the execution result of the proposal. In this manner, consensus and execution may be decoupled.

The operation of the node to execute the proposal is similar to the operation of a node to execute a proposal in the related art, which is not described in detail in the embodiments of the present application.

Step 205: for each node in the plurality of nodes, each time the node submits k proposals, generating the check information of the k proposal according to the execution result of the k proposal in the k proposals, and storing the check information of the k proposal into a local check information set.

k is a positive integer, and k can be set in advance, for example, k can be 1, 5, 10, etc. Thus, after a certain number of proposals are submitted by a node, the node can asynchronously wait for the execution result of the newly submitted proposal by the execution module, and then generate the check information of the proposal according to the execution result of the proposal.

The check information of this proposal is information for checking the execution consistency of this proposal. For example, the checking information of the proposal may include a block number, a block round, and an execution result of the proposal, and further may include a block execution height, a signature of the execution result of the proposal by the node using its own private key, and the like. The block number may be a hash value of a block included in the proposal, the block round may be a consensus round in which the proposal is located, the block execution height may be a height of a block chain after adding the block included in the proposal, and the execution result of the proposal may include a root hash value of a world state after executing the proposal.

Each node has a local set of inspection information. The local check information set of the node stores the check information of the proposal submitted by the node and having obtained the execution result, and the subsequent node can verify whether the execution results of the proposals to which the check information belongs have consistency according to the check information in the local check information set of the node, which is described in the following step 206.

Step 206: for each of the plurality of nodes, the node obtains aggregate check information, compares the check information in the local check information set with the aggregate check information to determine stable check information from the local check information set.

The aggregated check information includes check information in which execution results generated by at least some of the plurality of nodes for the same proposal are consistent, that is, the proposal to which the aggregated check information belongs has acquired execution consistency to some extent. For example, the aggregated check information of one proposal includes check information generated for this proposal by each of at least some of the plurality of nodes whose number is greater than or equal to the first number threshold, that is, the aggregated check information of one proposal includes a plurality of check information whose number is greater than or equal to the first number threshold, and the plurality of check information is generated by a plurality of different nodes, and the execution result included in each of the plurality of check information is the same.

The first number threshold may be set in advance. For example, the first number threshold may be 2f +1, so that if the aggregated check information of a proposal is obtained, it is indicated that at least 2f +1 nodes in the blockchain system generate check information with consistent execution results for the proposal, that is, at least 2f +1 nodes in the blockchain system obtain the same execution results after executing the proposal, so that it can be ensured that f malicious nodes in the blockchain system cannot affect the execution process of the normal nodes.

The check information in the local check information set of a node is the check information of the proposal that the node has submitted and obtained the execution result. The proposal to which the aggregation check information belongs is a proposal that has acquired a certain number of nodes to perform consistency. Thus, the check information in the local check information set of the node may be compared with the aggregated check information to determine whether there is a proposal to which a certain check information belongs in the local check information set of the node that has execution consistency, that is, whether there is stable check information in the local check information set of the node that has execution consistency, that is, the stable check information is authentic check information.

In addition, since the block chain is a chain block structure, after determining the stability check information, the node can determine that not only the execution results of the proposals to which the stability check information belongs have consistency, but also the execution results of other proposals whose turn is lower than that of the proposal also have consistency. The node generates the check information of the kth proposal in the k proposals every time the k proposals are submitted and stores the check information into the local check information set, so that the node actually selects the execution result of one proposal for verification every k proposals, and the aim of indirectly verifying the execution results of other k-1 proposals is fulfilled.

It should be noted that, in the embodiment of the present application, when the aggregated voting information of the proposal satisfies the submission rule, the node may submit the proposal and execute the proposal. That is, when the aggregated voting information of the proposal satisfies the submission rule, the node may mark that the consensus of the proposal is completed without waiting for the execution result of the proposal. After a node submits a certain number of proposals, check information of the proposal can be generated according to the execution result of the newly submitted proposal and stored in a local check information set, and then the check information in the local check information set is compared with the aggregated check information to verify whether the execution results of the proposals to which the check information in the local check information set belongs have consistency, so as to determine stable check information from the local check information set. In this case, the checking mechanism is solely responsible for verifying the execution result and ensuring the consistency, thereby ensuring the safety of proposal execution.

In this way, the consensus process is completely decoupled from the execution process. In this case, since it is not necessary to perform the flow in the consensus process, the consensus time is predictable, and is only related to the consensus message body, the node size, and the like, so that an appropriate timeout threshold can be used to ensure the consensus activity. And because the proposal is executed after being submitted, the proposal to be executed is ensured to be identified completely, and the execution work can not be abandoned due to the switching of the identified view and other reasons, thereby not wasting the processing resource.

There may be multiple implementation manners for each node in the plurality of nodes to obtain the aggregated check information, and three possible manners are described below.

A first possible way: for each of the plurality of nodes, the node generates a check message and sends the newly generated check message to the other nodes. And, when acquiring a plurality of pieces of inspection information belonging to the same proposal, the number of which is greater than or equal to the first number threshold and the execution result of which is the same, the node generates the aggregated inspection information of the proposal based on the plurality of pieces of inspection information.

In this way, all nodes cross-broadcast the inspection information of the proposal generated by themselves, and after each node collects a certain number of inspection information with consistent execution results belonging to a proposal, the inspection information can be aggregated into the aggregated inspection information of the proposal.

Illustratively, all the check information included in the aggregated check information carries the same block number, block turn, block execution height, and execution result, and carries different node signatures. That is, the aggregated check information includes the same proposal information but different signature information among all check information.

Alternatively, the node may generate the aggregated check information of the same proposal according to a plurality of check information which are sent by other nodes and belong to the same proposal, the number of the check information is greater than or equal to the first number threshold, and the execution results are the same.

Alternatively, after receiving the check information which belongs to the same proposal and has the same execution result and is sent by other nodes, the node may generate the aggregated check information of the proposal according to the check information which belongs to the proposal and is generated by itself and the check information which belongs to the proposal and is sent by other nodes, when the execution result of the check information which belongs to the proposal and is generated by itself is the same as the execution result of the check information which belongs to the proposal and is sent by other nodes, and the sum of the number of the check information which belongs to the proposal and is generated by itself and the number of the check information which belongs to the proposal and is sent by other nodes is greater than or equal to a first number threshold.

For example, as shown in fig. 3, a generation process of the aggregation check information is shown in fig. 3. After the node a, the node B, the node C and the node D broadcast the inspection information 1 belonging to the proposal 1 for the first time, the node a acquires the four inspection information 1, and generates the aggregated inspection information 1 according to the four inspection information 1; the node B acquires three pieces of inspection information 1, and generates aggregate inspection information 1 according to the three pieces of inspection information 1; the node C acquires the three pieces of inspection information 1, and generates the aggregation inspection information 1 according to the three pieces of inspection information 1; the node D acquires two pieces of inspection information 1, the factors are insufficient, and the node D does not generate aggregate inspection information. Then, after the node a, the node B, the node C and the node D broadcast the inspection information 2 belonging to the proposal 2 for the second time, the node a acquires the four inspection information 2, and generates the aggregated inspection information 2 according to the four inspection information 2; the node B acquires the check information 2, the factor quantity is insufficient, and the node B does not generate the aggregation check information; the node C acquires the four pieces of inspection information 2, and generates the aggregation inspection information 2 according to the four pieces of inspection information 2; the node D acquires the check information 2, the factor is insufficient, and the node D does not generate the aggregation check information. Then, after the node a, the node B, the node C and the node D broadcast the check information 3 belonging to the proposal 3 for the third time, the node a acquires one check information 3, the factor is insufficient, and the node a does not generate the aggregated check information; the node B acquires a piece of checking information 3, the factor quantity is insufficient, and the node B does not generate aggregation checking information; the node C acquires two pieces of inspection information 3, the factor quantity is insufficient, and the node C does not generate aggregation inspection information; the node D acquires the four pieces of check information 3, and generates the aggregate check information 3 from the four pieces of check information 3. Then, after the node a, the node B, the node C and the node D broadcast the check information 4 belonging to the proposal 4 for the fourth time, the node a acquires the two check information 4, the factor is insufficient, and the node a does not generate the aggregated check information; the node B acquires two pieces of inspection information 4, the factors are insufficient, and the node B does not generate aggregation inspection information; the node C acquires two pieces of inspection information 4, the factor is insufficient, and the node C does not generate aggregation inspection information; the node D acquires two pieces of check information 4, the factors are insufficient, and the node D does not generate aggregate check information.

It should be noted that, in the embodiment of the present application, a timeout mechanism may be added in the aggregation process of the check information, that is, if a certain node does not generate the aggregated check information within a certain time, it may try to broadcast the newly generated check information to other nodes again.

A second possible way: and after determining that the proposal message carrying the proposal of the ith round has validity, the (i + 1) th round slave node carries the vote aiming at the proposal of the ith round and the latest generated check information in a message and sends the message to the (i + 1) th round master node. After acquiring a plurality of pieces of check information belonging to the same proposal, the number of which is greater than or equal to the first number threshold and the execution result of which is the same, the master node in the (i + 1) th round generates the aggregate check information of the proposal according to the plurality of pieces of check information, and carries the aggregate check information, the (i + 1) th round proposal and the aggregate voting information of the (i) th round proposal in the proposal message to be sent to the (i + 1) th round slave node. And receiving proposal information carrying the aggregation check information, the proposal of the (i + 1) th round and the aggregation voting information of the proposal of the (i) th round from the node in the (i + 1) th round.

In this way, the slave nodes unicast the check information to the master node in the same round, and the master node is responsible for aggregating the check information and then broadcasting the aggregated check information to the slave nodes in the same round. That is, the slave node may attach the newly generated check information to each round of voting, and transmit the check information to the master node in the same round. Meanwhile, when broadcasting proposal information to the slave nodes in the same round, the master node attaches the newly generated aggregation check information. In this manner, slave node processing pressure may be reduced.

Alternatively, the master node in round i +1 may generate the aggregated check information of the proposal according to a plurality of check information, which are sent by the slave nodes in round i +1, and belong to the same proposal, and have the same execution result, when receiving the plurality of check information, which are sent by the slave nodes in round i +1 and have a number greater than or equal to the first number threshold.

Alternatively, after receiving the inspection information belonging to the same proposal and having the same execution result, which is transmitted by the slave node in the (i + 1) th round, the master node in the (i + 1) th round may generate the aggregated inspection information of the proposal according to the inspection information belonging to the proposal, which is generated by the master node in the (i + 1) th round, if the execution result in the inspection information belonging to the proposal, which is generated by the master node in the (i + 1) th round, is the same as the execution result in the inspection information belonging to the proposal, which is transmitted by the slave node in the (i + 1) th round, and the sum of the number of the inspection information belonging to the proposal, which is generated by the master node in the (i + 1) th round, and the number of the inspection information belonging to the proposal, which is transmitted by the slave node in the (i + 1) th round, is greater than or equal to the first number threshold.

For example, as shown in fig. 4, fig. 4 shows a generation process of the aggregated check information. In the first round of consensus process, in the voting process of the first round of proposal, all the node a, the node B, the node C and the node D generate the check information locally, and assuming that the node B, the node C and the node D are the slave nodes in the second round of consensus process and the node a is the master node in the second round of consensus process, the slave node B, the slave node C and the slave node D send the votes with the check information to the master node a, and at this time, the master node a acquires four check information, and can generate the aggregated check information according to the four check information. In the second round of consensus process, in the broadcasting process of the second round of proposal, the master node a broadcasts the aggregation check information in the proposal message to the slave node C and the slave node D, and at this time, the slave node C and the slave node D acquire the aggregation check information. In the voting process of the second round of proposal, it is assumed that node a, node C and node D are slave nodes in the third round of consensus process, and node B is a master node in the third round of consensus process, so that the slave nodes a, C and D send votes with check information to the master node B, and at this time, the master node B acquires four pieces of check information, and can generate aggregated check information according to the four pieces of check information. In the third round of consensus process, the master node B broadcasts the aggregation check information in a proposal message to the slave node a, the slave node C, and the slave node D in the broadcast of the third round of proposal.

A third possible way: and (4) generating one check information every time the (i + 1) th round slave node generates, and sending the newly generated check information to the (i + j) th round master node. After acquiring a plurality of pieces of check information which belong to the same proposal, are more than or equal to a first quantity threshold and have the same execution result, the master node in the (i + j) th round generates the aggregate check information of the proposal according to the plurality of pieces of check information, and carries the aggregate check information, the aggregate voting information of the (i + j) th round proposal and the (i + j-1) th round proposal in the proposal message and sends the aggregate voting information to the slave node in the (i + j) th round. And receiving proposal information carrying the aggregation check information, the proposal of the (i + j) th round and the aggregation voting information of the proposal of the (i + j-1) th round from the node in the (i + j) th round.

j is a positive integer, and j can be preset, for example, j can be 1, 2, 3, etc. When j is 1, the slave node sends the checking information to the master node in the same round; when j is greater than or equal to 2, the slave node sends the check information to the master node in the next few rounds.

In this way, after the slave node generates the check information, the check information can be directly sent to the master node of the same round or the next rounds without waiting for the arrival of the proposed voting opportunity, and the voting and the sending of the check information can be in parallel, so that the flexibility can be improved. In addition, when the slave node transmits the check information to the master node of the next several rounds, the processing load of the master node of the same round can be reduced.

Alternatively, the master node in round i + j may generate the aggregate check information of the proposal according to a plurality of check information which is sent by other nodes, belongs to the same proposal, has a number greater than or equal to the first number threshold, and has the same execution result.

Alternatively, after receiving the inspection information belonging to the same proposal and having the same execution result, sent by another node, the i + j-th turn master node may generate the aggregated inspection information of the proposal based on the inspection information belonging to the proposal generated by itself and the inspection information belonging to the proposal sent by another node, when the execution result in the inspection information belonging to the proposal generated by itself is the same as the execution result in the inspection information belonging to the proposal sent by another node, and the sum of the number of the inspection information belonging to the proposal generated by itself and the number of the inspection information belonging to the proposal sent by another node is greater than or equal to a first number threshold.

For example, as shown in fig. 5, fig. 5 shows a generation process of the aggregated check information. In the first round of consensus process, in the voting process of the first round of proposal, it is assumed that node B, node C and node D are slave nodes in the second round of consensus process, and node a is a master node in the second round of consensus process, and at this time, no check information is attached to the votes sent from node B, node C and node D to master node a. In the second round of consensus process, in the second round of proposal broadcasting process, the master node a broadcasts the proposal message to the slave node B, the slave node C and the slave node D, meanwhile, the slave node B, the slave node C and the slave node D all generate check information locally, and if the slave node B is the master node in the third round of consensus process, the slave node C and the slave node D transmit the check information to the slave node B, and at this time, the slave node B acquires three check information, and the aggregate check information can be generated according to the three check information. In the voting process of the second round of proposal, the votes transmitted from the slave node a, the slave node C, and the slave node D to the master node B in the third round of consensus process are not accompanied by check information. In the third round of consensus process, in the third round of broadcast of the proposal, the master node B broadcasts the aggregation check information to the slave node a, the slave node C and the slave node D in the proposal message, and at this time, the slave node a, the slave node C and the slave node D acquire the aggregation check information.

The proposal to which the stability check information belongs is a proposal for which the consistency of the execution results has been verified. That is, after comparing the aggregated check information with all the check information in the local check information set, it can be determined which of the check information in the local check information set belongs to the proposal that has obtained the consistency of the execution result, and at this time, the check information of the proposal can be determined as the stable check information.

The operation of comparing the check information in the local check information set with the aggregated check information by the node may include the following four cases:

in the first case: if target check information belonging to the same proposal as the aggregation check information exists in the local check information set and the execution result in the target check information is the same as the execution result in the aggregation check information, the target check information is set as the latest stable check information.

If the target check information in the local check information set and the aggregated check information belong to the same proposal and the execution result is the same, which indicates that the execution result of the proposal to which the target check information belongs by the current node is the same as the execution result of the proposal by a certain number of other nodes, the execution result of the proposal can be determined to have consistency, and thus the target check information can be determined to be stable check information.

Since the execution results of other proposals with a lower round than that of the proposal have consistency in the case that the execution results of the proposals to which the stable inspection information belongs have consistency, optionally, after setting new stable inspection information, the node may persist the latest stable inspection information, and then clear the relevant proposal cache with a lower round than that of the proposals to which the stable inspection information belongs, such as clear the consensus cache (including but not limited to the block tree, the aggregated voting information, and the like), and the node may also clear the inspection information of the proposals with a lower round than that of the proposals to which the stable inspection information belongs in the local inspection information set.

In the second case: if the round of the proposal to which the latest stable inspection information in the local inspection information set belongs is higher than the round of the proposal to which the aggregation inspection information belongs, the processing of the aggregation inspection information is ignored, and the operation is ended.

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 aggregation check information belongs, the node verifies the consistency of the execution results of the proposals to which the aggregation check information belongs, so that the node does not need to operate at this time.

In the third case: if the local checking information set does not have the checking information belonging to the same proposal as the aggregation checking information, the block synchronization operation is executed.

The process of the node performing the block synchronization operation is similar to the process of performing the block synchronization by a certain node in the related art, and is not described in detail in the embodiments of the present application.

If the local check information set does not have the check information belonging to the same proposal as the aggregation check information, it indicates that the current node is likely to lose the execution of the proposal to which the aggregation check information belongs, and thus block synchronization can be triggered at this time. When a node performs a block synchronization operation, relevant information of a proposal is acquired from other nodes to attempt synchronization to an execution result of the proposal to which the aggregate check information belongs, and then synchronization to check information of the proposal to which the aggregate check information belongs is attempted.

In a fourth case: if the local check information is centralized with target check information belonging to the same proposal as the aggregation check information, but the execution result in the target check information is different from the execution result in the aggregation check information, the block rollback operation is executed.

The process of the node performing the block rollback operation is similar to the process of performing the block rollback operation by a certain node in the related art, which is not described in detail in the embodiments of the present application.

If the target check information in the local check information set and the aggregated check information belong to the same proposal but have different execution results, which indicates that the execution result of the proposal to which the target check information belongs by the current node is different from the execution result of the proposal by a certain number of other nodes, it can be determined that the execution of the proposal by the current node is likely to be wrong, and thus block rollback can be triggered. When the node performs the block rollback operation, it re-executes the proposal to attempt to synchronize to the execution result in the aggregated check information.

Further, in this embodiment of the application, the node may not only generate the check information every time k proposals are submitted, but also directly generate the check information as the configuration check information when a corresponding proposal including a configuration block (config block) is submitted in a case where the consensus cluster change occurs. The configuration block is a special consensus block for changing the consensus configuration and triggering the change of the consensus cluster. The configuration check information may include information regarding consensus configuration changes, such as a list of consensus cluster members that may include new changes.

Specifically, the master node may construct a configuration block when processing the consensus cluster change transaction, generate a first proposal including the configuration block, and then perform the proposal consensus process through the above steps 201 to 204. In this case, when the submitted proposal is the first proposal including the configuration block, any node may generate the check information of the first proposal as the configuration check information according to the execution result of the first proposal, store the configuration check information into the local check information set, and then verify the execution result in the configuration check information in the local check information set through step 206. In this case, the node only allows to submit the proposal whose content is empty, but not to submit the substantial proposal, that is, does not submit any other proposal except the proposal whose content is empty, before the configuration check information in the local check information set becomes stable, that is, in the case where the configuration check information in the local check information set does not become stable check information. After the configuration check information in the local check information set is stable, that is, after the configuration check information in the local check information set becomes stable check information, the proposal consensus is continued by using the configuration block as an initial block, that is, the consensus of a new generation (epoch) is started.

It should be noted that, since the consensus cluster change affects the consensus process of the proposals, in the process of processing the consensus cluster change transaction, for other transactions to be processed after the consensus cluster change transaction, that is, for other proposals generated after the first proposal, the proposals are not allowed to be submitted until the first proposal is successfully executed (that is, until the consensus cluster change is completed), so as to ensure the security of the block chain.

Further, in order to ensure the activity of the checking mechanism, a proposal containing a verification block (proof block) may be added in the consensus process, and when the proposal containing the verification block is submitted, the checking information is directly generated as the mandatory checking information. The verification block is a special consensus block, may not contain a transaction, and may not be created repeatedly under certain conditions, for example, the verification block may not be created repeatedly within 3-chain, i.e., the verification block may not be created again in three consecutive rounds of consensus after creating a verification block, i.e., three consecutive rounds of proposals after creating a proposal containing the verification block may not contain the verification block.

Specifically, when the master node finds that the stability check information is not formed for a long time, that is, when the master node does not form the stability check information in the local check information set within the preset time, a verification block is constructed, a second proposal including the verification block is generated, and then a proposal consensus process is performed through the above steps 201 to 204. In this case, when the submitted proposal is the second proposal including the verification block, any node may generate the check information of the second proposal as the mandatory check information according to the execution result of the second proposal, store the mandatory check information in the local check information set, and then implement verification of the execution result in the mandatory check information in the local check information set through step 206.

It should be noted that, in the embodiment of the present application, when stable inspection information is not formed for a long time, the forced inspection information is forcibly generated by the verification block and stored in the local inspection information set. Since the verification block does not generally contain transactions, the execution difficulty is low, consistency is easy to achieve, forced inspection information in local inspection information set is convenient to achieve stability in a short time, and therefore the activity of an inspection mechanism can be kept.

In embodiments of the present application, the consensus process may be completely decoupled from the execution process. Since the execution module needs to guarantee consistency in theory, the consensus result should not be affected when the execution result is inconsistent, so that the consensus protocol in the embodiment of the present application can mark the final consistency of the proposal after the proposal is submitted, and does not need to wait for the execution result of the proposal. Thus, on the one hand, the consensus activity is not affected. Since there is no need to interwork the flow in the consensus process, the consensus time is predictable, and is only related to the consensus message body, the node size, etc., so that an appropriate timeout threshold can be used to ensure the consensus activity. On the other hand, the resource utilization rate is high. Since the proposal is executed after the consensus submission is completed, that is, the consensus protocol ensures that the blocks to be executed are already known, the execution task is not discarded due to the reasons of consensus view switching, and the like, and the execution resource waste is not caused.

Fig. 6 is a schematic structural diagram of a computer device according to an embodiment of the present application. As shown in fig. 6, the computer device 6 includes: a processor 60, a memory 61, and a computer program 62 stored in the memory 61 and operable on the processor 60, wherein the steps of the proposed consensus execution method in the above-described embodiments are implemented when the processor 60 executes the computer program 62.

The computer device 6 may be a general purpose computer device or a special purpose computer device. In particular implementations, computer device 6 may be a server cluster comprising a plurality of servers, such as may be a blockchain system comprising a plurality of nodes. Those skilled in the art will appreciate that fig. 6 is merely an example of the computer device 6 and does not constitute a limitation of the computer device 6, and may include more or less components than those shown, or combine certain components, or different components, such as input output devices, network access devices, etc.

The Processor 60 may be a Central Processing Unit (CPU), and the Processor 60 may also be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or any conventional processor.

The memory 61 may in some embodiments be an internal storage unit of the computer device 6, such as a hard disk or a memory of the computer device 6. The memory 61 may also be an external storage device of the computer device 6 in other embodiments, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like provided on the computer device 6. 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 for storing an operating system, an application program, a Boot Loader (Boot Loader), 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 embodiment of the present application further provides a computer device, where 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 implementing the steps of any of the various method embodiments described above when executing the computer program.

The embodiments of the present application also provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

The embodiments of the present application provide a computer program product, which when run on a computer causes the computer to perform the steps of the above-described method embodiments.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the above method embodiments may be implemented by a computer program, which may be stored in a computer readable storage medium and used for instructing relevant hardware to implement the steps of the above method embodiments when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or apparatus capable of carrying computer program code to a photographing apparatus/terminal device, a recording medium, computer Memory, ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, optical data storage device, etc. The computer-readable storage medium referred to herein may be a non-volatile storage medium, in other words, a non-transitory storage medium.

It should be understood that all or part of the steps for implementing the above embodiments may be implemented by software, hardware, firmware or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. The computer instructions may be stored in the computer-readable storage medium described above.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/computer device and method may be implemented in other ways. For example, the above-described apparatus/computer device embodiments are merely illustrative, and for example, a module or a unit may be divided into only one logical function, and may be implemented in other ways, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A proposal consensus execution method applied to a blockchain system, the blockchain system comprising a plurality of nodes, the method comprising:

each node of the plurality of nodes performs the following operations:

acquiring aggregated voting information of a proposal generated in a consensus process, submitting the proposal and executing the proposal if the aggregated voting information of the proposal meets a submission rule, wherein the submission of the proposal indicates that consensus of the proposal is completed, and the aggregated voting information of the proposal comprises a vote of each node in at least part of nodes in the plurality of nodes for the proposal;

acquiring aggregation check information, wherein the aggregation check information comprises check information of consistent execution results generated by at least part of nodes aiming at the same proposal; comparing 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, wherein the execution results of the proposals to which the stable inspection information belongs have consistency.

2. The method of claim 1, wherein the plurality of nodes have one master node and a plurality of slave nodes in each round of consensus process, the method further comprising:

if the i +1 th round slave node determines that the proposal message is legal, sending a vote aiming at the i +1 th round proposal to the i +1 th round master node;

3. The method of claim 1, wherein the obtaining aggregate check information comprises:

4. The method of claim 1, wherein the plurality of nodes have one master node and a plurality of slave nodes in each round of consensus process, and the obtaining the aggregated check information comprises:

5. The method of claim 1, wherein the plurality of nodes have one master node and a plurality of slave nodes in each round of consensus process, and the obtaining the aggregated check information comprises:

6. The method of any of claims 3-5, wherein the first number threshold is 2f +1, where f is a number of malicious nodes in the plurality of nodes.

7. The method of any of claims 1-5, wherein said comparing the inspection information in the local set of inspection information with the aggregated inspection information comprises:

8. The method of claim 7, wherein said comparing the inspection information in the local set of inspection information to the aggregated inspection information comprises:

9. The method of any one of claims 1-5, wherein there is one master node and multiple slave nodes in each round of consensus, the method further comprising:

each node of the plurality of nodes performs the following operations:

10. The method of any one of claims 1-5, wherein there is one master node and multiple slave nodes in each round of consensus, the method further comprising:

each node of the plurality of nodes performs the following operations:

11. A blockchain system, the blockchain system comprising a plurality of nodes, each node of the plurality of nodes configured to:

12. A computer device, characterized in that the computer device comprises a memory, a processor and a computer program stored in the memory and executable on the processor, which computer program, when executed by the processor, implements the method according to any of claims 1 to 10.

13. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed by a processor, implements the method of any one of claims 1 to 10.