Consensus method and apparatus for blockchain system

Abstract

The present application is applicable to the technical field of blockchains. Provided are a consensus method and apparatus for a blockchain system. The consensus method comprises: in an (n+x2)th consensus round, referencing a plurality of proposal blocks, and combining same with the current transaction of a client, so as to generate a post-proposal block, wherein the plurality of proposal blocks are correspondingly generated by a plurality of validator nodes referencing a pre-proposal block in an nth consensus round, and the pre-proposal block is generated in an (n-x1)th consensus round; and using the post-proposal block as a certificate for the pre-proposal block, so as to reach a consensus on the pre-proposal block. By using the consensus method provided in the present application, it is unnecessary to transmit a large number of signature messages during a consensus process, instead, a reference relationship is established between blocks which are generated in different consensus rounds, so as to reach a consensus on a certain block. In this way, the overheads of transmitting and verifying signature messages during a consensus process are reduced.

Description

Consensus method and device of a blockchain system

[0001] The present application claims priority to the Chinese patent application No. 202410844017.9, filed on June 27, 2024, and entitled "Consensus method and device of a blockchain system", the whole content of which is incorporated herein by reference. TECHNICAL FIELD

[0002] The present application belongs to the field of blockchain technology, and in particular relates to a consensus method and device of a blockchain system. BACKGROUND

[0003] In a blockchain, a consensus mechanism is used to ensure that all nodes on the network agree on the current state of the network and the authenticity of transactions, which is crucial for maintaining the security and integrity of the blockchain. A validating node participating in the consensus needs to verify and sign a block, and according to the principle of Byzantine fault tolerance, a block with a quorum of 2f+1 signature votes can pass the verification and be correctly submitted and recorded in the blockchain. The signature quorum 2f+1 is directly proportional to the total number of validating nodes 3f+1 in the system. When the number of validating nodes in the system increases dramatically, the number of signatures required for each block also increases dramatically, and the transmission and verification overhead of signature messages becomes very large and difficult to control. Therefore, how to reduce the transmission and verification cost of signature messages in the consensus process has become a technical problem to be solved. TECHNICAL PROBLEM

[0004] The present application provides a consensus method and device of a blockchain system, which can solve the problem of high transmission and verification cost of signature messages in the consensus process. TECHNICAL SOLUTION

[0005] In a first aspect, the present application provides a consensus method of a blockchain system, the blockchain system comprising a plurality of validating nodes, the consensus method being executed by a validating node, and the consensus method comprising:

[0006] In the n+x2th consensus round, a post-proposal block is generated by referencing a plurality of proposal blocks and combining the current transactions of the client; wherein the plurality of proposal blocks are generated by referencing a pre-proposal block in the nth consensus round by a plurality of validating nodes, and the pre-proposal block is generated in the n-x1th consensus round;

[0007] The post-proposal block is used as a certificate of the pre-proposal block to consensus the pre-proposal block.

[0008] In a possible implementation, x1 and x2 are the same or different, and each of x1 and x2 is equal to 1 or not equal to 1.

[0009] In a possible implementation, the plurality of validation nodes reference a preceding proposal block to correspondingly generate a proposal block, including:

[0010] The validation node, together with other validation nodes, references a preceding proposal block to correspondingly generate a proposal block.

[0011] In a possible implementation, the step of referencing any one proposal block includes referencing a hash index of the any one proposal block, wherein the any one proposal block is one of the proposal block and the preceding proposal block.

[0012] In a possible implementation, the preceding proposal block is generated by the validation node, or the preceding proposal block is generated by other validation nodes.

[0013] In a possible implementation, the following proposal block is used as a certificate of the preceding proposal block, including:

[0014] The following proposal block is used as a certificate of the preceding proposal block, independently generated by the validation node and at least one other validation node, wherein if the number of certificates is greater than a preset threshold, the preceding proposal block is verified.

[0015] In a possible implementation, the number of proposal blocks is not less than 2f+1, wherein f is the number of dishonest validation nodes in the nth consensus round, and 3f+1 is the total number of validation nodes in the nth consensus round.

[0016] In a second aspect, an embodiment of the present application provides a consensus device of a block chain system, including:

[0017] A following proposal block generation module is configured to reference a plurality of proposal blocks in an nth+x2 consensus round, and generate a following proposal block in combination with a current transaction of a client, wherein the plurality of proposal blocks are generated by a plurality of validation nodes in correspondence with a preceding proposal block referenced in an nth consensus round, and the preceding proposal block is generated in an nth-x1 consensus round.

[0018] A consensus module is configured to use the following proposal block as a certificate of the preceding proposal block, to consensus the preceding proposal block.

[0019] In a possible implementation, x1 and x2 are the same or different, and x1 and x2 are each equal to 1 or each not equal to 1.

[0020] In a possible implementation, the validation node is configured to reference a preceding proposal block to correspondingly generate a proposal block, together with other validation nodes.

[0021] In a possible implementation, the post-proposal block generation module is specifically configured to quote a hash index of the arbitrary proposal block, where the arbitrary proposal block is one of the proposal block and the pre-proposal block.

[0022] In a possible implementation, the pre-proposal block is generated by the current verification node, or the pre-proposal block is generated by another verification node.

[0023] In a possible implementation, the consensus module is specifically configured to independently generate, together with at least one post-proposal block generated by another verification node, a certificate of the post-proposal block as the pre-proposal block, and if the number of certificates is greater than a preset threshold, the pre-proposal block is verified.

[0024] In a possible implementation, the number of proposal blocks is not less than 2f+1, where f is the number of dishonest verification nodes in the n th consensus round, and 3f+1 is the total number of verification nodes in the n th consensus round.

[0025] In a third aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the method described above when executing the computer program.

[0026] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the method described above. Advantages

[0027] The present application provides a consensus method, device, terminal device and storage medium, which replaces the signature message in the traditional consensus method by using the reference relationship, that is, if a verification node references a proposal block, it means that the verification node has verified the proposal block. Therefore, by using the consensus method provided by the present application, a large number of signature messages no longer need to be transmitted in the consensus process, but the reference relationship between blocks generated in different consensus rounds is established to perform consensus on a certain block. In this way, the overhead of transmitting and verifying signature messages in the consensus process is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiments or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0029] FIG. 1 is a flowchart of a consensus method according to an embodiment of the present application;

[0030] FIG. 2 is a schematic diagram of an embodiment 1 of the present application;

[0031] FIG. 3 is a schematic diagram of an embodiment 2 of the present application;

[0032] FIG. 4 is a schematic diagram of an embodiment 3 of the present application;

[0033] FIG. 5 is a schematic diagram of a reference relationship according to an embodiment of the present application;

[0034] FIG. 6 is a schematic diagram of an embodiment 4 of the present application;

[0035] FIG. 7 is a schematic diagram of an embodiment 5 of the present application;

[0036] FIG. 8 is a schematic diagram of an embodiment 6 of the present application;

[0037] FIG. 9 is a schematic diagram of an embodiment 7 of the present application;

[0038] FIG. 10 is a schematic diagram of an embodiment 8 of the present application;

[0039] FIG. 11 is a schematic diagram of an embodiment 9 of the present application;

[0040] FIG. 12 is a schematic diagram of an embodiment 10 of the present application;

[0041] FIG. 13 is a schematic diagram of an embodiment 11 of the present application;

[0042] FIG. 14 is a schematic diagram of a consensus device according to an embodiment of the present application;

[0043] FIG. 15 is a schematic diagram of a terminal device according to an embodiment of the present application.

[0044] Embodiments of the present application

[0045] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular architectures, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, circuits, and

[0046] It is to be understood that the terminology "includes", "has", "holds", "contains" and / or the like, when used in the present specification and in the accompanying claims, indicates the presence of the described features, integers, steps, operations, elements, and / or components but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0047] It should also be understood that the term “and / or” as used herein, means any one or more of the associated listed items, and that the term “and / or” as used herein, can be interpreted to mean “one or more” of the associated listed items, and that the term “and / or” as used herein, can be interpreted to mean “one, two, three, or four” of the associated listed items, and that the term “and / or” as used herein, can be interpreted to mean “one, two, three, four, five, six, seven, eight, nine, ten, or more” of the associated listed items.

[0048] As used in the description of the application and the appended claims, the term “if’ can be interpreted to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a described condition or event] is detected” can be interpreted to mean “upon determining” or “in response to determining” or “upon [the described condition or event] being detected” or “in response to [the described condition or event] being detected,” depending on the context.

[0049] In addition, the terms “first,” “second,” “third,” etc. as used in the description of embodiments herein and throughout the claims (if any), are not used to connote any relative importance but are used merely as distinguishing designations.

[0050] Reference throughout this specification to “an embodiment” or “some embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. Thus, appearances of the phrases “in one embodiment,” “in some embodiments,” “in other embodiments,” “in additional embodiments,” and so on, in various places throughout this specification are not necessarily all referring to the same embodiment, unless otherwise specified by the context. The terms “including,” “containing,” “comprising,” and similar terms are meant to be open-ended and non-limiting.

[0051] In a blockchain system, the consistency of distributed nodes in the system must be ensured by a consensus protocol. Each verification node in the consensus protocol is also referred to as a consensus node, which needs to verify and sign a block. According to the principle of Byzantine fault tolerance, a block with a quorum of 2f+1 signature votes can pass the verification and be correctly submitted and recorded in the blockchain. The signature quorum 2f+1 is proportional to the total number of verification nodes 3f+1 in the system. When the number of verification nodes in the system increases dramatically, the number of signatures required for each block also increases dramatically. At this time, the transmission and verification overhead of the signature message becomes very large and difficult to control. Therefore, how to reduce the transmission and verification cost of the signature message in the consensus process has become a technical problem to be solved.

[0052] The application provides a consensus method, device, terminal equipment and storage medium. The reference relationship is used to replace the signature message in the traditional consensus method, that is, if a verification node references a proposal block, it means that the verification node has verified the proposal block. Therefore, in the consensus process, a large number of signature messages no longer need to be transmitted, and it is determined whether a proposal block is verified by a sufficient number of verification nodes by checking the reference relationship. In this way, the overhead of transmitting and verifying signature messages in the consensus process is reduced.

[0053] In order to illustrate the technical solutions of the application, specific embodiments are used for illustration below.

[0054] Referring to the flow of one embodiment of the consensus method of the blockchain system shown in FIG. 1, as an example but not limitation, the following steps are included:

[0055] Step S100: In the n+x2th consensus round, reference multiple proposal blocks, and generate a post-proposal block in combination with the current transaction of the client; wherein the multiple proposal blocks are generated by multiple verification nodes in the nth consensus round by referencing a pre-proposal block, and the pre-proposal block is generated in the n-x1th consensus round.

[0056] Step S200: Take the post-proposal block as a certificate of the pre-proposal block, and consensus the pre-proposal block.

[0057] It should be noted that the blockchain system of the application includes multiple verification nodes, and the consensus method provided in the embodiments of the application is executed by the verification nodes. The verification nodes are nodes that are authenticated and authorized in the blockchain network, and they have the permission to participate in the consensus process, verify transactions and package blocks. Specifically, the tasks of the verification nodes include executing the consensus algorithm, as described in the above scheme, which will reference the proposal block in a specific consensus round, generate the post-proposal block, and participate in the consensus of the pre-proposal block. The verification nodes will also verify the transaction to ensure the legality, validity and compliance with the protocol rules of the blockchain. In addition, the verification nodes will package the legal transactions to generate new blocks according to the results of the consensus algorithm, and try to add these blocks to the blockchain.

[0058] It can be understood that the blockchain system usually sets a threshold, which requires a certain number of verification nodes to verify the same proposal block before the proposal block can be added to the blockchain. This process ensures that most of the verification nodes in the network reach a consensus on the content of the new block. In the traditional consensus process, if a verification node verifies a proposal block, it needs to sign and broadcast it to other verification nodes in the system, and other verification nodes need to verify the signature. Therefore, a large amount of signature information needs to be transmitted and verified in the consensus process.

[0059] In the consensus method provided in this application, if a validator node references a proposal block generated in a previous consensus round, it indicates that the validator node has already verified the proposal block. That is, in this application, reference relationships are used instead of signature messages in traditional consensus methods. Therefore, the consensus process no longer needs to transmit a large number of signature messages, but instead determines whether a proposal block has been verified by a sufficient number of validator nodes by checking reference relationships.

[0060] It should be noted that in this application, the determination of the citation relationship is based on successful verification. That is, a certain block needs to be verified to ensure that the content of the proposed block complies with the rules of the blockchain and the security requirements of the network. Only after the verification is successful can a citation relationship be established with it.

[0061] For example, validator nodes can verify the correctness of a proposed block by checking its signature, content, hash, and timestamp. For instance, a validator node can check the validity and legality of transaction data within the block, including ensuring the completeness of transaction fields and conformity to blockchain protocol rules. For each transaction, the validator node may also need to check the balance of inputs and outputs. Furthermore, a validator node can calculate the hash value of the proposed block and compare it with the hash value stored in the block header to ensure the block has not been tampered with during transmission. Alternatively, a validator node can check the validity of the timestamp in the proposed block; the timestamp records the time of block creation and can help the validator node detect potential double-spending or duplicate transactions.

[0062] Therefore, referencing a proposal block can also be understood as indicating acceptance of that proposal block. In the subsequent consensus process, the reference relationships between proposal blocks can be checked to determine whether a proposal block is referenced by a sufficient number of validator nodes. If the number of validator nodes referencing the proposal block meets a certain requirement, the proposal block can be considered to have received enough acceptance, meaning it is trustworthy.

[0063] Compared to traditional consensus methods, where each proposal block requires at least 2f+1 signatures, the number of signatures required for each block increases dramatically as the number of validators in the system grows. The consensus method provided in this application uses reference relationships to indicate acceptance of a proposal block, rather than using signatures to reach consensus on a proposal block. Therefore, a large number of signature messages no longer need to be transmitted during the consensus process, thus reducing the overhead of transmitting and verifying signature messages during the consensus process.

[0064] It should be noted that in step S100, the verification node also needs to combine the current transaction of the client when generating the post-proposal block. The transaction refers to a series of operations or requests initiated by a user (i.e., a client) on the blockchain network, which changes the state or data on the blockchain. These transactions may involve the invocation of a smart contract, the writing or updating of data, etc.

[0065] It should be noted that the implementation process of referencing the proposal block is based on a Directed Acyclic Graph (DAG), that is, the blockchain system is not just a simple linear structure, but adopts a more complex graph structure to organize and reference the proposal blocks.

[0066] In order to better understand the present application, first, a brief introduction to the Directed Acyclic Graph (DAG) is given. The Directed Acyclic Graph is a graph containing directional edges and no loops. In the blockchain system, the Directed Acyclic Graph can be used to represent the reference relationship between the proposal blocks, where each proposal block can point to one or more previous proposal blocks, forming a complex network structure.

[0067] Specifically, the blockchain system maintains a pre-stored Directed Acyclic Graph, which records all the proposal blocks and their reference relationships. When a verification node wants to reference a previous proposal block, it will query this pre-stored DAG to find the appropriate block for reference. The reference basis can be the age (i.e., the generation time) of the block, the number of transactions contained, the quality of the block, or other customized strategies.

[0068] When a verification node constructs a new proposal block, it will select one or more previous proposal blocks for reference according to the current transaction data and the reference relationship in the DAG. When the new proposal block is successfully added to the DAG and confirmed by other verification nodes in the network, the structure of the DAG will be updated accordingly to reflect the new reference relationship and the addition of the block.

[0069] Through the consensus method of referencing the proposal block by the Directed Acyclic Graph, the blockchain system can be more flexible and efficient when processing a large number of transactions and quickly generating blocks. Verification nodes can process multiple proposal blocks in parallel and find appropriate paths in the DAG to reach consensus, thereby improving the throughput and performance of the entire system.

[0070] In one possible implementation, x1 and x2 are the same or different, and each of x1 and x2 is equal to 1 or not equal to 1.

[0071] It should be noted that x1 can be 1 or a positive integer greater than 1, if x1 is 1, it means that the round in which the proposal block is generated and the round in which the preceding proposal block is generated are adjacent, if x1 is not 1, it means that the round in which the proposal block is generated and the round in which the preceding proposal block is generated are not adjacent. Similarly, x2 can also be 1 or a positive integer greater than 1, if x2 is 1, it means that the round in which the proposal block is generated and the round in which the subsequent proposal block is generated are adjacent, if x2 is not 1, it means that the round in which the proposal block is generated and the round in which the subsequent proposal block is generated are not adjacent.

[0072] The above is explained in specific embodiments as follows.

[0073] Embodiment 1: Referring to FIG. 2, in this embodiment, x1 = 1, x2 = 1, that is, in the n+1th consensus round, the proposal blocks An, Bn, Cn generated in the nth consensus round are referenced to generate the subsequent proposal block Bn+1, wherein the three proposal blocks An, Bn, Cn all reference the preceding proposal block Bn-1 generated in the n-1th consensus round, so the subsequent proposal block Bn+1 is taken as the certificate of the preceding proposal block Bn-1, for consensus of the preceding proposal block Bn-1.

[0074] Embodiment 2: Referring to FIG. 3, in this embodiment, x1 = 1, x2 ≠ 1, specifically, taking x2 equal to 2 as an example, in the n+2th consensus round, the proposal blocks An, Bn, Cn generated in the nth consensus round are referenced in an indirect way to generate the subsequent proposal block Bn+2, wherein the three proposal blocks An, Bn, Cn all reference the preceding proposal block Bn-1 generated in the n-1th consensus round, so the subsequent proposal block Bn+2 is taken as the certificate of the preceding proposal block Bn-1, for consensus of the preceding proposal block Bn-1.

[0075] It should be noted that since the blocks generated in the n+1th consensus round and the proposal blocks generated in the nth consensus round have a reference relationship, the subsequent proposal block Bn+2 can be indirectly referenced to the proposal blocks generated in the nth consensus round by referencing the blocks generated in the n+1th consensus round.

[0076] For example, since the block An+1 has a reference relationship with the proposal block An, the subsequent proposal block Bn+2 can realize the reference to the proposal block An by referencing the block An+1. Similarly, since the block Cn+1 has a reference relationship with the proposal block Bn, the subsequent proposal block Bn+2 can realize the reference to the proposal block Bn by referencing the block Cn+1. Similarly, since the block Dn+1 has a reference relationship with the proposal block Cn, the subsequent proposal block Bn+2 can realize the reference to the proposal block Cn by referencing the block Dn+1.

[0077] In this embodiment, xi≠1, x2=1, and specifically, xi is equal to 2, that is, in the (n+1)th consensus round, the proposal blocks An, Bn, Cn generated in the nth consensus round are referenced to generate the post-proposal block Bn+1, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Bn-2 generated in the (n-2)th consensus round through indirect reference, and therefore the post-proposal block Bn+1 is taken as the certificate of the pre-proposal block Bn-2, for consensus of the pre-proposal block Bn-2.

[0078] It should be noted that since the block generated in the (n-1)th consensus round has a reference relationship with the pre-proposal block generated in the (n-2)th consensus round, the proposal block can indirectly reference the pre-proposal block generated in the (n-2)th consensus round by referencing the block generated in the (n-1)th consensus round.

[0079] For example, since the block An-1 has a reference relationship with the pre-proposal block Bn-2, the proposal block An can reference the pre-proposal block Bn-2 by referencing the block An-1. Similarly, since the block Bn-1 has a reference relationship with the pre-proposal block Bn-2, the proposal block Cn can reference the pre-proposal block Bn-2 by referencing the block Bn-1. Similarly, since the block Cn-1 has a reference relationship with the pre-proposal block Bn-2, the proposal block Dn can reference the pre-proposal block Bn-2 by referencing the block Cn-1.

[0080] It should be noted that from the above embodiments, it can be seen that the reference includes direct reference and indirect reference. The direct reference is to reference a block generated in the last round, for example, in FIG. 3, the block An references the block Bn-1, the block Bn+2 references the block Cn+1, or the block An+1 references the block An. The indirect reference is to reference a proposal block generated in non-adjacent rounds, for example, in FIG. 3, the block Bn+2 references the block An, that is, the block Bn+2 indirectly references the block An through the block An+1.

[0081] In a possible implementation, the multiple verification nodes correspondingly generate a proposal block by referencing a pre-proposal block, including:

[0082] The verification node corresponds with other verification nodes to correspondingly generate a proposal block by referencing a pre-proposal block.

[0083] It should be noted that in the nth consensus round, the process of referencing a pre-proposal block to generate a proposal block can or can not include the verification node.

[0084] The above is illustrated by Embodiment 1 and Embodiment 3. As shown in the schematic diagram of Embodiment 1 in FIG. 2, in the n th consensus round, the validator node (Validator B) participates in the generation of the proposal block, that is, Validator B generates the proposal block Bn by referencing the previous proposal block Bn-1 in the n th consensus round. In Embodiment 3 shown in FIG. 4, in the n th consensus round, the validator node (Validator B) does not participate in the generation of the proposal block, that is, Validator B does not generate the proposal block Bn by referencing the previous proposal block in the n th consensus round.

[0085] Therefore, in the embodiments of the present application, the execution subject of the process of referencing a previous proposal block to generate a proposal block can or can not include the validator node.

[0086] In a possible implementation, the step of referencing any one proposal block includes referencing a hash index of the any one proposal block, wherein the any one proposal block is one of the proposal block and the previous proposal block.

[0087] It should be noted that a proposal block includes a transaction list, a current consensus round, a proposal signer, a proposal signature, and a reference relationship with a proposal block generated in a previous round. As shown in FIG. 5, each proposal block includes a transaction list transactions, a current consensus round round, a proposal signer author, a proposal signature signature, and a reference relationship with a proposal block in a previous round parents.

[0088] In a possible implementation, the hash index can be generated according to the current consensus round, the proposal signer, the transaction list, and the reference relationship. As shown in FIG. 5, in the illustrated case, the hash index includes h1, h2, and h3, wherein h1 is calculated by a hash function according to the current consensus round r, the proposal signer v1, the transaction list txs1, and the reference relationship p1; h2 is calculated by a hash function according to the current consensus round r, the proposal signer v2, the transaction list txs2, and the reference relationship p2; and h3 is calculated by a hash function according to the current consensus round r, the proposal signer v3, the transaction list txs3, and the reference relationship p3.

[0089] It should be noted that the basis for the reference is that the proposal block has been verified, including verification of the correspondence between the proposal block signer and the signature, and verification of the correctness of the reference relationship.

[0090] Specifically, the correspondence between the proposer of the block and the signature needs to be verified. The present application performs consensus through multiple consensus rounds, and each honest verifier node broadcasts its unique proposer block signature in each consensus round to other verifier nodes to prove that the block is indeed generated by it. The verifier node checks whether the signature matches the proposer and whether the signature is valid (not tampered or forged), so as to prevent malicious nodes from forging blocks or tampering with transactions.

[0091] In addition, the correctness of the reference relationship also needs to be verified. Since each proposer block references several (no less than the statutory number) proposer blocks, the verifier node needs to check whether the hash value of the referenced proposer block is correct to ensure the integrity and continuity of the block chain.

[0092] In addition, when generating the post-proposer block, the current transaction of the client also needs to be combined, and the transaction also needs to be verified. Specifically, the transaction list of the current transaction can be verified, including verifying the validity of each transaction, the identity of the sender and the receiver, and whether the transaction amount is correct, etc., to ensure that only legal and valid transactions can be added to the block chain.

[0093] In a possible implementation, the pre-proposer block is generated by the present verifier node, or the pre-proposer block is generated by other verifier nodes.

[0094] It should be noted that in the above embodiment 1, embodiment 2 and embodiment 3, the pre-proposer block and the post-proposer block are generated by the same verifier. In some possible implementations, the pre-proposer block and the post-proposer block can also be generated by different verifiers corresponding to the above three cases. The following specific embodiments are explained.

[0095] Embodiment 4: Referring to FIG. 6, in the present embodiment, x1 = 1, x2 = 1, and the pre-proposer block and the post-proposer block are generated by different verifier nodes.

[0096] It should be noted that the difference between the present embodiment and embodiment 1 is that the pre-proposer block and the post-proposer block are generated by different verifier nodes. In embodiment 1, the pre-proposer block Bn-1 and the post-proposer block Bn+1 are generated by the verifier node Validator B, while in embodiment 4, the pre-proposer block Dn-1 is generated by the verifier node Validator D, and the post-proposer block Bn+1 is generated by the verifier node Validator B.

[0097] Specifically, in the n+1thconsensus round, the proposal blocks An, Bn, Cn generated in the nthconsensus round are referenced to generate the post-proposal block Bn+1, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Dn-1 generated in the n-1thconsensus round, and the post-proposal block Bn+1 is taken as a certificate of the pre-proposal block Dn-1, for consensus of the pre-proposal block Dn-1.

[0098] In this embodiment, x1=1, x2≠1, and the pre-proposal block and the post-proposal block are generated by different verification nodes.

[0099] It should be noted that the difference between this embodiment and embodiment 2 is that the pre-proposal block and the post-proposal block are generated by different verification nodes. In embodiment 2, the pre-proposal block Bn-1 and the post-proposal block Bn+1 are both generated by the verification node Validator B, while in embodiment 5, the pre-proposal block Cn-1 is generated by the verification node Validator C, and the post-proposal block Bn+2 is generated by the verification node Validator B.

[0100] Specifically, in the n+2thconsensus round, the proposal blocks An, Bn, Cn generated in the nthconsensus round are referenced in an indirect manner to generate the post-proposal block Bn+2, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Cn-1 generated in the n-1thconsensus round, and the post-proposal block Bn+2 is taken as a certificate of the pre-proposal block Cn-1, for consensus of the pre-proposal block Cn-1.

[0101] In this embodiment, x1≠1, x2=1, and the pre-proposal block and the post-proposal block are generated by different verification nodes.

[0102] It should be noted that the difference between this embodiment and embodiment 3 is that the pre-proposal block and the post-proposal block are generated by different verification nodes. In embodiment 3, the pre-proposal block Bn-2 and the post-proposal block Bn+1 are both generated by the verification node Validator B, while in embodiment 6, the pre-proposal block Dn-2 is generated by the verification node Validator D, and the post-proposal block Bn+1 is generated by the verification node Validator B.

[0103] Specifically, in the n+1th consensus round, the proposal blocks An, Bn, Cn generated in the nth consensus round are cited to generate a post-proposal block Bn+1, wherein the three proposal blocks An, Bn, Cn all cite the pre-proposal block Dn-2 generated in the n-2th consensus round by means of indirect citation, and the post-proposal block Bn+1 is taken as a certificate of the pre-proposal block Dn-2, so as to consensus the pre-proposal block Dn-2.

[0104] In a possible implementation, taking the post-proposal block as the certificate of the pre-proposal block comprises: taking the post-proposal block as the certificate of the pre-proposal block independently by each of the at least one verification node, wherein if the number of certificates is greater than a preset threshold, the pre-proposal block is verified to be passed.

[0105] It should be noted that the certificate represents the confirmation and acceptance of the to-be-submitted proposal block by the verification node. Each verification node can generate a certificate for one or more to-be-submitted proposal blocks, and the certificates are accumulated to form a quantitative indicator of the acceptance degree of a proposal block. In order to ensure the stability and security of the blockchain, only when the number of certificates of the to-be-submitted proposal block reaches or exceeds a preset value, the proposal block is determined to have been sufficiently supported, and thus is submitted to the target blockchain.

[0106] It should also be noted that the preset number of certificates can be adjusted according to the specific situation of the blockchain network. For example, in the case of a small blockchain network or a small number of verification nodes, the preset number of certificates can be appropriately reduced; and in the case of a large blockchain network or a large number of verification nodes, the preset number of certificates can be appropriately increased.

[0107] In the embodiments of the present application, for the same pre-proposal block, there can be multiple post-proposal blocks as its certificates, and the multiple certificates can be generated by different verification nodes in the same consensus round, or generated by the same verification node in different rounds. The following will be described through specific embodiments.

[0108] Embodiment 7: Referring to FIG. 9, in this embodiment, for the pre-proposal block Bn-1 generated by Validator B in the n-1th consensus round, there are two certificates generated by Validator B and Validator D in the n+1th consensus round.

[0109] Specifically, the verification node Validator B references the proposal blocks An, Bn, Cn generated in the n-th consensus round to generate a post-proposal block Bn+1 in the n+1-th consensus round, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Bn-1 generated in the n-1-th consensus round, so that the post-proposal block Bn+1 is taken as a certificate of the pre-proposal block Bn-1 for consensus of the pre-proposal block Bn-1. Meanwhile, the verification node Validator D also references the proposal blocks An, Bn, Cn generated in the n-th consensus round to generate a post-proposal block Dn+1 in the n+1-th consensus round, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Bn-1 generated in the n-1-th consensus round, so that the post-proposal block Dn+1 is taken as a certificate of the pre-proposal block Bn-1 for consensus of the pre-proposal block Bn-1.

[0110] It should be noted that in Embodiment 7, the post-proposal block Dn+1 generated by the Validator D and the post-proposal block Bn+1 generated by the Validator B can both be taken as a certificate of the pre-proposal block Bn-1 for consensus of the pre-proposal block Bn-1.

[0111] In the above embodiments, one pre-proposal block has multiple post-proposal blocks as its certificates, and the multiple post-proposal blocks as the certificates are all generated in the same consensus round. It should be noted that in some possible embodiments, the multiple post-proposal blocks as the certificates can be generated in different consensus rounds, which will be described below through Embodiment 8.

[0112] Embodiment 8: Referring to FIG. 10, in this embodiment, the verification node Validator B references the proposal blocks An, Bn, Cn generated in the n-th consensus round to generate a post-proposal block Bn+1 in the n+1-th consensus round, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Cn-1 generated in the n-1-th consensus round, so that the post-proposal block Bn+1 is taken as a certificate of the pre-proposal block Cn-1 for consensus of the pre-proposal block Bn-1.

[0113] Meanwhile, the verification node Validator B references the proposal blocks An, Bn, Cn generated in the n-th consensus round to generate a post-proposal block Bn+2 in the n+2-th consensus round by means of indirect reference, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Cn-1 generated in the n-1-th consensus round, so that the post-proposal block Bn+2 can also be taken as a certificate of the pre-proposal block Cn-1 for consensus of the pre-proposal block Cn-1.

[0114] Therefore, in this embodiment, the post-proposal block Bn+1 and the post-proposal block Bn+2 are both certificates of the pre-proposal block Cn-1, and the post-proposal block Bn+1 and the post-proposal block Bn+2 are generated in different consensus rounds.

[0115] In the above embodiment 8, the two post-proposal blocks as certificates are generated in different rounds, but are both generated by the same verification node Validator B. It should be noted that in some possible embodiments, the multiple post-proposal blocks as certificates can also be generated by different verification nodes in different consensus rounds. This is illustrated below by means of embodiment 9.

[0116] Referring to FIG. 11, in embodiment 9, the verification node Validator D references the proposal blocks An, Bn, Cn generated in the n-th consensus round to generate a post-proposal block Dn+1 in the n+1-th consensus round, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Cn-1 generated in the n-1-th consensus round, so that the post-proposal block Dn+1 is taken as a certificate of the pre-proposal block Cn-1, for consensus of the pre-proposal block Cn-1.

[0117] Meanwhile, the verification node Validator B references the proposal blocks An, Bn, Cn generated in the n-th consensus round to generate a post-proposal block Bn+2 in the n+2-th consensus round by means of indirect reference, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Cn-1 generated in the n-1-th consensus round, so that the post-proposal block Bn+2 can also be taken as a certificate of the pre-proposal block Cn-1, for consensus of the pre-proposal block Cn-1.

[0118] Therefore, in this embodiment, the post-proposal block Dn+1 and the post-proposal block Bn+2 are both certificates of the pre-proposal block Cn-1, and the post-proposal block Dn+1 and the post-proposal block Bn+2 are generated in different consensus rounds by different verification nodes.

[0119] It should also be noted that in some possible embodiments, the same post-proposal block can also simultaneously serve as a certificate of multiple pre-proposal blocks. This is illustrated below by means of embodiment 10.

[0120] Referring to FIG. 12, in embodiment 10, the pre-proposal blocks include Bn-1 and Dn-1, and according to the reference relationship shown in the figure, the post-proposal block Bn+1 can serve as a certificate of the pre-proposal block including Bn-1, or can serve as a certificate of the pre-proposal block including Dn-1.

[0121] Specifically, in the n+1th consensus round, the validator node Validator B references the proposal blocks An, Bn, Cn generated in the nth consensus round to generate a post-proposal block Bn+1, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Dn-1 generated in the n-1th consensus round, so that the post-proposal block Bn+1 is taken as a certificate of the pre-proposal block Dn-1, for consensus of the pre-proposal block Dn-1. Moreover, the proposal blocks An, Bn, Cn all reference the pre-proposal block Bn-1 generated in the n-1th consensus round, so that the post-proposal block Bn+1 can also be taken as a certificate of the pre-proposal block Bn-1, for consensus of the pre-proposal block Bn-1. Therefore, in this embodiment, the post-proposal block Bn+1 simultaneously serves as a certificate of the pre-proposal block Bn-1 and the pre-proposal block Dn-1.

[0122] It should be noted that, for the case that one post-proposal block serves as multiple pre-proposal blocks, the pre-proposal block and the post-proposal block must still be generated by the same validator node. This case will be described below in Embodiment 11.

[0123] Referring to FIG. 13, in the n+1th consensus round, the validator node Validator B references the proposal blocks An, Bn, Cn generated in the nth consensus round to generate a post-proposal block Bn+1, wherein the three proposal blocks An, Bn, Cn all reference the pre-proposal block Dn-1 generated in the n-1th consensus round, so that the post-proposal block Bn+1 is taken as a certificate of the pre-proposal block Dn-1, for consensus of the pre-proposal block Dn-1. Moreover, the proposal blocks An, Bn, Cn all reference the pre-proposal block An-1 generated in the n-1th consensus round, so that the post-proposal block Bn+1 can also be taken as a certificate of the pre-proposal block An-1, for consensus of the pre-proposal block An-1. Therefore, in this embodiment, the post-proposal block Bn+1 simultaneously serves as a certificate of the pre-proposal block An-1 and the pre-proposal block Dn-1.

[0124] In a possible implementation, the number of the proposal blocks is not less than 2f+1, where f is the number of dishonest validator nodes in the nth consensus round, and 3f+1 is the total number of validator nodes in the nth consensus round.

[0125] It should be noted that the post-proposal block needs to meet certain conditions to be used as a certificate of the pre-proposal block, that is, the number of proposal blocks referenced by the post-proposal block needs to meet the condition of 2f+1, which is based on the Byzantine Fault Tolerant algorithm, which is a fault-tolerant algorithm for Byzantine problems, and solves the problem of how to reach consensus in the case of reliable network communication but node failure and sabotage. Its core theory is that the total number of nodes in the system is greater than or equal to 3f+1, f is the number of nodes allowed to fail, in other words, for a certain proposal block, only if a statutory number (not less than 2f+1) of verification nodes verify the block, the correctness of the proposal block can be ensured. Therefore, the embodiment of the present application requires that the number of proposal blocks referenced by the pre-proposal block generated by the pre-proposal block is not less than 2f+1.

[0126] In addition, for the check of the reference relationship, a depth-first traversal method can be used, and a post-proposal block in the nth+x2 consensus round is taken as a starting point, and the proposal blocks having a reference relationship with the post-proposal block are preferentially traversed, so as to determine whether a pre-proposal block is supported by a sufficient number of verification nodes through the reference relationship.

[0127] Depth-first traversal is an algorithm for traversing or searching a tree / graph, and in the embodiment of the present application, the directed acyclic graph can be traversed, that is, if a post-proposal block references a proposal block in a previous round, the post-proposal block is taken as a starting point, and a depth-first traversal (Depth-First Search, DFS) method is used to track and verify the referenced blocks.

[0128] The traversal process will be described in combination with the principle of depth-first traversal. The verification node takes the post-proposal block generated in the nth+x2 consensus round as a starting point, and then selects the first neighbor node. Since the current block references one or more previous blocks, the verification node will first select these referenced blocks as the first neighbor node for traversal. Then, for each referenced block (neighbor node), the verification node will check whether the block references other blocks, and if so, the verification node will recursively continue to traverse these referenced blocks until there are no more referenced blocks. Then, when the verification node traverses all the blocks in a branch, it will backtrack to the previous node and continue to traverse other untraversed neighbor nodes of the node. When the verification node traverses all reachable blocks or reaches a certain preset termination condition (such as a traversal depth limit, a time limit, etc.), the traversal process ends. In this way, it can be determined whether a pre-proposal block is supported by a sufficient number of verification nodes.

[0129] The consensus device 400 of the blockchain system provided in the embodiments of the present application, referring to FIG. 14, comprises:

[0130] The post-proposal block generation module 401 is configured to reference a plurality of proposal blocks in the n+x2th consensus round, and generate a post-proposal block in combination with the current transaction of the client; wherein the plurality of proposal blocks are generated in the nth consensus round by a plurality of verification nodes referencing a pre-proposal block, and the pre-proposal block is generated in the n-x1th consensus round;

[0131] The consensus module 402 is configured to use the post-proposal block as a certificate of the pre-proposal block to consensus the pre-proposal block.

[0132] It should be noted that the consensus device 400 provided in the present application uses a reference relationship to replace the signature message in the traditional consensus method, that is, if the post-proposal block references a plurality of proposal blocks, and the plurality of proposal blocks all reference a pre-proposal block, the post-proposal block can be used as a certificate of the pre-proposal block, and the formula process is completed according to the certificate. Therefore, in the process of realizing consensus by using the consensus device 400 provided in the present application, a large number of signature messages do not need to be transmitted, but the reference relationship can be used to determine whether a pre-proposal block is verified by a sufficient number of verification nodes. In this way, the overhead of transmitting and verifying signature messages in the consensus process is reduced.

[0133] Based on the same inventive concept, in a possible implementation, x1 and x2 are the same or different, and each of x1 and x2 is equal to 1 or is not equal to 1.

[0134] It should be noted that x1 can be 1 or a positive integer greater than 1, if x1 is 1, it means that the round in which the proposal block is generated and the round in which the pre-proposal block is generated are adjacent, if x1 is not 1, it means that the round in which the proposal block is generated and the round in which the pre-proposal block is generated are not adjacent. Similarly, x2 can also be 1 or a positive integer greater than 1, if x2 is 1, it means that the round in which the proposal block is generated and the round in which the post-proposal block is generated are adjacent, if x2 is not 1, it means that the round in which the proposal block is generated and the round in which the post-proposal block is generated are not adjacent.

[0135] Based on the same inventive concept, the verification node is configured to generate a proposal block corresponding to a pre-proposal block together with other verification nodes.

[0136] It should be noted that in the n th consensus round, the process of referencing a pre-proposal block to generate a proposal block can or can not include the verification node.

[0137] Based on the same inventive concept, the post-proposal block generation module is specifically configured to cite a hash index of the arbitrary proposal block, wherein the arbitrary proposal block is one of the proposal block and the pre-proposal block.

[0138] It should be noted that the proposal block contains a transaction list, a current consensus round, a proposal signer, a proposal signature, and a citation relationship with a proposal block generated in a previous round. Referring to FIG. 5, each proposal block contains a transaction list transactions, a current consensus round round, a proposal signer author, a proposal signature signature, and a citation relationship with a proposal block in a previous round parents.

[0139] In a possible implementation, the hash index can be generated according to the current consensus round, the proposal signer, the transaction list, and the citation relationship. Referring to FIG. 5, in the illustrated case, the hash index includes h1, h2, and h3, wherein h1 is calculated by a hash function according to the current consensus round r, the proposal signer v1, the transaction list txs1, and the citation relationship p1; h2 is calculated by a hash function according to the current consensus round r, the proposal signer v2, the transaction list txs2, and the citation relationship p2; and h3 is calculated by a hash function according to the current consensus round r, the proposal signer v3, the transaction list txs3, and the citation relationship p3.

[0140] Based on the same inventive concept, the pre-proposal block is generated by the current verification node, or the pre-proposal block is generated by another verification node.

[0141] It should be noted that in the above embodiment 1, embodiment 2, and embodiment 3, the pre-proposal block and the post-proposal block are generated by the same verifier. In some possible implementations, corresponding to the above three cases, the pre-proposal block and the post-proposal block can also be generated by different verifiers. The following specific embodiments are explained.

[0142] Based on the same inventive concept, the consensus module is specifically configured to independently generate, together with at least one other verification node, a post-proposal block, and each independently take the post-proposal block as a certificate of the pre-proposal block, wherein if the number of certificates is greater than a preset threshold, the pre-proposal block is verified.

[0143] It should be noted that the certificate represents the confirmation and acceptance of the to-be-submitted proposal block by the verification node. Each verification node can generate a certificate for one or more to-be-submitted proposal blocks, and the certificates accumulate to form a quantitative indicator of the degree of acceptance of a proposal block. In order to ensure the stability and security of the blockchain, only when the number of certificates of the to-be-submitted proposal block reaches or exceeds the preset value, the proposal block will be determined to have been sufficiently supported, and thus submitted to the target blockchain.

[0144] It should also be noted that the preset number of certificates can be adjusted according to the specific circumstances of the blockchain network. For example, in the case of a small-scale blockchain network or a small number of verification nodes, the preset number of certificates can be appropriately reduced; while in the case of a large-scale blockchain network or a large number of verification nodes, the preset number of certificates can be appropriately increased.

[0145] In the embodiments of the present application, for the same pre-proposal block, there can be multiple post-proposal blocks as its certificates, and the multiple certificates can be generated by different verification nodes in the same consensus round, or by the same verification node in different rounds.

[0146] Based on the same inventive concept, the number of proposal blocks is not less than 2f+1, where f is the number of dishonest verification nodes in the nth consensus round, and 3f+1 is the total number of verification nodes in the nth consensus round.

[0147] It should be noted that the post-proposal block as the certificate of the pre-proposal block needs to meet certain conditions, i.e., the number of proposal blocks referenced by the post-proposal block needs to meet the condition of 2f+1, which is based on the Byzantine Fault Tolerant algorithm. The Byzantine Fault Tolerant algorithm is a fault-tolerant algorithm for the Byzantine problem, which solves the problem of how to reach consensus in the case of reliable network communication but possible node failure and malice. Its core theory is that the total number of nodes in the system is greater than or equal to 3f+1, f is the number of nodes allowed to fail, in other words, for a certain proposal block, only if the number of verification nodes that pass the block is not less than 2f+1, the correctness of the proposal block can be guaranteed. Therefore, the embodiments of the present application require that for a pre-proposal block, the number of proposal blocks referenced by it should not be less than 2f+1.

[0148] In addition, for the checking of the reference relationship, a depth-first traversal method can be used, taking a post-proposal block in the nth+x2 consensus round as the starting point, and preferentially traversing the proposal blocks that have a reference relationship with it, to determine whether a pre-proposal block is supported by a sufficient number of verification nodes through the reference relationship.

[0149] FIG. 15 is a structural schematic diagram of a terminal device provided in an embodiment of the present application. The terminal device 1000 comprises at least one processor 1001 (only one processor is shown in FIG. 15), a memory 1002, and a computer program 1003 stored in the memory 1002 and executable on the at least one processor 1001, wherein the processor 1001 implements the steps in the above-mentioned method embodiments of the present application when executing the computer program 1003.

[0150] The terminal device 1000 can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The terminal device can comprise, but is not limited to, the processor 1001 and the memory 1002. Those skilled in the art can understand that FIG. 15 is only an example of the terminal device 1000, and does not constitute a limitation on the terminal device 1000, and can comprise more or fewer components than those shown, or combine certain components, or different components, for example, can also comprise an input / output device, a network access device, and the like.

[0151] The processor 1001 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic components, discrete hardware components, or the like. The general-purpose processor can be a microprocessor or can also be any conventional processor.

[0152] The memory 1002 may, in some embodiments, be an internal storage unit of the terminal device 1000, such as a hard disk or a memory of the terminal device 1000. The memory 1002 may, in other embodiments, also be an external storage device of the terminal device 1000, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, and the like equipped on the terminal device 1000. Further, the memory 1002 may, for example, include both an internal storage unit and an external storage device of the terminal device 1000. The memory 1002 is used to store an operating system, an application program, a boot loader, data, and other programs, and the like, such as program codes of the computer program, and the like. The memory 1002 may also be used to temporarily store data that has been output or is to be output.

[0153] It can be clearly understood by those skilled in the art that, for the convenience and brevity of description, only the division of the above functional units and modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically independently, or two or more units can be integrated in one unit, and the integrated unit can be realized in the form of hardware or in the form of a software functional unit. In addition, the specific names of the functional units and modules are only for the convenience of mutual distinction, and are not used to limit the protection scope of the present application. The specific working process of the units and modules in the system can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0154] The embodiment of the present application further provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in each of the method embodiments.

[0155] The embodiment of the present application provides a computer program product, when the computer program product is run on a mobile terminal, so that the mobile terminal is enabled to implement the steps in each of the method embodiments.

[0156] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the present application can implement all or part of the processes in the above-mentioned embodiment methods through a computer program to instruct relevant hardware to complete, and the computer program can be stored in a computer readable storage medium. When the computer program is executed by a processor, the steps of each method embodiment described above can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms. The computer readable medium at least includes any entity or device capable of carrying the computer program code to the photographing device / terminal equipment, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium. For example, U disk, mobile hard disk, magnetic disk or optical disk, etc. In some jurisdictions, according to legislation and patent practice, the computer readable medium can not be an electrical carrier signal and a telecommunication signal.

[0157] In the above embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0158] Those of ordinary skill in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0159] In the embodiments provided by the present application, it should be understood that the disclosed apparatus / network device and method can be implemented in other ways. For example, the above-described apparatus / network device embodiments are merely schematic, for example, the division of the modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed each other can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0160] The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may also be distributed to multiple network units. Part or all of the units can be selected to achieve the purpose of the embodiment scheme according to actual needs.

[0161] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A consensus method of a blockchain system, characterized in that, The blockchain system comprises a plurality of verification nodes, the consensus method is executed by a verification node, and the consensus method comprises: In the n+x2th consensus round, a post-proposal block is generated by referencing a plurality of proposal blocks and combining the current transaction of the client; wherein the plurality of proposal blocks are generated by a plurality of verification nodes referencing a pre-proposal block in the nth consensus round, and the pre-proposal block is generated in the n-x1th consensus round; The post-proposal block is used as a certificate of the pre-proposal block to consensus the pre-proposal block.

2. The consensus method of claim 1, wherein, x1 and x2 are the same or different, and each of x1 and x2 is equal to 1 or not equal to 1.

3. The consensus method of claim 1, wherein, The step of referencing any one of the proposal blocks comprises: referencing a hash index of the any one of the proposal blocks, wherein the any one of the proposal blocks is one of the proposal blocks and the pre-proposal block. The pre-proposal block is generated by the verification node or the pre-proposal block is generated by other verification nodes.

4. The consensus method of claim 1, wherein, The number of the proposal blocks is not less than 2f+1, wherein f is the number of dishonest verification nodes in the n th consensus round, and 3f+1 is the total number of verification nodes in the n th consensus round.

5. The consensus method of claim 1, wherein, The terminal device is any verification node of a plurality of verification nodes included in a blockchain system; and the processor, when executing the computer program, implements the following steps:

6. The consensus method of claim 1, wherein, In the n+x2th consensus round, a post-proposal block is generated by referencing a plurality of proposal blocks and combining the current transaction of the client; wherein the plurality of proposal blocks are generated by a plurality of verification nodes referencing a pre-proposal block in the nth consensus round, and the pre-proposal block is generated in the n-x1th consensus round; The post-proposal block is used as a certificate of the pre-proposal block to consensus the pre-proposal block.

7. The consensus method of claim 1, wherein, x1 and x2 are the same or different, and each of x1 and x2 is equal to 1 or not equal to 1. 8.A consensus device of a blockchain system, characterized in that, The step of referencing any one of the proposal blocks comprises: referencing a hash index of the any one of the proposal blocks, wherein the any one of the proposal blocks is one of the proposal blocks and the pre-proposal block. The pre-proposal block is generated by the verification node or the pre-proposal block is generated by other verification nodes. The number of the proposal blocks is not less than 2f+1, wherein f is the number of dishonest verification nodes in the n th consensus round, and 3f+1 is the total number of verification nodes in the n th consensus round.

9. The consensus device of claim 8, wherein, The terminal device is any verification node of a plurality of verification nodes included in a blockchain system; and the processor, when executing the computer program, implements the following steps:

10. The consensus device of claim 8, wherein, ​ 11. The consensus device of claim 8, wherein, ​ 12. The consensus device of claim 8, wherein, ​ 13. A terminal device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, ​ In the n+x2th consensus round, a post-proposal block is generated by referencing multiple proposal blocks and combining the current transaction of the client; wherein the multiple proposal blocks are generated by referencing a pre-proposal block in the nth consensus round, and the pre-proposal block is generated in the n-x1th consensus round; The post-proposal block is used as a certificate of the pre-proposal block to consensus the pre-proposal block.

14. The terminal device according to claim 13, characterized by x1 and x2 are the same or different, and each of x1 and x2 is equal to 1 or not equal to 1.

15. The terminal device according to claim 13, characterized by The multiple verification nodes correspond to generate the proposal block by referencing the pre-proposal block, including: The current verification node corresponds to generate the proposal block by referencing the pre-proposal block together with other verification nodes.

16. The terminal device according to claim 13, wherein The step of referencing any one proposal block includes referencing the hash index of the any one proposal block, wherein the any one proposal block is one of the proposal block and the pre-proposal block.

17. The terminal device according to claim 13, characterized by The pre-proposal block is generated by the current verification node or the pre-proposal block is generated by other verification nodes.

18. The terminal device according to claim 13, characterized by The post-proposal block is used as a certificate of the pre-proposal block, including: The post-proposal block is used as a certificate of the pre-proposal block by each of the at least one verification node independently, wherein if the number of certificates is greater than a preset threshold, the pre-proposal block is verified.

19. The terminal device according to claim 13, characterized by The number of the proposal blocks is not less than 2f+1, wherein f is the number of dishonest verification nodes in the n th consensus round, and 3f+1 is the total number of verification nodes in the n th consensus round.

20. A computer-readable storage medium, the computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to realize the steps of the consensus method according to any one of claims 1 to 7. The computer program is executed by the processor to realize the steps of the consensus method according to any one of claims 1 to 7.

Images