A consensus method, system and consensus node

Abstract

A consensus method, system, and consensus node. The method includes: determining a consensus node within a consensus group initiating a consensus proposal in a current round of consensus based on a random number from a previous round, the determined consensus node initiating the consensus proposal; each consensus node within the consensus node group signing the consensus proposal using its own first private key share in a threshold signature algorithm to generate a first signature share, and broadcasting the first signature share to other consensus nodes within the consensus group; consensus nodes that have collected a threshold number of first signature shares using a first recovery function in the threshold signature algorithm to recover a first aggregate signature, and broadcasting the first aggregate signature and the corresponding first aggregate public key to a blockchain network; blockchain nodes that have received the first aggregate signature and the first aggregate public key verifying the first aggregate signature using the first aggregate public key, and upon successful verification, determining the consensus proposal corresponding to the first aggregate signature as the current consensus result.

Description

Technical Field

[0001] The embodiments of this specification belong to the field of blockchain technology, and in particular to a consensus method, system, and consensus node. Background Art

[0002] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application. Summary of the Invention

[0003] The purpose of the present invention is to provide a consensus method, system and consensus node, including:

[0004] A method for achieving consensus on a blockchain, comprising:

[0005] Determine the consensus node that initiates the consensus proposal within the consensus group in this round of consensus based on the random number of the previous round, and the determined consensus node initiates the consensus proposal;

[0006] Each consensus node in the consensus node group uses its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0007] The consensus node that has collected the threshold number of first signature shares uses the first recovery function in the threshold signature algorithm to recover the first aggregate signature, and broadcasts the first aggregate signature and the corresponding first aggregate public key to the blockchain network;

[0008] The blockchain node that receives the first aggregate signature and the first aggregate public key uses the first aggregate public key to verify the first aggregate signature. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0009] A method for achieving consensus on a blockchain, the method being executed by a consensus node of a consensus group in a current round, the method comprising:

[0010] Determine the consensus node that initiates the consensus proposal within the consensus group in this round of consensus based on the random number of the previous round;

[0011] Sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0012] After collecting the threshold number of first signature shares, the first recovery function in the threshold signature algorithm is used to recover the first aggregate signature, and the first aggregate signature and the corresponding first aggregate public key are broadcast to the blockchain network;

[0013] After receiving the first aggregate signature and the first aggregate public key, the first aggregate signature is verified using the first aggregate public key. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0014] A blockchain system includes several consensus groups, each of which includes several consensus nodes, where:

[0015] The consensus nodes in the consensus group executing the consensus in this round each determine the consensus node that initiates the consensus proposal in the consensus group in this round based on the random number of the previous round;

[0016] The determined consensus node initiates a consensus proposal;

[0017] Each consensus node in the consensus group executing consensus in this round uses its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0018] The consensus node that has collected the threshold number of first signature shares uses the first recovery function in the threshold signature algorithm to recover the first aggregate signature, and broadcasts the first aggregate signature and the corresponding first aggregate public key to the blockchain network;

[0019] The blockchain node that receives the first aggregate signature and the first aggregate public key in the blockchain network uses the first aggregate public key to verify the first aggregate signature. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0020] A first consensus node in a blockchain system, wherein the first consensus node is a consensus node of a consensus group in this round, wherein the first consensus node performs:

[0021] Determine the consensus node that initiates the consensus proposal within the consensus group in this round of consensus based on the random number of the previous round;

[0022] Sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0023] After collecting the threshold number of first signature shares, the first recovery function in the threshold signature algorithm is used to recover the first aggregate signature, and the first aggregate signature and the corresponding first aggregate public key are broadcast to the blockchain network;

[0024] After receiving the first aggregate signature and the first aggregate public key, the first aggregate signature is verified using the first aggregate public key. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0025] A truly randomly generated consensus proposal node means its selection cannot be known in advance. This probabilistically guarantees the security of the blockchain's public disclosure system, especially when the number of nodes is large. Through this approach, the consensus node initiating consensus proposals can be changed based on the random number in each consensus round. This makes the rotation of consensus proposal nodes less fixed and less predictable, thereby reducing the probability of consensus proposal nodes being attacked. Furthermore, the consensus group executing consensus can be changed based on the random number, and the corresponding consensus proposal node will also be changed to a consensus node within the consensus group executing consensus, further reducing the probability of consensus proposal nodes being attacked. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0027] Figure 1 is a schematic diagram of the conventional phase of a practical Byzantine fault tolerance algorithm in one embodiment;

[0028] Figure 2 This is a schematic diagram of the view switching phase of a practical Byzantine fault tolerance algorithm in one embodiment;

[0029] Figure 3 This is a schematic diagram of a conventional phase of a practical Byzantine fault tolerance algorithm in an embodiment when no consensus nodes are down;

[0030] Figure 4 This is a flow chart of a method for achieving consensus on a blockchain in an embodiment of this specification;

[0031] Figure 5 is a schematic diagram of generating random numbers in one embodiment of this specification;

[0032] Figure 6 This is a flow chart of a method for generating public-private key pairs and aggregated public keys using the DKG protocol in one embodiment of this specification. DETAILED DESCRIPTION

[0033] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0034] The Blockchain 1.0 era generally refers to the period between 2009 and 2014, a period of blockchain application development focused on addressing the decentralization of currency and payment methods. Starting in 2014, developers increasingly focused on addressing blockchain's technical and scalability shortcomings. At the end of 2013, Vitalik Buterin introduced smart contracts into the blockchain, opening up blockchain applications beyond currency and ushering in the Blockchain 2.0 era.

[0035] In a blockchain system, different participants can establish a distributed blockchain network through the deployment of nodes. A decentralized (or multi-centralized) distributed ledger, constructed using a chained block structure, is stored on each node (or a majority of nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system must address the consistency and correctness of ledger data across multiple nodes in the decentralized (or multi-centralized) network. Each node (or multiple nodes) runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, ensuring that all loyal nodes execute the same transaction results. Transactions and execution results are then packaged into blocks.

[0036] As mentioned above, each node (or multiple nodes) runs a blockchain program. Under certain fault-tolerance requirements, a consensus mechanism ensures that all loyal nodes have the same transactions, thereby ensuring that all loyal nodes execute the same transactions consistently. Transactions and execution results are then packaged and generated into blocks. Current mainstream consensus mechanisms include Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT), and HoneyBadgerBFT.

[0037] Blockchains can use Proof of Work (PoW) as a consensus algorithm. The key concept of PoW is to quantify the computing power of nodes, ensuring that the entire network remains secure with a high probability when a malicious adversary controls no more than half of the computing power. PoW is suitable for public blockchains where the number of nodes cannot be accurately determined but where non-malicious nodes constitute the majority. PoW itself consumes enormous computing resources, while the primary goal of mining is simply to quantify computing power. Furthermore, blockchain technologies must strike a balance between block time and mining workload. To avoid forks, users are advised to confirm transactions after six blocks, which can take over an hour to confirm. Currently, miners often form mining pools to increase their probability of generating blocks, which contradicts the principle of decentralization.

[0038] Take PBFT, for example. This algorithm, proposed by Miguel Castro and Barbara Liskov in 1999, addresses the inefficiency of the original Byzantine fault-tolerance algorithm, reducing its complexity from exponential to polynomial, making it feasible for practical system applications. The paper was presented at the 1999 International Conference on Operating Systems Design and Implementation (OSDI99). In the PBFT algorithm, all replicas operate in a rotation process called a view (succession of configuration). In a view, one replica serves as the primary node, while the others serve as backups. A view is a consecutively numbered integer. The primary node can be calculated using the formula p = v mod |R|, where v is the view number, p is the replica number, and |R| is the number of replicas. The algorithm assumes that if at most f replicas (i.e., nodes) fail, safety and liveness are guaranteed in an asynchronous system if a total of at least 3f + 1 replicas remain. The set of replicas required to ensure data consistency and fault tolerance across all replicas is typically a majority of the nodes in the distributed system, forming a quorum. For example, if the total number of nodes n is 3f+1 (n=3f+2 or n=3f generally does not improve fault tolerance), the quorum is 2f+1. Thus, for a distributed system with four nodes, any three nodes can form a quorum.

[0039] PBFT includes two processes: Normal Case Phase and View Change Phase. Figure 1This is a flowchart of the Normal Case Phase process. The Normal Case Phase mainly includes three phases: PRE-PREPARE, PREPARE, and COMMIT. Node 3, for example, can represent a downtime node ( Figure 1 Indicated by ×). When the master node fails ( Figure 2 Indicated by an ×, if the primary node (Replica 0) fails before the view is changed, the view change process needs to be started. This allows the system to adjust when a failure occurs and replace the new primary node (for example, after the view is changed, Replica 1 becomes the primary node). Figure 2 This is a diagram of the ViewChange Phase. If the master node goes offline or acts maliciously and does not broadcast the client's request, the client can set a timeout mechanism. If the timeout occurs, the client can broadcast the request message to all replica nodes. After the replica node detects that the master node is acting maliciously or is offline, it can also initiate the View Change protocol phase to replace the master node (often referred to as "changing the master"). In addition, the three-phase consensus process of PRE-PREPARE, PREPARE, and COMMIT may fail due to the master node initiating an erroneous proposal, or the PREPARE and COMMIT phases may not reach a consensus on the quorum number (such as 2f+1 out of 3f+1 nodes, also known as the legal number), and consensus cannot be achieved. In these cases, the View Change protocol phase may also be initiated to replace the master node.

[0040] Under normal circumstances, that is, when the consensus nodes are not down and the consensus message can reach each other within a certain period of time, that is, when the master does not change, the Normal Case Phase process in PBFT can be as follows: Figure 3 As shown, the figure still takes 4 consensus nodes as an example.

[0041] During the Normal Case Phase of round r-1, node 0, acting as the master node, collects a certain number of transactions awaiting consensus (or read-write sets, etc., which will be explained using transactions as an example below). It then initiates the pre-prepare process (the aforementioned PRE-PREPARE, also referred to as the PP phase). Nodes 1, 2, and 3 then enter the preparation process (the aforementioned PREPARE, also referred to as the P phase). Afterward, nodes 0, 1, 2, and 3 enter the commit process (the aforementioned COMMIT, also referred to as the C phase). The PP, P, and C phases are generally collectively referred to as the three phases of PBFT. Under normal circumstances, this completes the three-phase process of round r-1 of PBFT, achieving consensus on the transaction data corresponding to block m-1 and generating information such as the block number. Consequently, each consensus node can execute these transactions sequentially based on the agreed-upon transaction data, following the agreed-upon transaction order and content, to generate the world state and receipt. Specifically, each node can construct a Merkle tree (including tree structures such as the MPT tree, which combines the Merkle tree and the Patricia tree (a compressed prefix tree, a more space-efficient Trie tree, dictionary tree)) based on the consensus transaction data locally and generate the hash of the Merkle tree's root (also called the transaction root hash). Similarly, a Merkle tree can be constructed based on the world state data and the hash of the Merkle tree's root (also called the state root hash) can be generated. A Merkle tree can be constructed based on the receipt data and the hash of the Merkle tree's root (also called the receipt root hash) can be generated. After each node generates these three root hashes locally, it can generate the m-1th block locally. The block header of the m-1th block may include the aforementioned block number, transaction root hash, state root hash, receipt root hash, and other information. The block body may include a transaction data set, a world state set, and a receipt set. In this way, the m-1th block is generated.

[0042] During the generation of the mth block, the three-stage process in PBFT will be repeated. Figure 3In the process, for the mth block, node 0 acts as the master node to collect a certain number of transactions to be agreed upon, and then initiates the PP process. Then nodes 1, 2, and 3 enter the P process, and then nodes 0, 1, 2, and 3 enter the C process. In this way, under normal circumstances, the three-stage process of the rth round of PBFT is completed, and the consensus of the transaction data corresponding to the mth block is completed, and the block number and other information of this block are also generated. Each node can execute these transactions in sequence based on the consensus transaction data, in accordance with the order and content of the consensus transaction data, and then generate the world state and receipt. After each node generates the three root hashes as mentioned above locally, it can generate the mth block locally. The block header of the mth block can include the aforementioned block number, transaction root hash, state root hash, receipt root hash and other information, and the block body can include transaction data set, world state set and receipt set. In this way, the mth block is generated. Similarly, the generation of the m+1th block includes the following process: Figure 3 The three-phase process of PBFT in round r+1 is shown in Figure .

[0043] It can be seen that in the case of normal block generation, each consensus node includes a PBFT Normal Case Phase process in the process of generating each block. As blocks are continuously generated, each consensus node will repeat this consensus process. Figure 3 The following only illustrates the consensus process in rounds r-1, r, and r+1. Some consensus nodes act as master nodes in PBFT, while others act as backup nodes.

[0044] A consensus process, i.e. a three-phase PBFT process, can include:

[0045] a110: (PRE-PREPARE phase) Master node 0 collects a certain number of pending consensus transactions, sorts them, packages them into message m (also known as the original transaction list), and sends a pre-prepare request to backup nodes 1, 2, and 3. The pre-prepare request includes the original transaction list.

[0046] a120: (PREPARE preparation phase) After nodes 1, 2, and 3 receive the pre-prepare request, if they check that the original transaction list is legal, they will broadcast the hash value of the message m they received through the prepare message (the broadcast content generally does not include the message m itself, because the message m includes several original transaction requests and is generally large in size). Specifically, node 1 diffuses the prepare message to nodes 0, 2, and 3, node 2 diffuses the prepare message to nodes 0, 1, and 3, and node 3 diffuses the prepare message to nodes 0, 1, and 2. Correspondingly, each node also receives prepare messages broadcast by other nodes. Each node adds the prepare message it sends (which contains the hash value of message m, representing its own approval) and the prepared message it receives (which contains the hash value of message m, representing the approval of other nodes) to the local log (Log). If a node collects at least a Quorum of legal pp messages / p messages from different nodes (including pre-prepare and prepare messages sent by itself, and prepare messages received), it will transition to the prepared state.

[0047] a130: (COMMIT phase) After entering the prepared state, each consensus node sends a commit message to other consensus nodes and adds its own commit message to its local log (representing its own approval). Furthermore, each node receives commit messages broadcast by other nodes. Once a node has collected at least a quorum of valid commit messages from different nodes and added them to its local log (this adds up to a total of quorums, including the number of commit messages it has added to its own local log), it enters the committed state.

[0048] a140: The node that changes to the committed state outputs message m as the consensus result of this round.

[0049] The transactions included in message m and their order are generally determined by the masternode in a110. This determination of transaction inclusion and order is crucial to the consensus mechanism. A blockchain network may receive numerous transaction requests. The transactions packaged by the masternode in a110 determine which transactions will be processed by the blockchain network and whose execution results will be recorded on the blockchain. Even for the same set of transactions, a different execution order can lead to different final results, impacting the consistency of ledgers across nodes.

[0050] In the PBFT protocol, although a view change process is provided when the master node fails, a new master node is replaced (such as Figure 2 After the replacement, Replica 1 becomes the Primary node. Many PBFT implementations rotate the primary node within a fixed range of consensus nodes, and many implementations also have a fixed rotation rule. This relatively fixed rotation method makes it easy to guess the next consensus primary node, making it vulnerable to attacks.

[0051] This application provides an embodiment of a consensus method on a blockchain. Figure 4 As shown, including:

[0052] S110: Determine a consensus node that initiates a consensus proposal within the consensus group in this round of consensus based on the random number of the previous round, and the determined consensus node initiates the consensus proposal.

[0053] Assume that the current consensus round is r, the previous round was r-1, and that there are 10 consensus nodes in the blockchain network, numbered 1 to 10. These 10 consensus nodes can be divided into several groups, with the consensus nodes within each group being either overlapping or non-overlapping. This example uses the case of 10 consensus nodes being divided into two groups with no overlap between the consensus nodes within these two groups; other scenarios are essentially similar.

[0054] Assume that consensus nodes 1-4 are the first consensus group, and consensus nodes 5-10 are the second consensus group.

[0055] In the r-1th round of consensus, a random number can be generated, which is set as ξ r-1 In the rth round of consensus, on the one hand, we can r-1 To determine the consensus node that initiated the proposal in this round, on the other hand, a random number can be generated in this round, which is set as ξ r .

[0056] Specifically, it can be based on ξ r-1 Calculate the priority of each consensus node in the consensus group in this round of consensus, and the consensus node with the highest priority is the consensus node that initiates the consensus proposal.

[0057] In the genesis block, a random number can be set as ξ0. Starting from block 1, the random number in the previous block can be used to generate the random number for this round and determine the consensus group that initiates the proposal in this round.

[0058] In addition, the consensus group in the current round of consensus can also be determined based on the random number of the previous round. As mentioned above, for example, if the consensus group in the r-1 round is the second consensus group, the consensus group in the r round can be determined based on ξ r-1Determined as the first consensus group. In this way, according to the random number ξ in the r-1 round r-1 The consensus node that initiated the consensus proposal in the rth round of consensus is determined to be the consensus node in the first consensus group. Similarly, based on the calculation of ξ r-1 Calculate the priority of each consensus group in this round of consensus, and the consensus group with the highest priority will be the consensus group for this round. The group to which the consensus node belongs can be determined by ξ0.

[0059] S120: Each consensus node in the consensus node group uses its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group.

[0060] For example, the consensus group in the rth round of consensus determined by S110 is the first consensus group, and the consensus node that initiates the consensus proposal is node 1. For example, in a blockchain network using the PBFT consensus algorithm:

[0061] In the rth round of consensus, for example, after consensus node 1 collects a certain number of transaction requests, it can sort and package these transaction requests to generate a raw transaction list, and then initiate a consensus proposal for the packaged raw transaction list. Consensus node 1, as the master node for this round of consensus, initiates a PP message, thereby broadcasting the PP message containing the raw transaction list (which may also include information such as the consensus round, collectively referred to as the consensus proposal) to the other consensus nodes in the first consensus group, namely nodes 2-4. In the P phase, each of consensus nodes 1-4 can use its own first private key share in the threshold signature algorithm to sign the consensus proposal, for example, by generating a first signature share from the hash value containing the raw transaction list (e.g., including information such as the consensus round), and broadcasting the first signature share to the other consensus nodes in the consensus group via a P message.

[0062] Alternatively, in the rth round of consensus, for example, after consensus node 1 collects a certain number of transaction requests, it sorts and packages these transaction requests to generate an original transaction list, and uses its own first private key share in the threshold signature algorithm to sign the hash value containing the original transaction list (e.g., including information such as the consensus round, collectively referred to as the consensus proposal) to generate a first signature share, and then broadcasts a PP message containing the consensus proposal and the signature share. In the P phase, each of consensus nodes 2-4 can use its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group via a P message.

[0063] In addition, in stage C, each of the consensus nodes 1-4 may separately sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes within the consensus group via a C message.

[0064] Threshold signature, also known as threshold signature, is an important branch of digital signature and a combination of threshold secret sharing technology and digital signature. A threshold signature scheme first includes 1 aggregate public key (or called aggregated public key) and n public-private key pairs. One public key in each public-private key pair is called a public key share, and one private key in each public-private key pair is called a private key share. Secondly, there is a recovery function corresponding to this aggregate public key and n public-private key pairs. This recovery function can restore the signature shares signed by at least the threshold number of different private key shares into a complete signature (or called aggregated signature), and the generated complete signature can also be verified for correctness by the said 1 aggregate public key. And any signature shares less than the threshold number cannot be restored to generate this complete signature. Threshold signature mechanisms based on ECDSA (Elliptic Curve Digital Signature Algorithm), Schnorr (a knowledge proof mechanism based on the discrete logarithm problem), BLS (Boneh-Lynn-Shacham Signature), etc. can be adopted.

[0065] It should be noted that in the threshold signature scheme adopted in the blockchain, the number of private key shares can be equal to the number of consensus nodes (set as n), and the number of the minimum signature shares for the recovery function to generate a complete signature (i.e., the threshold number, set as t, generally t < n) can be equal to the quorum in the PBFT algorithm. Of course, the number of private keys can also not be equal to the number of consensus nodes, and the number of the minimum signature shares for the recovery function to generate a complete signature can not be equal to the quorum in the PBFT algorithm. The former is taken as an example for illustration below.

[0066] The said 1 aggregate public key and n public-private key pairs can be generated by a centralized dealer and distributed to n blockchain consensus nodes. This belongs to the centralized key distribution method. Thus, combined with the consensus algorithm, n private key shares can be held by each blockchain consensus node with one of them. At the same time, each blockchain consensus node can hold the same 1 aggregate public key. In addition, there is also a decentralized key distribution method, that is, canceling the dealer, and instead, n consensus nodes negotiate to obtain n paired public-private key pairs and 1 aggregate public key through a key negotiation process. Still, each consensus node separately holds one of the n private key shares, and each consensus node holds the same 1 aggregate public key.

[0067] Using the threshold signature algorithm, each consensus node in the first consensus group can use its own unique private key (for example, in a blockchain network containing 4 nodes and using PBFT as the consensus algorithm, the private key shares held by node 1, node 2, node 3, and node 4 using the threshold signature algorithm are sk1, sk2, sk3, and sk4 respectively, and the subscript numbers can represent the node numbers) to sign the hash value of the consensus proposal containing the original transaction list in this consensus to obtain the signature result.

[0068] In addition, the nodes in the consensus group that receive the consensus proposal in S120 can verify whether the node initiating the consensus proposal is the node with the highest priority. If so, the process in S120 is executed; otherwise, the node initiating the consensus proposal is judged to be a malicious node.

[0069] S130: The consensus node that has collected the threshold number of first signature shares uses the first recovery function in the threshold signature algorithm to recover the first aggregate signature, and broadcasts the first aggregate signature to the blockchain network.

[0070] First, the consensus node that receives the first signature share can verify the first signature share using the corresponding first public key. If the verification passes, it means that the first signature share is correct; otherwise, the first signature share is discarded.

[0071] The consensus node that collects at least a threshold number of first signature shares can use the corresponding first recovery function to recover at least the threshold number of first signature shares to obtain a first aggregate signature.

[0072] For example, each of the four nodes in the first consensus group has a public-private key pair, and each node has a corresponding recovery function and the same aggregate public key. After any node has collected at least a threshold number of first signature shares, it can use the corresponding first recovery function to recover at least the threshold number of first signature shares, thereby obtaining a first aggregate signature. This first aggregate signature can then be verified using the first aggregate public key.

[0073] Furthermore, at least one consensus node that recovers the first aggregate signature may broadcast the first aggregate signature to the blockchain network, for example, to consensus nodes 1-10. At least one consensus node may also broadcast the first aggregate public key to the blockchain network, for example, to consensus nodes 1-10.

[0074] S140: The blockchain node that receives the first aggregate signature and the first aggregate public key uses the first aggregate public key to verify the first aggregate signature. After the verification is successful, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0075] As described in the aforementioned steps, through the threshold signature algorithm, there is no need to prove the consensus of the consensus proposal confirmed in S140 through the signatures of at least a quorum of consensus nodes. Instead, the first recovery function is used to restore at least the threshold first signature shares into a first aggregate signature, which can greatly reduce the space occupied by the signature information and the transmission resources.

[0076] A blockchain node that receives the first aggregate signature and the first aggregate public key, such as any of consensus nodes 1-10, can use the first aggregate public key to verify the first aggregate signature. As previously described, the first aggregate public key can verify the correctness of the first aggregate signature. Successful verification indicates that the consensus proposal has been agreed upon by at least a threshold number of consensus nodes (t, for example, if t = quorum, then the consensus condition is met) in the consensus group, i.e., all have expressed their approval of the consensus proposal by signing it with their own shares of the first private key. In a consensus process, if a quorum of consensus nodes in the consensus group have all expressed their approval of the consensus proposal, the consensus proposal can be determined as the consensus result for that time.

[0077] A truly randomly generated consensus proposal node means its selection cannot be known in advance. This probabilistically guarantees the security of the blockchain's public disclosure system, especially when the number of nodes is large. Through this approach, the consensus node initiating consensus proposals can be changed based on the random number in each consensus round. This makes the rotation of consensus proposal nodes less fixed and less predictable, thereby reducing the probability of consensus proposal nodes being attacked. Furthermore, the consensus group executing consensus can be changed based on the random number, and the corresponding consensus proposal node will also be changed to a consensus node within the consensus group executing consensus, further reducing the probability of consensus proposal nodes being attacked.

[0078] In S110, the consensus node that initiates the consensus proposal in the consensus group in this round is determined based on the random number of the previous round, and the threshold signature algorithm can also be used to obtain it. Figure 5 As shown, including the following:

[0079] S210: Each consensus node in the consensus node group uses its own second private key share in the threshold signature algorithm to sign the random number of the previous round, generates a second signature share, and broadcasts the second signature share to other consensus nodes in the consensus group.

[0080] S220: The consensus node that has collected the threshold number of second signature shares uses the second recovery function in the threshold signature algorithm to recover the second aggregate signature, and generates a random number in this round based on the second aggregate signature.

[0081] It should be noted that the second private key share may be the same as or different from the first private key share, and the second recovery function may be the same as or different from the first recovery function.

[0082] S110-S140 and S210-S220 described above all involve the use of a threshold signature algorithm. As mentioned above, a threshold signature scheme based on ECDSA, Schnorr, or BLS can be used. This type of threshold signature scheme first includes an aggregate public key and n public-private key pairs. The public key in each public-private key pair is called a public key share, and the private key in each public-private key pair is called a private key share. Secondly, there exists a recovery function corresponding to this aggregate public key and the n public-private key pairs. This recovery function can restore signature shares signed with at least a threshold number of different private key shares into a single aggregate signature. The correctness of this generated complete signature can also be verified using the aggregate public key. Any signature shares that are less than the threshold number cannot be used to restore the complete signature. Furthermore, signature shares signed with private key shares can be verified using the corresponding public key shares.

[0083] The n participants in a consensus group can generate public-private key pairs and an aggregate public key in a centralized or decentralized manner. Here, the decentralized manner is used for explanation. The n participants can use the Distributed Key Generation (DKG) protocol to generate the n public-private key pairs and 1 aggregate public key. For example, for the first consensus group, there are 4 consensus nodes, numbered 1, 2, 3, and 4. This method is for example Figure 6 As shown, including the following:

[0084] S310: Each consensus node in the consensus group generates a unique set of n secret shares, retains one for itself, and encrypts n-1 secret shares and sends them to the other n-1 nodes.

[0085] Each node can be in group Z q A polynomial of degree t is randomly selected. The Nth-degree polynomial function is uniquely determined by N+1 points. Because at least a quorum of consensus nodes in the consensus group must be able to recover the signature, quorum = N+1, so the degree t of the polynomial is quorum-1. In this way, a complete signature can be recovered by at least a quorum (quorum = t+1) signature shares through the recovery function. Of course, t can also be set to other values. The elliptic curve constructed using this polynomial can be expressed as follows:

[0086] f i (z) = a i0 +a i1 z+a i2 z2 +…+a it z t Formula (1)

[0087] In formula (1), a i0 , a i1 , a i2 , a i3 ,...,a it are the coefficients of the polynomial, and a polynomial can be determined by this set of coefficients.

[0088] When the number of consensus nodes n in the blockchain network is set to 4, and the quorum of algorithms such as PBFT and HBBFT is 3, then t = 2. In this case, the polynomial is:

[0089] f i (z) = a i0 +a i1 z+a i2 z 2 Formula (2)

[0090] Node 1 can randomly select a set of numbers from a finite prime number field as coefficients, that is, as a 10 , a 11 , a 12 , then the generated polynomial is: f1(z)=a 10 +a 11 z+a 12 z 2 .

[0091] Similarly, node 2 can randomly select a set of numbers from the same finite prime number field as coefficients, that is, as a 20 , a 21 , a 22 , then the generated polynomial is: f2(z)=a 20 +a 21 z+a 22 z 2 .

[0092] Similarly, node 3 can randomly select a set of numbers from the same finite prime number field as coefficients, that is, as a 30 , a 31 , a 32 , then the generated polynomial is: f3(z)=a 30 +a 31 z+a 32 z 2 .

[0093] Similarly, node 4 can randomly select a set of numbers from the same finite prime number field as coefficients, that is, as a 40 , a41 , a 42 , then the generated polynomial is: f4(z)=a 40 +a 41 z+a 42 z 2 .

[0094] Each node can further determine a set of secret shares based on the determined polynomial. The secret shares can be determined from the polynomial coefficients according to the following formula:

[0095] s ij =f i (j)mod q(j=1,…,n) Formula (3)

[0096] In formula (3), q is a large number that is used by each node. i (j) The purpose of taking the modulus with q is to convert f i The value of (j) is limited to the range [0,q-1]. For example:

[0097] Consensus node 1 generates 4 secret shares, namely S 11 =f1(1)mod q,S 12 =f1(2)mod q,S 13 =f1(3)mod q,S 14 =f1(4) mod q. The four secret shares here are equal to the total number of consensus nodes. In other words, if we want to ultimately generate a complete signature using the recovery function by taking any w signature shares from n, we need to generate n secret shares. The same applies below.

[0098] Consensus node 2 generates 4 secret shares, namely S 21 =f2(1)mod q,S 22 =f2(2)mod q,S 23 =f2(3)mod q,S 24 =f2(4)mod q.

[0099] Consensus node 3 generates 4 secret shares, namely S 31 =f3(1)mod q,S 32 =f3(2)mod q,S 33 =f3(3)mod q,S 34 =f3(4)mod q.

[0100] Consensus node 4 generates 4 secret shares, namely S 41 =f4(1)mod q,S 42 =f4(2)mod q,S 43=f4(3)mod q,S 44 =f4(4)mod q.

[0101] Furthermore, in addition to retaining a secret share, each node can exchange other secret shares generated with other consensus nodes through the P2P network. The details can be as follows:

[0102] Consensus node 1 retains S 11 , S 12 Send to node 2, and S 13 Send to node 3, and S 14 The secret shares sent to node 4 can be sent through the underlying P2P (Peer to Peer) network component of the blockchain network. The sent secret shares need to be kept confidential. Consensus node 1 can encrypt the secret shares with the recipient's public key before sending them to the recipient, or send them to the recipient through a secure connection such as TLS (Transport Layer Security).

[0103] Consensus node 2 retains S 22 , S 21 Send to node 1, and S 23 Send to node 3, and S 24 The secret shares sent to node 4 can be sent, for example, via the underlying P2P network component of the blockchain network. Similarly, the sent secret shares must be kept confidential. Consensus node 2 can encrypt the sent secret shares with the recipient's public key before sending them to the recipient, or send them to the recipient via a secure connection such as TLS.

[0104] Consensus node 3 retains S 33 , S 31 Send to node 1, and S 32 Send to node 2, and S 34 Send to node 4. Similarly, the sent secret share needs to be kept confidential. Consensus node 3 can encrypt the secret share to be sent with the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0105] Consensus node 4 retains S 44 , S 41 Send to node 1, and S 42 Send to node 2, and S 43 Sent to node 3. Similarly, the sent secret share needs to be kept confidential, and consensus node 4 can encrypt the secret share to be sent with the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0106] The two numbers in the subscript of the secret share can be seen. The left one can represent the number of the node that sends the secret share, and the right one can represent the node that receives the secret share.

[0107] Consensus node 1 locally has a secret share S generated by different nodes 11 、S 21 、S 31 、S 41 ;

[0108] Consensus node 2 locally has a secret share S generated by a different node 12 、S 22 、S 32 、S 42 ;

[0109] Consensus node 3 locally has a secret share S generated by different nodes 13 、S 23 、S 33 、S 43 ;

[0110] Consensus node 4 locally has a secret share S generated by different nodes 14 、S 24 、S 34 、S 44 .

[0111] Among them, consensus node 1 has S locally 11 It is generated by itself, and the consensus node 2 has S locally 22 It is generated by itself, and the consensus node 3 has S locally 33 It is generated by itself, and the consensus node 4 has S locally 44 It is generated by itself.

[0112] It is best for consensus nodes to sign the secret shares they send, for example, using their own private keys or using a MAC (Message Authentication Code) to ensure message integrity and prevent man-in-the-middle attacks. Nodes that receive the secret shares can then verify the correctness of the signature.

[0113] S320: Each node generates public verification parameters corresponding to its own secret share and broadcasts them to other nodes in the consensus group. Each consensus node can generate a set of verification parameters corresponding to its own secret share. The generation method can use the following formula:

[0114]

[0115] In formula (4), g is a base point on the elliptic curve. Due to the computational properties of elliptic curves, a power of g is also a point on the elliptic curve. t is the degree of the polynomial, generally set to (quorum - 1). As mentioned above, if we want to ultimately generate a complete signature by taking any w signature shares from n signature shares using the recovery function, we need to set the degree of the polynomial to t, where t = w - 1. The same applies below.

[0116] Based on the above formula (4), let t = 2, and the set of verification parameters generated by consensus node 1 is 10 ,A 11 ,A 12 >, broadcast this set of verification parameters to other nodes. Similarly, based on the above formula, the set of verification parameters generated by consensus node 2 is 20 ,A 21 ,A 22 >, broadcast this set of verification parameters to other nodes. Similarly, based on the above formula, the set of verification parameters generated by consensus node 3 is 30 ,A 31 ,A 32 >, broadcast this set of verification parameters to other nodes. Similarly, based on the above formula, the set of verification parameters generated by consensus node 4 is 40 ,A 41 ,A 42 >, broadcast this set of verification parameters to other nodes.

[0117] Based on the nature of cryptography, A ik Even if it is published, it will not be possible to reversely infer a ik , so even if the published A ik , nor can we obtain the polynomial in S310.

[0118] In this way, the result of broadcasting the public verification parameters generated by each node can be as follows:

[0119] Consensus node 1 locally has a secret share S generated by different nodes 11 、S 21 、S 31 、S 41 , and validation parameters 10 ,A 11 ,A 12 >, and can obtain public verification parameters 20 ,A 21 ,A 22 >, 30 ,A 31 ,A 32 >, 40 ,A 41 ,A 42 >​​​​​​​​

[0120] Consensus node 2 locally has a secret share S generated by a different node 12 、S 22 、S 32 、S 42 , and validation parameters 20 ,A 21 ,A 22 >, and can obtain public verification parameters 10 ,A 11 ,A 12 >, 30 ,A 31 ,A 32 >, 40 ,A 41 ,A 42 >

[0121] Consensus node 3 locally has a secret share S generated by different nodes 13 、S 23 、S 33 、S 43 , and validation parameters 30 ,A 31 ,A 32 >, and can obtain public verification parameters 10 ,A 11 ,A 12 >, 20 ,A 21 ,A 22 >, 40 ,A 41 ,A 42 >

[0122] Consensus node 4 locally has a secret share S generated by different nodes 14 、S 24 、S 34 、S 44 , and validation parameters 40 ,A 41 ,A 42 >, and can obtain public verification parameters 10 ,A 11 ,A 12 >, 20 ,A 21 ,A 22 >, 30 ,A 31 ,A 32 >.

[0123] ​​​​​​​​​​​​S330: Each consensus node verifies each received secret share and corresponding public verification parameter, and broadcasts the verified node number to other nodes.

[0124] Each consensus node can receive secret shares from any other node and receive broadcast public verification parameters.

[0125] As mentioned in S310 above, each consensus node generates n secret shares S ij , retaining a copy for itself, and encrypting the n-1 secret shares and sending them to the other n-1 nodes. As mentioned in S320 above, each node generates a public verification parameter corresponding to its own secret share and broadcasts it.

[0126] If the secret shares sent by each node and the corresponding public verification parameters belong to the same polynomial, then the following equation should hold:

[0127]

[0128] As mentioned above, t = quorum - 1; when n = 4, quorum = 3, and then t = 2.

[0129] Based on the properties of formula (5), each received secret share and public verification parameter can be verified using this formula. If the verification equation holds, it means that the secret share and the corresponding public verification parameter belong to the same polynomial, otherwise they do not belong to the same polynomial. This can also be used to verify whether the node that generates the secret share and the corresponding public verification parameter has committed malicious behavior. A typical malicious behavior is for example, if the node generates S according to the first polynomial. ij , but A is generated with a different polynomial ik (k=0,...,t).

[0130] The above verification, specifically:

[0131] When j=1, consensus node 1 can verify the following:

[0132] i=1: (In fact, consensus node 1 does not need to verify whether this equation holds, because the secret share S 11 and validation parameters 11 ,A 12 ,A 13 >are all self-generated)

[0133] i=2:

[0134] i=3:

[0135] i=4:​

[0136] When j=2, consensus node 2 can verify the following:

[0137] i=1:

[0138] i=2: (In fact, consensus node 2 does not need to verify whether this equation holds, because the secret share S 22 and validation parameters 20 ,A 21 ,A 22 >are all self-generated)

[0139] i=3:

[0140] i=4:

[0141] When j=3, consensus node 3 can verify the following:

[0142] i=1:

[0143] i=2:

[0144] i=3: (In fact, consensus node 3 does not need to verify whether this equation holds, because the secret share S 33 and validation parameters 30 ,A 31 ,A 32 >are all self-generated)

[0145] i=4:

[0146] When j=4, consensus node 4 can verify the following:

[0147] i=1:

[0148] i=2:

[0149] i=3:

[0150] i=4: (In fact, consensus node 4 does not need to verify whether this equation holds, because the secret share S 44 and validation parameters 40 ,A 41 ,A 42 >are all self-generated)

[0151] ​​​After each consensus node passes each verification, it can broadcast the verified node number to other nodes.

[0152] Consensus Node 2 Verifies Equation If it is established, the number of node 1 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters issued by node 2 to node 1 have passed the verification.

[0153] Consensus Node 3 Verifies Equation If it is established, the number of node 1 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters issued by node 3 to node 1 have passed the verification.

[0154] Consensus Node 4 Verification Equation If it is established, the number of node 1 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters issued by node 4 to node 1 have passed the verification.

[0155] In this way, any one of consensus nodes 2, 3, and 4 can collect the confirmation of node 1's passing of verification from all other nodes except node 1. Therefore, it can be considered that the secret shares and corresponding public verification parameters issued by node 1 belong to the same polynomial.

[0156] akin:

[0157] Consensus node 1 verifies the equation If it is established, the number of node 2 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters sent by node 1 to node 2 have passed the verification.

[0158] Consensus Node 3 Verifies Equation If it is established, the number of node 2 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters issued by node 3 to node 2 have passed the verification.

[0159] Consensus Node 4 Verification Equation If it is established, the number of node 2 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameter issued by node 4 to node 2 have passed the verification.

[0160] In this way, any one of consensus nodes 1, 3, and 4 can collect confirmation from all other nodes except node 2 that node 2 has passed verification. Therefore, it can be considered that the secret shares and corresponding public verification parameters issued by node 2 all belong to the same polynomial.

[0161] akin:

[0162] Consensus node 1 verifies the equation If it is established, the number of node 3 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameter sent by node 1 to node 3 have passed the verification.

[0163] Consensus Node 2 Verifies Equation If it is established, the number of node 3 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameter sent by node 2 to node 3 have passed the verification.

[0164] Consensus Node 4 Verification Equation If it is established, the number of node 3 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameter issued by node 4 to node 3 have passed the verification.

[0165] In this way, any one of consensus nodes 1, 2, and 4 can collect the confirmation of node 3's passing of verification from all other nodes except node 3. Therefore, it can be considered that the secret shares and corresponding public verification parameters issued by node 3 all belong to the same polynomial.

[0166] akin:

[0167] Consensus node 1 verifies the equation If it is established, the number of node 4 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters sent by node 1 to node 4 have passed the verification.

[0168] Consensus Node 2 Verifies Equation If it is established, the number of node 4 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameter sent by node 2 to node 4 have passed the verification.

[0169] Consensus Node 4 Verification Equation If it is established, the number of node 4 can be broadcast to other nodes to indicate that the secret share and the corresponding public verification parameters sent by node 3 to node 4 have passed the verification.

[0170] In this way, the DKG contract can collect all the confirmations of node 4 passing the verification from all nodes except node 4, so it can be considered that the secret shares and corresponding public verification parameters issued by node 4 belong to the same polynomial.

[0171] S340: Each consensus node determines the node set based on the node numbers that have passed the verification sent by each consensus node, calculates the public key share based on the verification parameters and the node set, and calculates its own corresponding private key share and aggregated public key based on the local secret share and the node set.

[0172] Furthermore, each consensus node may determine the node set based on the node numbers that have passed verification sent by each consensus node.

[0173] For example, the DKG contract can determine a node set based on the transaction verifications sent by each consensus node. Specifically, for a node ID, if a node receives confirmations from all other nodes for that node ID, the confirmed node ID is added to the node set. This set is, for example, the QUAL set.

[0174] For example, in the example of S340, node 2 receives confirmation from node 3 and node 4 for node 1. If node 2 itself also confirms node 1, node 2 can add node 1 to the QUAL set. Similarly, node 3 receives confirmation from node 2 and node 4 for node 1. If node 3 itself also confirms node 1, node 3 can add node 1 to the QUAL set. Similarly, node 4 receives confirmation from node 2 and node 3 for node 1. If node 4 itself also confirms node 1, node 4 can add node 1 to the QUAL set. In addition, if node 1 receives confirmation from node 2, node 3, and node 4 for node 1, node 1 can add its own number to the QUAL set (normally, node 1 recognizes itself).

[0175] Thus, the QUAL sets of nodes 1, 2, 3, and 4 each include {1}.

[0176] Similarly, if node 1 receives confirmation from nodes 3 and 4 for node 2, and if node 1 itself also confirms node 2, node 1 can add node 2 to the QUAL set. Similarly, if node 3 receives confirmation from nodes 1 and 4 for node 2, and if node 3 itself also confirms node 2, node 3 can add node 2 to the QUAL set. Similarly, if node 4 receives confirmation from nodes 1 and 3 for node 2, and if node 4 itself also confirms node 2, node 4 can add node 2 to the QUAL set. In addition, if node 2 receives confirmation from nodes 1, 3, and 4 for node 2, node 2 can add its own number to the QUAL set (normally, node 2 recognizes itself).

[0177] Thus, the QUAL sets of nodes 1, 2, 3, and 4 each include {1, 2}.

[0178] Similarly, if node 1 receives confirmation from node 2 and node 4 for node 3, and if node 1 itself also confirms node 3, node 1 can add node 3 to the QUAL set. Similarly, if node 2 receives confirmation from node 1 and node 4 for node 3, and if node 2 itself also confirms node 3, node 2 can add node 3 to the QUAL set. Similarly, if node 4 receives confirmation from node 1 and node 2 for node 3, and if node 4 itself also confirms node 3, node 4 can add node 3 to the QUAL set. In addition, if node 3 receives confirmation from node 1, node 2, and node 4 for node 3, node 3 can add its own number to the QUAL set (normally, node 3 approves itself).

[0179] Thus, the QUAL sets of nodes 1, 2, 3, and 4 each include {1, 2, 3}.

[0180] Similarly, if node 1 receives confirmation from node 2 and node 3 regarding node 4, and if node 1 itself also confirms node 4, node 1 can add node 4 to the QUAL set. Similarly, if node 2 receives confirmation from node 1 and node 3 regarding node 4, and if node 2 itself also confirms node 4, node 2 can add node 4 to the QUAL set. Similarly, if node 3 receives confirmation from node 1 and node 2 regarding node 4, and if node 3 itself also confirms node 4, node 3 can add node 4 to the QUAL set. In addition, if node 4 receives confirmation from node 1, node 2, and node 3 regarding node 4, node 4 can add its own number to the QUAL set (normally, node 4 approves itself).

[0181] Thus, the QUAL sets of nodes 1, 2, 3, and 4 each include {1, 2, 3, 4}.

[0182] Furthermore, on the one hand, each consensus node can calculate the public key share locally based on the verification parameters and the node set in the contract. The public key share can be calculated according to the following formula:

[0183]

[0184] Thus, for example, the public key share calculated by consensus node 1 can be:

[0185]

[0186] Similarly, for example, the public key share calculated by consensus node 2 can be:

[0187]

[0188] Similarly, for example, the public key share calculated by consensus node 3 can be:

[0189]

[0190]

[0191] Similarly, for example, the public key share calculated by consensus node 4 can be:

[0192]

[0193] On the other hand, each consensus node calculates its own corresponding private key share based on the local secret share and the node set in the contract, which can be calculated according to the following formula:

[0194] x j =∑ i∈QUAL s ij mod q formula (7)

[0195] For example, consensus node 1 calculates its own share of the private key locally:

[0196]

[0197] Consensus node 2 calculates its own private key share locally:

[0198]

[0199] Consensus node 3 calculates its own private key share locally:

[0200]

[0201] Consensus node 4 calculates its own private key share locally:

[0202]

[0203] It can be seen that the private key shares calculated by nodes 1, 2, 3, and 4 are different.

[0204] On the other hand, each consensus node can calculate the total public key locally based on the verification parameters and the set of nodes in the contract. The total public key can be calculated according to the following formula:

[0205] y=∏ i∈QUAL y i Formula (8)

[0206] Among them, y i =A i0 .

[0207] Thus, for example, the total public key calculated by consensus node 1 can be:

[0208] y=y1*y2*y3*y4=A 10 *A 20 *A 30 *A 40

[0209] Similarly, for example, the total public key calculated by consensus node 2 can be:

[0210] y=y1*y2*y3*y4=A 10 *A 20 *A 30 *A 40

[0211] Similarly, for example, the total public key calculated by consensus node 3 can be:

[0212] y=y1*y2*y3*y4=A 10 *A 20 *A 30 *A 40

[0213] Similarly, for example, the total public key calculated by consensus node 4 can be:

[0214] y=y1*y2*y3*y4=A 10 *A 20 *A 30 *A 40

[0215] It can be seen that the total public key calculated by node 1, node 2, node 3 and node 4 is the same, that is, through the above method, each node obtains the same total public key.

[0216] In the above example, private key share x1 corresponds to public key share pub1, private key share x2 corresponds to public key share pub2, private key share x3 corresponds to public key share pub3, and private key share x4 corresponds to public key share pub4. As mentioned above, each public key share can verify the signature share generated by the corresponding private key share. Furthermore, the complete signature generated by at least a quorum of private key shares, recovered through the recovery function, can be verified by the corresponding aggregate public key.

[0217] The following describes an embodiment of a method for implementing distributed key generation on a blockchain, which is executed by a consensus node of the consensus group in this round. The method includes:

[0218] Determine the consensus node that initiates the consensus proposal within the consensus group in this round of consensus based on the random number of the previous round;

[0219] Sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0220] After collecting the threshold number of first signature shares, the first recovery function in the threshold signature algorithm is used to recover the first aggregate signature, and the first aggregate signature and the corresponding first aggregate public key are broadcast to the blockchain network;

[0221] After receiving the first aggregate signature and the first aggregate public key, the first aggregate signature is verified using the first aggregate public key. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0222] The process of determining the consensus node that initiates the consensus proposal within the consensus group in the current round of consensus based on the random number of the previous round includes:

[0223] The priority of each consensus node in the consensus group in this round of consensus is calculated based on the random number of the previous round, and the consensus node with the highest priority is set as the consensus node that initiates the consensus proposal in this round.

[0224] The method further includes determining a consensus group in the current round of consensus based on the random number of the previous round.

[0225] Determining the consensus group in the current round of consensus based on the random number of the previous round includes:

[0226] The priority of each consensus group in this round of consensus is calculated based on the random number of the previous round, and the consensus group with the highest priority is set as the consensus group for this round.

[0227] The method further includes verifying that the node initiating the consensus proposal is the node with the highest priority.

[0228] The method also includes the consensus node that receives the first signature share verifying the first signature share using the corresponding first public key verification.

[0229] The method further includes determining the random number of the current round based on the random number of the previous round.

[0230] Determining the random number of this round based on the random number of the previous round includes:

[0231] Use its own second private key share in the threshold signature algorithm to sign the random number of the previous round, generate a second signature share, and broadcast the second signature share to other consensus nodes in the consensus group;

[0232] After collecting the threshold number of second signature shares, the second recovery function in the threshold signature algorithm is used to recover the second aggregate signature, and the random number in this round is generated based on the second aggregate signature.

[0233] The consensus nodes in the consensus group determine the private key share, public key share and aggregated public key in the threshold signature algorithm through the following process:

[0234] Generate a unique set of n secret shares, keep one for itself, and encrypt n-1 secret shares and send them to the other n-1 nodes;

[0235] Generate public verification parameters corresponding to its own secret share and broadcast them to other nodes in the consensus group;

[0236] Verify each received secret share and the corresponding public verification parameter, and broadcast the verified node number to other nodes;

[0237] The node set is determined based on the verified node numbers sent by each consensus node, and the public key share is calculated based on the verification parameters and the node set. The corresponding private key share and aggregate public key are calculated based on the local secret share and the node set.

[0238] The following describes an embodiment of a blockchain system of the present application, including several consensus groups, each of which includes several consensus nodes, wherein:

[0239] The consensus nodes in the consensus group executing the consensus in this round each determine the consensus node that initiates the consensus proposal in the consensus group in this round based on the random number of the previous round;

[0240] The determined consensus node initiates a consensus proposal;

[0241] Each consensus node in the consensus group executing consensus in this round uses its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0242] The consensus node that has collected the threshold number of first signature shares uses the first recovery function in the threshold signature algorithm to recover the first aggregate signature, and broadcasts the first aggregate signature and the corresponding first aggregate public key to the blockchain network;

[0243] The blockchain node that receives the first aggregate signature and the first aggregate public key in the blockchain network uses the first aggregate public key to verify the first aggregate signature. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0244] The following describes an embodiment of a first consensus node in a blockchain system of the present application. The first consensus node is a consensus node of a consensus group in this round, wherein the first consensus node executes:

[0245] Determine the consensus node that initiates the consensus proposal within the consensus group in this round of consensus based on the random number of the previous round;

[0246] Sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group;

[0247] After collecting the threshold number of first signature shares, the first recovery function in the threshold signature algorithm is used to recover the first aggregate signature, and the first aggregate signature and the corresponding first aggregate public key are broadcast to the blockchain network;

[0248] After receiving the first aggregate signature and the first aggregate public key, the first aggregate signature is verified using the first aggregate public key. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

[0249] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0250] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0251] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0252] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0253] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0254] The present invention is described with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0255] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0256] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The steps for the function specified in one or more boxes.

[0257] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0258] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0259] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0260] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0261] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0262] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0263] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A method for achieving consensus on a blockchain, comprising: A consensus node that initiates a consensus proposal within the consensus group in this round is determined based on the random number from the previous round. This consensus node initiates the consensus proposal. Each consensus node in the consensus node group uses its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group; Each consensus node that has collected a threshold number of first signature shares uses the first recovery function in the threshold signature algorithm to recover the first aggregate signature, and broadcasts the first aggregate signature and the corresponding first aggregate public key to the blockchain network; Each blockchain node that receives the first aggregate signature and the first aggregate public key uses the first aggregate public key to verify the first aggregate signature. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

2. The method according to claim 1, wherein determining the consensus node that initiates the consensus proposal within the consensus group in the current round of consensus based on the random number of the previous round comprises: The priority of each consensus node in the consensus group in this round of consensus is calculated based on the random number of the previous round, and the consensus node with the highest priority is set as the consensus node that initiates the consensus proposal in this round.

3. The method of claim 1, further comprising determining a consensus group in the current round of consensus based on the random number of the previous round.

4. The method of claim 3, wherein determining the consensus group in the current round of consensus based on the random number of the previous round comprises: The priority of each consensus group in this round of consensus is calculated based on the random number of the previous round, and the consensus group with the highest priority is set as the consensus group for this round.

5. The method of claim 2 further includes, a node within the consensus group that receives the consensus proposal, verifying that the node that initiated the consensus proposal is the node with the highest priority.

6. The method as claimed in claim 2 also includes the consensus node that receives the first signature share using the corresponding first public key to verify the first signature share. The method of claim 1 , further comprising determining the random number of the current round based on the random number of the previous round.

8. The method according to claim 7, wherein determining the random number of the current round based on the random number of the previous round comprises: Each consensus node in the consensus node group uses its own second private key share in the threshold signature algorithm to sign the random number of the previous round, generate a second signature share, and broadcast the second signature share to other consensus nodes in the consensus group; The consensus node that has collected the threshold number of second signature shares uses the second recovery function in the threshold signature algorithm to recover the second aggregate signature and generates the random number in this round based on the second aggregate signature.

9. According to the method of claim 1, the consensus nodes within the consensus group determine the private key share, public key share, and aggregated public key in the threshold signature algorithm through the following process: Each consensus node in the consensus group generates a unique set of n secret shares, retains one for itself, and encrypts n-1 secret shares and sends them to the other n-1 nodes. Each node generates a public verification parameter corresponding to its own secret share and broadcasts it to other nodes in the consensus group; Each consensus node verifies each received secret share and the corresponding public verification parameter, and broadcasts the verified node number to other nodes; Each consensus node determines the node set based on the verified node numbers sent by each consensus node, calculates the public key share based on the verification parameters and the node set, and calculates its own corresponding private key share and aggregated public key based on the local secret share and the node set.

10. A method for achieving consensus on a blockchain, the method being executed by a consensus node of a consensus group in a current round, the method comprising: Determine a consensus node that initiates a consensus proposal within the consensus group in this round based on the random number from the previous round; Sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group; After collecting the threshold number of first signature shares, the first recovery function in the threshold signature algorithm is used to recover the first aggregate signature, and the first aggregate signature and the corresponding first aggregate public key are broadcast to the blockchain network; After receiving the first aggregate signature and the first aggregate public key, the first aggregate signature is verified using the first aggregate public key. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

11. The method according to claim 10, wherein determining the consensus node that initiates the consensus proposal within the consensus group in the current round of consensus based on the random number of the previous round comprises: The priority of each consensus node in the consensus group in this round of consensus is calculated based on the random number of the previous round, and the consensus node with the highest priority is set as the consensus node that initiates the consensus proposal in this round.

12. The method of claim 10, further comprising determining a consensus group in a current round of consensus based on the random number of the previous round.

13. The method of claim 12, wherein determining the consensus group in the current round of consensus based on the random number of the previous round comprises: The priority of each consensus group in this round of consensus is calculated based on the random number of the previous round, and the consensus group with the highest priority is set as the consensus group for this round.

14. The method of claim 11, further comprising verifying that the node initiating the consensus proposal is the node with the highest priority.

15. The method as claimed in claim 11 further includes: the consensus node that receives the first signature share uses the corresponding first public key to verify the first signature share. The method of claim 10 , further comprising determining the random number of the current round based on the random number of the previous round.

17. The method according to claim 16, wherein determining the random number of the current round based on the random number of the previous round comprises: Use its own second private key share in the threshold signature algorithm to sign the random number of the previous round, generate a second signature share, and broadcast the second signature share to other consensus nodes in the consensus group; After collecting the threshold number of second signature shares, the second recovery function in the threshold signature algorithm is used to recover the second aggregate signature, and the random number in this round is generated based on the second aggregate signature.

18. The method of claim 10, wherein the consensus nodes within the consensus group determine the private key share, public key share, and aggregated public key in the threshold signature algorithm through the following process: Generate a unique set of n secret shares, keep one for itself, and encrypt n-1 secret shares and send them to the other n-1 nodes; Generate public verification parameters corresponding to its own secret share and broadcast them to other nodes in the consensus group; Verify each received secret share and the corresponding public verification parameter, and broadcast the verified node number to other nodes; The node set is determined based on the verified node numbers sent by each consensus node, and the public key share is calculated based on the verification parameters and the node set. The corresponding private key share and aggregate public key are calculated based on the local secret share and the node set.

19. A blockchain system comprising several consensus groups, each of which comprises several consensus nodes, wherein: Each consensus node in the consensus group that executes consensus in this round determines a consensus node in the consensus group that initiates a consensus proposal in this round of consensus based on the random number of the previous round; The determined consensus node initiates a consensus proposal; Each consensus node in the consensus group executing consensus in this round uses its own first private key share in the threshold signature algorithm to sign the consensus proposal, generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group; Each consensus node that has collected a threshold number of first signature shares uses the first recovery function in the threshold signature algorithm to recover the first aggregate signature, and broadcasts the first aggregate signature and the corresponding first aggregate public key to the blockchain network; Each blockchain node in the blockchain network that receives the first aggregate signature and the first aggregate public key uses the first aggregate public key to verify the first aggregate signature. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

20. A first consensus node in a blockchain system, wherein the first consensus node is a consensus node of a consensus group in this round, wherein: The first consensus node executes: Determine the first consensus node to initiate a consensus proposal within the consensus group in this round of consensus based on the random number from the previous round; Sign the consensus proposal using its own first private key share in the threshold signature algorithm to generate a first signature share, and broadcast the first signature share to other consensus nodes in the consensus group; After collecting the threshold number of first signature shares, the first recovery function in the threshold signature algorithm is used to recover the first aggregate signature, and the first aggregate signature and the corresponding first aggregate public key are broadcast to the blockchain network; After receiving the first aggregate signature and the first aggregate public key, the first aggregate signature is verified using the first aggregate public key. After the verification is passed, the consensus proposal corresponding to the first aggregate signature is determined as the consensus result of this time.

Images