A method, system and node for implementing distributed key generation on a blockchain

Abstract

A method, system, and node for distributed key generation on a blockchain are disclosed. The method includes: each node generating n secret shares, retaining one secret share for itself, and providing the other n-1 secret shares to the other n-1 nodes; each node generating public verification parameters corresponding to its own secret share and broadcasting them through an on-chain contract; each node verifying each received secret share and its corresponding public verification parameters; each node recording the node number that passed verification after each verification; each node sending the set of recorded verified node numbers to the contract when a preset rule is met, to determine a node set; each node calculating its public key share based on the verification parameters and the node set, and calculating its own private key share based on its local secret share and the node set.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and in particular relate to a method, system and node for implementing distributed key generation on a blockchain. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked together to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application. Summary of the Invention

[0003] The purpose of this invention is to provide a method, system, and node for implementing distributed key generation on a blockchain, including:

[0004] The first aspect provides a method for implementing distributed key generation on a blockchain, including:

[0005] Each node generates n secret shares, keeps one secret share for itself, and provides the other n-1 secret shares to the other n-1 nodes respectively;

[0006] Each node generates public verification parameters corresponding to its own secret share and broadcasts them through an on-chain contract.

[0007] Each node verifies each received secret share and its corresponding public verification parameters;

[0008] Each node records the node number that passed the verification after each verification is completed.

[0009] When each node meets the preset rules, it sends the set of recorded verified node numbers to the contract, so that the contract can determine the node set based on the node numbers sent by each consensus node.

[0010] Each node calculates its public key share based on the verification parameters and the set of nodes, and calculates its own private key share based on its local secret share and the set of nodes.

[0011] The second aspect provides a method for implementing distributed key generation on a blockchain, executed by the first node in the blockchain, including:

[0012] Generate n secret shares, keep one secret share for yourself, and provide the other n-1 secret shares to the other n-1 nodes respectively;

[0013] Generate public verification parameters corresponding to its own secret share and broadcast them through an on-chain contract;

[0014] Receive secret shares generated by other nodes and broadcast the public verification parameters corresponding to those secret shares via on-chain contract;

[0015] Verify each received secret share and its corresponding public verification parameters;

[0016] After each verification is successful, record the node number that passed the verification;

[0017] When the preset rules are met, the set of recorded verified node numbers is sent to the contract so that the contract can determine the node set based on the node numbers sent by each consensus node.

[0018] The public key share is calculated based on the verification parameters and the set of nodes, and the private key share corresponding to itself is calculated based on the local secret share and the set of nodes.

[0019] The third aspect provides a blockchain system comprising several nodes, wherein:

[0020] Each node generates n secret shares, keeps one secret share for itself, and provides the other n-1 secret shares to the other n-1 nodes respectively;

[0021] Each node is used to generate public verification parameters corresponding to its own secret share and broadcast them through an on-chain contract;

[0022] Each node is used to verify each received secret share and its corresponding public verification parameters;

[0023] Each node is used to record the node number that has passed verification after each verification is successful;

[0024] Each node is used to send a set of recorded verified node numbers to the contract when a preset rule is met, so that the contract can determine the node set based on the node numbers sent by each consensus node.

[0025] Each node is used to calculate its public key share based on the verification parameters and the set of nodes, and to calculate its own private key share based on its local secret share and the set of nodes.

[0026] The fourth aspect provides a first node in a blockchain system, including:

[0027] The generation unit is used to generate n secret shares, retain one secret share for itself, and provide the other n-1 secret shares to the other n-1 nodes respectively; it generates the public verification parameters corresponding to its own secret share and broadcasts them through the on-chain contract;

[0028] The receiving unit is used to receive secret shares generated by other nodes and to receive public verification parameters corresponding to the secret shares through on-chain contract broadcast.

[0029] The verification unit is used to verify each received secret share and its corresponding public verification parameters;

[0030] The recording unit is used to record the node number that has passed verification after each verification is passed;

[0031] The sending unit sends a set of recorded verified node numbers to the contract when a preset rule is met, so that the contract can determine the node set based on the node numbers sent by each consensus node.

[0032] The calculation unit is used to calculate the public key share based on the verification parameters and the node set, and to calculate its own private key share based on the local secret share and the node set.

[0033] The fifth aspect provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the second aspect.

[0034] A sixth aspect provides a blockchain node including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the second aspect.

[0035] The above-mentioned solution provided in this application, based on the consensus mechanism to ensure the overall consistency and synchronization of the blockchain network, combines blockchain smart contracts to realize distributed key generation. This ensures that the generation of distributed keys is achieved by the cooperation of various participants, and that the generated results are consistent and reliable. This eliminates the strong dependence on network synchronization for distributed key generation outside the original blockchain and solves the problem of unreliability of the generated results in this case. Attached Figure Description

[0036] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a schematic diagram of the conventional stage of a practical Byzantine fault-tolerant algorithm in one embodiment;

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

[0039] Figure 3 This is a schematic diagram of the normal phase of a practical Byzantine fault-tolerant algorithm in one embodiment where none of the consensus nodes have failed;

[0040] Figure 4 This is a flowchart illustrating the generation of a random number seed on a blockchain in one embodiment of this specification;

[0041] Figure 5 This is a schematic diagram of the block header structure in one embodiment of this specification;

[0042] Figure 6 This is a method for implementing distributed key generation on a blockchain in one embodiment of this specification;

[0043] Figure 7 This is a method for implementing distributed key generation on a blockchain in one embodiment of this specification;

[0044] Figure 8 This is an architecture diagram of a blockchain node in one embodiment of this specification. Detailed Implementation

[0045] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0046] The Blockchain 1.0 era typically refers to the period between 2009 and 2014, which marked the beginning of the Blockchain 2.0 era.

[0047] In a blockchain system, different participants can establish a distributed blockchain network through deployed nodes. A decentralized (or multi-centralized) distributed ledger, constructed using a chain-like block structure, is stored on each node (or most nodes, such as consensus nodes) in the distributed blockchain network. Such a blockchain system needs to address the consistency and correctness of the ledger data across multiple decentralized (or multi-centralized) nodes. 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 guaranteeing consistent execution results for the same transactions across all loyal nodes. The transactions and execution results are then packaged into blocks.

[0048] A smart contract is a computer contract that executes automatically based on defined triggering rules; it can also be seen as a digital version of a traditional contract. The concept of smart contracts was first proposed in 1994 by Nick Szabo, a legal scholar and cryptographer working across disciplines. This technology was initially hindered from practical industrial applications due to a lack of programmable digital systems and related technologies, until the emergence of blockchain technology and Ethereum provided a reliable execution environment. Because blockchain technology uses a block-chain ledger, the generated data is immutable and cannot be deleted, and the entire ledger continuously adds data, ensuring the traceability of historical data; at the same time, the decentralized operating mechanism avoids the influence of centralized factors. Smart contracts based on blockchain technology not only leverage the advantages of smart contracts in terms of cost and efficiency but also prevent malicious interference with the normal execution of contracts. By writing smart contracts digitally into the blockchain, the characteristics of blockchain technology ensure that the entire process of storage, retrieval, and execution is transparent, traceable, and tamper-proof.

[0049] The development and applications of blockchain are diversifying. Some business logic is edited into smart contracts and executed on blockchain platforms. Specifically, these smart contracts containing business logic can run on every node (or a majority of nodes, such as consensus nodes) in the blockchain network. Compared to the single point of failure that can render the entire centralized system unusable in a centralized business logic execution environment, executing smart contracts in a blockchain environment is also known as a "world computer" because a distributed blockchain network has many nodes independently executing smart contracts. As mentioned earlier, these smart contracts executing the same logic on different nodes need to obtain the same execution result to ensure that the ledgers stored by a majority of these nodes are consistent.

[0050] Some business logic may require generating a result based on random numbers. For example, this could involve implementing a lottery system or distributing random amounts of money (like red envelopes or blind boxes) within a certain range. This typically requires including a program in the smart contract to generate random numbers. Similarly, some system contracts may need to implement voting on the master node or a small committee, which might use random methods or random numbers. As mentioned earlier, a significant characteristic of distributed blockchain networks is that the ledgers across a majority of nodes must be consistent to ensure the overall availability of the distributed blockchain network. This also necessitates that the random numbers generated by the smart contracts across a majority of nodes be consistent.

[0051] As mentioned earlier, 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, thus guaranteeing consistent execution results for the same transactions. The transactions and execution results are then packaged to generate blocks. Current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT) algorithm, and Honey Badger Byzantine Fault Tolerance (HoneyBadgerBFT) algorithm.

[0052] Taking PBFT as an example, this algorithm, proposed by Miguel Castro and Barbara Liskov in 1999, solved the problem of low efficiency in the original Byzantine fault-tolerant algorithm, reducing the algorithm complexity from exponential to polynomial, making the Byzantine fault-tolerant algorithm feasible in practical system applications. The paper was published at the 1999 International Conference on Operating System Design and Implementation (OSDI99). In the PBFT algorithm, all replicas operate in a succession of configuration process called a view. In a view, one replica acts as the primary node, and the others as backup nodes. Views are consecutively numbered integers. 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 when at most f replicas (i.e., nodes) fail, if there are at least 3f+1 replicas, safety and liveness can be guaranteed in asynchronous systems. To ensure data consistency and fault tolerance across all replicas, a certain number of replicas are needed. This set typically consists of a majority of nodes in the distributed system, forming a majority (Quorum). For example, when 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.

[0053] PBFT includes two processes: the Normal Case Phase and the View Change Phase. Figure 1This is a flowchart of the Normal Case Phase process. The Normal Case Phase mainly includes three stages: PRE-PREPARE, PREPARE, and COMMIT. Node 3 could, for example, represent a node that crashed. Figure 1 (represented by ×). When the master node fails ( Figure 2 The symbol × indicates that if the primary node (i.e., Replica 0) fails before the view is changed, the view change process needs to be initiated to adjust the system when there is a failure and replace the primary node (e.g., Replica 1 becomes the primary node after the view is changed). Figure 2 This is a diagram illustrating the ViewChange Phase. If the master node goes offline or acts maliciously without broadcasting client requests, the client can set a timeout mechanism. If the timeout occurs, the client can broadcast a request message to all replica nodes. If a replica node detects that the master node is malicious or offline, it can also initiate a ViewChange protocol phase to replace the master node (often simply called "master replacement"). Furthermore, the three-phase consensus process of PRE-PREPARE, PREPARE, and COMMIT may fail due to the master node making an incorrect proposal, or the PREPARE and COMMIT phases may fail to reach a consensus on the required number of quorum members (e.g., 2f+1 out of 3f+1 nodes, also known as the quorum). In these cases, a ViewChange protocol phase may also be initiated to replace the master node.

[0054] Under normal circumstances, i.e., no consensus nodes fail and consensus messages reach each other within a certain time, meaning no change of leadership will occur, the Normal Case Phase process in PBFT can proceed as follows: Figure 3 As shown in the diagram, this example still uses 4 consensus nodes.

[0055] In the (r-1)th round of the Normal Case Phase, node 0, as the master node, collects a certain number of transactions to be agreed upon (or read / write sets, which will be explained using transactions as an example later). It then initiates a pre-preparation process (the aforementioned PRE-PREPARE, also known as the PP phase). Nodes 1, 2, and 3 then enter the preparation process (the aforementioned PRE-PREPARE, also known as the P phase). Afterwards, nodes 0, 1, 2, and 3 enter the commit process (the aforementioned COMMIT, also known as the C phase). The PP, P, and C phases are generally referred to as the three phases of PBFT. In this way, under normal circumstances, the three phases of the (r-1)th round of PBFT are completed, achieving consensus on the transaction data corresponding to the (m-1)th block, and generating information such as the block number for this block. Therefore, each consensus node can, based on the consensus transaction data, execute these transactions sequentially according to the order and content of the consensus transaction data, thereby generating the world state and receipt. Specifically, each node can construct a Merkle tree (including MPT trees, which combine Merkle and Patricia trees, a more space-efficient Trie tree) based on consensus-driven transaction data locally, and generate the root hash of this Merkle tree (also known as the transaction root hash). Similarly, a Merkle tree can be constructed based on world state data, and the root hash of this Merkle tree (also known as the state root hash) can be generated. A Merkle tree can also be constructed based on receipt data, and the root hash of this Merkle tree (also known as the receipt root hash) can be generated. After each node generates these three root hashes locally, it can generate the (m-1)th block locally. The block header of the (m-1)th block may include the aforementioned block number, transaction root hash, state root hash, and receipt root hash, while the block body may include a set of transaction data, a set of world states, and a set of receipts. This generates the (m-1)th block.

[0056] During the generation of the m-th block, the three-stage process of PBFT will be repeated. For example... Figure 3In the process, for the m-th block, node 0, as the master node, collects a certain number of transactions awaiting consensus and initiates the PP process. Then, nodes 1, 2, and 3 enter the P process, followed by the C process. This completes the three-phase process of the r-th round of PBFT under normal circumstances, achieving consensus on the transaction data corresponding to the m-th block and generating information such as the block number. Each node can then execute these transactions sequentially based on the consensus transaction data, according to the order and content of the consensus transaction data, thereby generating the world state and receipts. After each node generates the three root hashes as described above locally, it can generate the m-th block locally. The block header of the m-th block can include the aforementioned block number, transaction root hash, state root hash, and receipt root hash, while the block body can include the transaction data set, world state set, and receipt set. This generates the m-th block. Similarly, the (m+1)-th block is generated, and this process includes... Figure 3 The three-stage process of the (r+1)th round of PBFT is shown in the figure.

[0057] As can be seen, under normal block generation conditions, each consensus node includes a PBFT Normal Case Phase process during each block generation. As blocks are continuously generated, each consensus node will repeat this consensus process. Figure 3 The diagram 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.

[0058] A consensus process, specifically a three-phase process of PBFT, may include:

[0059] a110: (PRE-PREPARE pre-preparation phase) After collecting a certain number of transactions to be agreed upon, the master node 0 sorts the transactions to be agreed upon and 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.

[0060] a120: (PREPARE Preparation Phase) After receiving the pre-prepare request, nodes 1, 2, and 3, if the original transaction list is valid, broadcast the hash value of the received message m via a prepare message (the broadcast content generally does not include message m itself, as message m includes several original transaction requests and is generally quite large). Specifically, node 1 propagates the prepare message to nodes 0, 2, and 3; node 2 propagates the prepare message to nodes 0, 1, and 3; and node 3 propagates the prepare message to nodes 0, 1, and 2. Correspondingly, each node also receives prepare messages broadcast by other nodes. Each node adds its own sent prepare message (containing the hash value of message m, representing its own approval) and received prepare messages (containing the hash value of message m, representing the approval of other nodes) to its local log. If a node collects at least Quorum valid pp / p messages from different nodes (including pre-prepare and prepare messages it sends, and prepare messages it receives), it transitions to the prepared state.

[0061] a130: (COMMIT Phase) After entering the prepared state, each node participating in the consensus sends a commit message to the other consensus nodes and adds its own commit message to its local log (representing its own approval). Furthermore, each node also receives commit messages broadcast by other nodes. Once a node has collected at least a Quorum number of valid commit messages from different nodes, it adds them to its local log (at this point, including its own, there are a total of a Quorum number), and transitions to the committed state.

[0062] a140: Nodes that transition to the committed state output message m as the consensus result for this round.

[0063] The selection of transactions in message 'm' and their order are generally determined by the master node in a110. Determining which transactions are included and their order is crucial to the consensus mechanism. A blockchain network may receive numerous transaction requests; the master node in a110 packages these transactions, determining which will be processed and the results recorded on the blockchain. Even with the same set of transactions, different execution orders can lead to different final results, affecting the consistency of the ledgers across different nodes.

[0064] This application provides a method for generating random number seeds on a blockchain, which can be implemented by combining the above-mentioned PBFT three-stage process. For example... Figure 4 As shown, it includes:

[0065] S110: During the commit phase of PBFT, each consensus node uses its own private key share to sign the original message containing the unique values ​​of the original transaction list in this consensus based on the threshold signature algorithm, generates a signature share, and adds the signature share to the broadcast commit message.

[0066] Threshold signatures are an important branch of ordinary digital signatures, combining threshold secret sharing technology with digital signatures. Traditional signature schemes can be implemented using the RSA algorithm. RSA is an asymmetric encryption algorithm proposed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA can decrypt without directly transmitting the key, ensuring information security while avoiding the risk of information being compromised by directly transmitting the key. RSA includes a private key and a public key, which are paired. Information encrypted with the public key can only be decrypted with the corresponding private key; similarly, information encrypted with the private key can only be decrypted with the corresponding public key. This property is due to the mathematical correlation between the paired private and public keys. For example, one underlying principle is based on number theory: finding two large prime numbers is relatively simple, but factoring their product is extremely difficult. Therefore, the product can be made public as the encryption key, thus ensuring security. Private keys are typically kept strictly confidential and cannot be disclosed, while public keys are public (and can be held by multiple people). Because private keys are kept strictly confidential by the holder, others cannot forge the signature of the private key holder without obtaining the private key.

[0067] The RSA signature mechanism guarantees the integrity of messages during transmission. For example, if node A needs to send a message to node B, and it may pass through several intermediate nodes, A can use the RSA signature mechanism to send the message along with its signature through these intermediate nodes to B. B's verification of the signature confirms that the received message was indeed sent by A and has not been tampered with during transmission. One RSA signature process is as follows:

[0068] b1: A generates a key pair (public key and private key). The private key is kept secret and kept confidential. The public key is public and can be obtained by anyone.

[0069] b2: A signs the hash value of the original message using its private key and then passes the original message and the signature result to B. As mentioned earlier, this transmission process may involve forwarding through several intermediate nodes.

[0070] Hash algorithms, also known as hashing algorithms, map original content to a fixed-length sequence, called the hash value. Common hash algorithms include SHA256, SHA384, and SHA512. SHA256 results in 256 bits, representing 2^256 possible original content values. Similarly, SHA384 results in 384 bits, and SHA512 results in 512 bits. These hash algorithms are suitable for large amounts of original content, allowing the hash value to be much smaller than the original content. A good hash algorithm ensures that different original content values ​​have a high probability of mapping to different hash values. This mapping is random, meaning the correlation between hash values ​​obtained from different original content values ​​cannot be predicted; it is also inversely compatible, meaning the original content cannot be derived from the hash value.

[0071] The original message may be lengthy and large in size, making direct signature calculation using the private key time-consuming and computationally expensive. Therefore, a hash algorithm can be used to calculate a hash value from the original message. This hash value is short yet fully represents the original message. Then, the private key is used to encrypt this hash value, and the result is the signature.

[0072] b3: After receiving the message, B uses A's public key to verify the signature.

[0073] On one hand, B can use the same hash algorithm as A to calculate the hash value of the original message, denoted as hash1; on the other hand, B uses A's public key to decrypt the signature result and calculate hash2. If hash1 and hash2 are the same, it can be determined that the received original message was sent by A and has not been tampered with during transmission.

[0074] A threshold signature scheme first comprises one total public key and n public-private key pairs. Each public key in a public-private key pair is called a public key share, and each private key in a public-private key pair is called a private key share. Secondly, there exists a recovery function corresponding to this total public key and the n public-private key pairs. This recovery function can recover a complete signature from signature shares signed with at least a threshold number of different private key shares. The generated complete signature can also be verified for correctness using the single total public key. Signature shares fewer than the threshold number cannot be used to generate the complete signature.

[0075] In addition to the RSA-based threshold signature mechanism, other threshold signature mechanisms that can be used include ECDSA (Elliptic Curve Digital Signature Algorithm), Schnorr (a knowledge proof mechanism based on the discrete logarithm problem), and BLS (Boneh-Lynn-Shacham Signature).

[0076] It's important to note that in threshold signatures used in blockchains, the number of private key shares can be equal to the number of consensus nodes, and the minimum number of signature shares required for the recovery function to generate a complete signature (i.e., the threshold number) can be equal to the quorum in the PBFT algorithm. Of course, the number of private keys may not be equal to the number of consensus nodes, and the minimum number of signature shares required for the recovery function to generate a complete signature may not be equal to the quorum in the PBFT algorithm. The following explanation uses the former as an example.

[0077] The single public key and n public-private key pairs can be generated by a centralized dealer and distributed to n blockchain consensus nodes; this is a centralized key distribution method. Thus, combined with the consensus algorithm, each blockchain consensus node can hold one of the n private key shares. Simultaneously, each blockchain consensus node can hold the same single public key. Alternatively, there is a decentralized key distribution method, where the dealer is eliminated, and the n consensus nodes negotiate n public-private key pairs and one public key through a key negotiation process. Each consensus node still holds one of the n private key shares, and all consensus nodes hold the same public key.

[0078] Using a threshold signature algorithm, each consensus node can use its own unique private key (for example, in a blockchain network with four nodes using PBFT as the consensus algorithm, the private key shares held by nodes 0, 1, 2, and 3 using the threshold signature algorithm are sk0, sk1, sk2, and sk3, respectively, where the subscript numbers represent node numbers) to sign the original message containing the unique values ​​of the original transaction list in this consensus, thus obtaining the signature result. Here, the unique values ​​of the original transaction list can be used as the original message to be signed.

[0079] The unique values ​​of the original transaction list can include the original transaction list itself or its hash value. Generally, different transactions have different content, so different original transaction lists or their hash values ​​are usually different. Therefore, the original message can at least include the original transaction list or its hash value. The properties of the hash function are sufficient to distinguish the random number seeds generated after the consensus process for different blocks is completed.

[0080] Considering that a number is generated for the content of this consensus process, if the consensus is complete, the generated number can be used as the block number of the block corresponding to this consensus. Therefore, the block number (i.e., the identifier) ​​can also be used as content in the original message. Regardless of whether the original transaction list contained in the (N+1)th block is the same as the original transaction table contained in the Nth block, block generation is sequential, which can be reflected as the block number of the later block being the block number of the previous block + 1. Therefore, even if the original transaction list contained in the (N+1)th block is the same as the original transaction table contained in the Nth block, each node still obtains a different signature based on (original transaction list + block number) using its own private key. The master node still cannot know the signatures of other nodes, and thus cannot predict the complete signature of the (N+1)th block. Therefore, the master node cannot use the publicly available random number seed of the Nth block to predict the random number seed of the (N+1)th block, achieving the purpose of unpredictability. Similar to numbering, timestamps are also unique to a block, with the timestamp of a later block following that of the previous block. Therefore, timestamps can also be used as content within the original message.

[0081] In addition to the unique values ​​of the original transaction list, the signing object can also include other content, such as the random number seed generated in the previous block. That is, the original message can also include the random number seed generated in the previous block. After the aforementioned a140 is executed, as mentioned earlier, each node can generate the m-th block based on the consensus transaction data. Since the m-th block is generated independently by each node locally, if the blockchain nodes do not broadcast and compare the hash values ​​of their generated previous blocks, each node may not be able to determine whether the m-th blocks generated in the blockchain network are the same, or whether, from the perspective of the overall usability of the blockchain system, at least a quorum of consensus nodes have generated the same m-th block. Through the random number seed generation process in this application, the random number seeds of the same block should be the same, and the random number seeds of different blocks should be different. Therefore, the random number seed can be added to the original message. Thus, if the random number seeds for the m-th block generated by each node are different, due to the nature of the threshold signature algorithm, it may be impossible to obtain a complete signature through the recovery function during the generation of the random number seed for the (m+1)-th block. Therefore, the scheme in this application can help consensus nodes confirm whether the previous block is consistent. Alternatively, the hash value of the previous block can be used instead of the random number seed. Since the hash value of a block is generally unique, this can also help consensus nodes confirm whether the previous block is consistent.

[0082] The original message containing unique values ​​from the original transaction list used in this consensus is signed using one's own private key share. These unique values ​​can be from the original transaction list itself. Generally, the original transaction list has already been broadcast during the PP phase of PBFT, and smaller commit messages broadcast during the C phase are more conducive to propagation and bandwidth saving. Therefore, the unique values ​​from the original transaction list can be the hash values ​​of the original transaction list.

[0083] If the original message contains multiple elements, such as the hash value of the original transaction list, the block number, and the random number seed generated in the previous block, the hash value of the original message can be calculated first, and then the hash value of the original message can be signed using the private key share to obtain the signature result.

[0084] The original message is signed, and the generated signature, along with the original message, can be added to the broadcast commit message. Thus, during the commit phase, each node participating in the consensus sends a commit message to the other consensus nodes and adds its own commit message to its local log (representing its own approval). Furthermore, each node also receives commit messages broadcast by other nodes.

[0085] S120: After each consensus node collects at least a threshold number of commit messages, it uses the verification of at least a threshold number of signature shares and the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain a complete signature.

[0086] As mentioned earlier, in application, the threshold signature algorithm can generate a total public key and n public-private key pairs, and can also generate recovery functions corresponding to these n public-private key pairs. As previously mentioned, this recovery function can recover a complete signature from at least a threshold number of correctly verified signatures. The threshold value, i.e., the threshold number, of the threshold signature algorithm can be set to w. Of course, even if there are more than w correct signatures, a complete signature can still be generated using this recovery function. In other words, whenever the number of correct signatures is greater than or equal to the threshold number w, a complete signature can be generated using this recovery function, and this generated complete signature is deterministic and will not change due to the number of correct signatures input (as long as it is greater than or equal to w).

[0087] The generated complete signature can be verified for correctness using the aforementioned master public key. Thus, any node holding this master public key can use it to verify the correctness of the complete signature. For example, after generating the complete signature, node 1 can use the master public key to verify its integrity. This involves performing cryptographic operations on the complete signature using the master public key to obtain a first hash, and then performing a hash operation on the original message to obtain a second hash. If the first hash matches the second hash, the integrity of the complete signature is confirmed. This integrity includes the fact that the complete signature is specific to the original message and that the original message has not been tampered with. As another example, after generating the complete signature, node 1 can send the complete signature, the master public key, and the original message to a device outside the blockchain. This device can then use the master public key and the original message to verify the correctness of the complete signature, following the same principle. The original message text here still contains the aforementioned content unique to the original transaction list in this consensus, or may also include the block number of the current block and / or the timestamp and / or the random number seed generated in the previous block.

[0088] Alternatively, each consensus node can collect each commit message, verify the signature share in the received commit message using the corresponding public key share, and then use the recovery function corresponding to the private key share generated by the threshold signature algorithm to obtain the complete signature. Compared to verifying the generated complete signature using the total public key, verifying each signature share using the public key share, and then restoring the complete signature using the recovery function after successful verification, can determine which signature is erroneous, thereby identifying which node might be a malicious node.

[0089] In the threshold signature algorithm, each consensus node has a total public key and one private key share and one corresponding public key share from n public-private key pairs. As mentioned earlier, these can be generated and distributed by the dealer or negotiated by the consensus nodes.

[0090] Each consensus node can verify the signature share in the received commit message using its corresponding public key share. Specifically, for example, in a consortium blockchain using the PBFT consensus algorithm with four consensus nodes, node 0 broadcasts its generated signature share σ to nodes 1, 2, and 3 in S110. 3,0 , where σ 3,0 The subscript 3 can represent the block number, and 0 can represent that this is the signature share of node 0; in S120, node 0 also receives the signature shares σ broadcast by nodes 1 and 2 respectively. 3,1 σ 3,2 Thus, node 0 has collected at least 3 signature shares, including the signature share σ broadcast by itself. 3，0 The signature share σ broadcast by nodes 1 and 2 3，1 σ 3，2 Of course, node 0 can also collect all the signature shares σ. 3，0 σ 3，1 σ 3，2 and σ 3，3 This also satisfies the minimum number of quorums.

[0091] Furthermore, node 0 can use the corresponding public key share to verify the collected σ. 3，0 σ 3，1 σ 3，2 Or may also include σ 3，3 (or σ) 3，0 σ 3，1 σ 3，3 Or may also include σ 3，2 Or σ 3，1 σ 3，2 σ 3，3 Or may also include σ 3，0 Or σ 3，0 σ 3，2 σ 3，3 Or may also include σ 3，1 The correctness of the signature share σ. Specifically, for example, node 0 can use the corresponding public key share to verify the signature share σ. 3，1 The calculation yields a hash value, which is denoted as hash. 3，1 Node 0 can also perform the same hash calculation on the original message to obtain hash′. 3，1 If hash 3，1 With hash′ 3，1If they are equal, it proves that the original message was sent by node 1 and was not tampered with during transmission. Thus, σ 3，1 The correctness of this has been verified. Similarly, node 0 can be related to σ. 3，2 Further verification will be conducted later, and will not be elaborated upon further.

[0092] Similarly, node 1 can use the corresponding public key share to verify the collected σ. 3，0 σ 3，1 σ 3，2 Or may also include σ 3，3 (or σ) 3，0 σ 3，1 σ 3，3 Or may also include σ 3，2 Or σ 3，1 σ 3，2 σ 3，3 Or may also include σ 3，0 Or σ 3，0 σ 3，2 σ 3，3 Or may also include σ 3，1 The correctness of ).

[0093] Similarly, node 2 can use the corresponding public key share to verify the collected σ. 3，0 σ 3，1 σ 3，2 Or may also include σ 3，3 (or σ) 3，0 σ 3，1 σ 3，3 Or may also include σ 3，2 Or σ 3，1 σ 3，2 σ 3，3 Or may also include σ 3，0 Or σ 3，0 σ 3，2 σ 3，3 Or may also include σ 3，1 The correctness of ).

[0094] Similarly, node 3 can use the corresponding public key share to verify the collected σ. 3，0 σ 3，1 σ 3，2 Or may also include σ 3，3 (or σ) 3，0 σ 3，1 σ 3，3 Or may also include σ 3，2 Or σ 3，1 σ 3，2 σ 3，3 Or may also include σ 3，0 Or σ 3，0 σ 3，2σ 3，3 Or may also include σ 3，1 The correctness of ).

[0095] S130: Each consensus node obtains a random number seed based on the complete signature.

[0096] A random number seed is the initial value used in a pseudo-random number generator to generate pseudo-random numbers. For a single pseudo-random number generator, starting from the same random number seed will yield the same sequence of random numbers. For a single machine, the random number seed can be determined by the current state of the computer, such as the current time. However, for a distributed system, the same random number seed must be generated on all nodes to ensure that the same random numbers are generated based on the same seed in system contracts / business contracts / blockchain platform functions, and that no single node should generate random numbers in a controllable, predictable, and reversible manner. This requires the seed to be jointly determined by the nodes participating in the consensus. Furthermore, considering that distributed networks are often asynchronous or semi-synchronous, for immediacy, random numbers need to be generated and used as soon as transactions in the current block are executed.

[0097] Following steps S110-S120 above, under normal circumstances, each consensus node can obtain the same complete signature. Of course, considering the fault tolerance characteristics of distributed systems, in a blockchain network using the PBFT consensus algorithm, there should be at least a quorum number of consensus nodes, each of which can obtain the same complete signature.

[0098] In this way, based on the complete signature, each consensus node can use the same random number seed generation algorithm to generate a random number seed. A relatively simple random number seed generation algorithm is, for example, the SHA256 algorithm. Of course, the complete signature can also be used directly as the random number seed.

[0099] After the above process, a random number seed can be generated on the blockchain.

[0100] In this way, during the process of blockchain nodes outputting consensus results after completing the current consensus process—that is, during the execution of a series of transactions with determined content and order—if the code includes smart contracts / system contracts / blockchain platform code that require the use of random numbers, it can be executed based on the S130 random number seed. For example, in smart contracts written in C++, the `mt19937(r)` method provided by the C++ standard library or the Boost library can be used to construct a cross-platform consistent random number engine, where the parameter `r` is the random number seed. Similarly, the `random` library in Python and Java also provides similar random number generation methods. Based on the same random number seed, the same random numbers can be generated using the same random number generation algorithm. Thus, for example, when each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random numbers based on the same random number seed, thereby completing business logic such as lotteries, red envelopes, and blind boxes, or completing system contract / blockchain platform functions, and obtaining consistent execution results on each node.

[0101] In addition, based on the above scheme, the following steps can also be included: each consensus node puts the obtained random number seed into the block header of the generated current block.

[0102] For example, Ethereum Figure 5 This is a schematic diagram of the block header structure of a block. Figure 5 In the structure shown, each block's header includes several fields, such as the previous block hash (prevHash in the diagram), a nonce (this is the random number involved in proof-of-work, different from the random number seed in this application, and not used in some Ethereum-based consortium blockchains), a timestamp, the previous block number (Block Num), a state root hash (State Root), a transaction root hash (Transaction Root), and a receipt root hash (Receipt Root). The Prev Hash in the header of the next block (e.g., block N+1) points to the previous block (e.g., block N), which is the hash value of the previous block, and also the hash value of the previous block's header. The hash value of the block header can be calculated by concatenating the fields in the block header sequentially using a certain hash algorithm. In this way, the blockchain achieves the locking of the previous block by the next block through the block header. Specifically, as mentioned earlier, the state root is the hash value of the root of the MPT tree composed of the states of all accounts in the current block, and the pointer to the state root is a statetrie in MPT form.

[0103] Transaction Root is generally the hash value of the root node of the original transaction list contained in this block after it is organized into a tree structure. Receipt Root is generally the hash value of the root node of all receipts generated after the transactions contained in this block are executed and organized into a tree structure.

[0104] It's important to note that this application can add a field to the block header—"random number seed," which is the random number seed in S130. This way, the random number seed generated in this block can be recorded on the blockchain ledger. Furthermore, for replaying blocks, transactions involving random numbers in the block can be replayed according to the random number seed in the block header.

[0105] The above-mentioned scheme provided in this application combines the threshold signature algorithm with the PBFT consensus algorithm, so that after the original transaction list corresponding to each block reaches consensus through the PBFT algorithm, it can obtain a complete signature through the threshold signature algorithm and thus obtain a random number seed. During the execution of transactions in the original transaction list corresponding to this block, the random number can be used. In this way, no additional waiting is required to execute the transactions in this block.

[0106] The above-mentioned scheme provided in this application, based on the nature of the threshold signature algorithm, allows each consensus node to recover the same complete signature through a recovery function based on at least a threshold number of signature shares, thereby generating the same random number seed. Thus, when each blockchain node executes the same transaction in the same block, the same random number generation process can generate the same random number based on the same random number seed, thereby completing business logic such as lottery, red envelope distribution, and blind box, or completing system contract / blockchain platform functions, and obtaining consistent execution results on each node.

[0107] The scheme provided in this application combines the threshold signature algorithm with the PBFT consensus algorithm, making it impossible for any consensus node to predict the complete signature before consensus is achieved. Even the PBFT master node cannot predict the complete signature, and therefore cannot predict the random number seed and random number. In particular, when the threshold equals the quorum, once consensus is achieved, since the quorum number of nodes have reached a consensus on the content and order of the transaction list, that is, the basic content for generating a new block has been determined, at least the quorum number of nodes will obtain the same complete signature according to the recovery function. The random number seed generated by these quorum number of nodes will also necessarily be the same. Even if no more than f nodes act maliciously and try to control or revoke the obtained random number seed, these f nodes will not affect the consistency of the system. That is, these f nodes cannot manipulate or revoke the generated complete signature, random number seed, and random number.

[0108] The method in this application can be implemented during the generation of each block, so that the block header of each block can include a random number seed field. Even if the block body of a block does not contain transactions involving random numbers, the generation process of that block can still include the process of generating a random number seed.

[0109] As mentioned earlier, threshold signature algorithms can employ RSA-based, ECDSA-based, Schnorr-based, or BLS-based threshold signature mechanisms, among others. Generally, these algorithms require generating one total public key and n public-private key pairs. In a typical and concise implementation, the number of private key shares can equal the number of consensus nodes, with each node holding one private key, i.e., one private key share. Thus, each consensus node, based on the threshold signature algorithm, uses its own private key share to sign the original message to generate a signature share. The minimum number of signatures (i.e., the threshold number w) required for the recovery function to generate a complete signature can be equal to the quorum in the PBFT algorithm. This means that at least w signature shares can generate a definite complete signature using the corresponding recovery function, regardless of which w of the n signature shares are used, as long as these at least w signatures are signatures made to the same original message using their respective correct private key shares.

[0110] To implement threshold signature algorithms on blockchain consensus nodes, a mechanism is needed to ensure that each of the n consensus nodes has one private key share and one corresponding public key share, all sharing the same master public key. As mentioned earlier, this could be generated by a centralized dealer and distributed to the n blockchain consensus nodes; this is a centralized key distribution method. This centralized method requires a third-party dealer, which must be compliant with malicious intent. For example, a distributed key generation protocol implementation, in principle, needs to generate a polynomial of degree t, then extract n points from the curve formed by this polynomial, generate n private key shares from these n points, and distribute them to the n participants in the threshold signature process. If this process is performed by a single dealer, and this dealer acts maliciously, it can obtain the private key shares of all n participants, which violates the security requirements of a blockchain system.

[0111] Furthermore, there are decentralized key generation and distribution methods, which eliminate the dealer and instead have n consensus nodes negotiate n public-private key pairs and one master public key through a key negotiation process. Each consensus node still holds one of the n private key shares, and all consensus nodes hold the same master public key. Traditionally, this approach is implemented outside the blockchain and relies on network synchronization. Nodes on the blockchain constitute a distributed network, which is generally semi-synchronous or asynchronous. Therefore, implementing key generation and distribution between nodes in a distributed network outside the blockchain is unreliable. However, achieving a reliable distributed key protocol is a crucial prerequisite for generating random number seeds on the blockchain.

[0112] The aforementioned PBFT protocol is a semi-synchronous protocol, characterized by the assumption that the network is initially asynchronous but can synchronize at a certain point. The simplest way to achieve consensus among different nodes on the same proposal is to set a master node to unify the opinions of all nodes. Timers can be used to prevent the master node from malfunctioning. In PBFT, if the Normal Case Phase is not completed within a finite time, Backups will initiate a View Change Phase to replace the master node. PBFT fixes the master node in one position, and all requests can be sent to the master node first, which then broadcasts them to other consensus nodes. In contrast, the HoneyBadgerBFT algorithm (often abbreviated as HBBFT) is an asynchronous protocol. Asynchronous protocols are suitable for asynchronous networks, where messages between nodes can be arbitrarily delayed but will eventually arrive. HoneyBadgerBFT eliminates timers, instead using messages to drive protocol execution. Furthermore, all nodes in the HoneyBadgerBFT algorithm are equal; there is no distinction between master and backup nodes, and therefore no master-slave transition. Asynchronous network consensus protocols such as HBBFT do not have the concept of a master node. Each node can propose requests and attempt to construct blocks. Therefore, asynchronous network protocols alleviate the problems of fairness and single-node bottlenecks to a certain extent.

[0113] For example, Chinese patents ZL202111175184.1, ZL202111178795.1, ZL202111178745.3, ZL202111178754.2, ZL202111175144.7, ZL202111175151.7 and Chinese patent application CN202111178779.2 all propose new consensus algorithms while taking into account the characteristics of semi-synchronous or asynchronous blockchain networks.

[0114] Through various consensus mechanisms within a blockchain network, the overall consistency and synchronization of the blockchain network can be guaranteed. For the latter, as long as the blockchain continues to produce blocks, block synchronization can be achieved. Therefore, combining blockchain with distributed key generation will be reliable.

[0115] Figure 6 This is a flowchart illustrating a method for implementing distributed key generation on a blockchain, as described in an embodiment of this specification. This method can be executed by multiple nodes in the blockchain, including:

[0116] S610: Each node generates a unique set of n secret shares, keeps one for itself, and encrypts and sends the n-1 secret shares to the other n-1 nodes respectively.

[0117] The methods described below, using a consensus node as an example, illustrate the embodiments of this specification. It is understood that the embodiments of this specification are not limited to executing the method through a consensus node, but can be executed through other nodes (e.g., non-consensus nodes).

[0118] In the DKG algorithm, nodes are renumbered, starting from 1. To maintain consistency with the DKG algorithm, consensus nodes will also be numbered starting from 1.

[0119] Elliptic Curve Cryptography (ECC) is a public-key cryptography technique based on elliptic curve theory. It leverages the discrete logarithmic difficulty of the Abelian group formed by points on an elliptic curve over a finite field to achieve encryption, decryption, and digital signatures. The following explanation uses an elliptic curve as an example. Each node can be found in the group Z... q A polynomial of degree t is randomly selected. The Nth degree polynomial function is uniquely determined by N+1 points, because ultimately quorum consensus nodes in the blockchain network are needed to recover the signature, so quorum = N+1, and therefore the degree t of the polynomial is quorum-1. In this way, a complete signature can be recovered from quorum (quorum = t+1) signature shares using the recovery function. Of course, t can also be set to other values. The elliptic curve constructed using this polynomial can be represented as follows:

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

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

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

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

[0124] Node 1 can randomly select a set of numbers from a finite prime field as coefficients, i.e., as a. 10 a 11 a 12 The generated polynomial is: f1(z) = a 10 +a 11 z+a 12 z 2 .

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

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

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

[0128] Each node, based on a defined polynomial, can further determine a set of secret shares. The secret shares can be determined from the polynomial coefficients using the following formula:

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

[0130] In formula (3), q is the same large number used by each node for f. i (j) The purpose of using q as the modulus is to make f i The value of (j) is limited to the range [0, q-1]. For example:

[0131] 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. Here, the 4 secret shares represent the total number of consensus nodes. In other words, to ultimately achieve the goal of generating a complete signature by taking any w from the n signature shares and then using the recovery function, n secret shares need to be generated. The same applies below.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] Furthermore, in addition to retaining its own secret share, each node can exchange other secret shares generated with other consensus nodes through a P2P network. Specifically, this can be done as follows:

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

[0137] Consensus node 2 retains S 22 , will S 21 Send to node 1, and send S 23 Send to node 3, and send S 24 Sending to node 4 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 2 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0138] Consensus node 3 retains S 33 , will S 31 Send to node 1, and send S 32 Send to node 2, and send S 34 Sending to node 4 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 3 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0139] Consensus node 4 retains S 44 , will S 41 Send to node 1, and send S 42 Send to node 2, and send S 43 Sending to node 3 can be done through the underlying P2P network components in the blockchain network. Similarly, the sent secret share needs to be kept confidential. Consensus node 4 can encrypt the secret share to be sent using the recipient's public key before sending it to the recipient, or send it to the recipient through a secure connection such as TLS.

[0140] As you can see, the two numbers in the subscript of the secret share represent the node number that issued the secret share (left) and the node number that received the secret share (right). Thus:

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

[0142] Consensus node 2 has a different secret share S generated by different nodes locally. 12 S 22 S 32 S 42 ;

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

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

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

[0146] Ideally, consensus nodes should sign the secret share to be sent, for example, using their own private key or a MAC (Message Authentication Code), to ensure message integrity and prevent man-in-the-middle attacks. Correspondingly, the node receiving the secret share can verify the correctness of the signature.

[0147] In one implementation, each consensus node can provide n-1 secret shares to the other n-1 nodes by sending a transaction. Specifically, each consensus node generates a transaction that invokes a contract (e.g., a DKG contract). The input parameters to the DKG contract in this transaction include the ciphertext of n-1 of the n secret shares it generates. The ciphertext of the n-1 secret shares is generated by encrypting them separately using the public keys of the other n-1 nodes. The consensus node then sends the generated transaction to the blockchain. Through the execution of the contract, the ciphertext of the n-1 secret shares can be stored in the receipt of the transaction. Other consensus nodes can retrieve the receipt from the blockchain, thereby obtaining the ciphertext of the secret shares corresponding to their respective consensus nodes within the ciphertext of the n-1 secret shares.

[0148] S620: Each node generates public verification parameters corresponding to its own secret share and broadcasts them through the DKG contract.

[0149] Each consensus node can generate a set of verification parameters corresponding to its own key share. The generation method can use the following formula:

[0150]

[0151] In formula (4), g is a base point on the elliptic curve. According to the operational properties of elliptic curves, a power of g is also a point on the elliptic curve. t is the degree of the polynomial, typically set to (quorum-1). As mentioned earlier, to ultimately achieve the goal of generating a complete signature from any w signatures selected from n signature shares using the recovery function, the degree of the polynomial needs to be set to t, where t = w-1. The same applies below.

[0152] Based on the above formula (4), let t = 2, and the set of verification parameters generated by consensus node 1 is as follows: 10 A 11 A 12 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 2 generates a set of verification parameters as follows: 20 A 21 A 22 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 3 generates a set of verification parameters as follows: 30 A 31 A 32 This set of verification parameters is broadcast via an on-chain contract. Similarly, based on the above formula, consensus node 4 generates a set of verification parameters as follows: 40 A 41 A 42 > This set of verification parameters is broadcast via an on-chain contract.

[0153] Based on the properties of cryptography, A ik Even if it's published, it won't lead to the derivation of a. ik Therefore, even if the published A is obtained from the chain... ik It is also impossible to obtain the polynomial in S610.

[0154] ​​​​Through on-chain contract broadcasting, specifically, each node can sign a transaction with its own private key and send it to the blockchain. Each node can have a built-in blockchain SDK (Software Development Kit). An SDK is a collection of program interfaces, documentation, examples, development tools, etc. With a built-in SDK, a blockchain node can initiate transactions to the blockchain network like a blockchain client. Transactions signed by a blockchain node with its own private key can contain calls to smart contracts on the blockchain. The called contract, for example, is a DKG contract. This DKG contract can be a system-level contract, that is, a contract pre-deployed on the blockchain, such as a contract created by an account with system administrator privileges, providing system-level control functions, rather than a contract developed and deployed by the user to implement specific business logic.

[0155] Like other contracts, DKG contracts can be executed in a virtual machine (such as the Ethereum Virtual Machine, EVM) or a container (such as Docker); the limitations are not specified. An external account initiates a transaction to the blockchain to invoke an on-chain contract, triggering the contract's execution. The transaction's `f` field includes fields such as `from`, `to`, `value`, and `data`. The `from` field can be the account address of the transaction initiator, the `to` field can represent the address of the smart contract being invoked, the `value` field can be a native token on the blockchain (such as the value of Ether in Ethereum), and the `data` field can contain the method and parameters for invoking the smart contract. By specifying the address of the smart contract to be invoked in the `to` field, it indicates that a call is being made to a specific smart contract on the blockchain. A smart contract typically includes one or more functions, each of which can include some input parameters. The `data` field in the transaction specifies the function within the smart contract to be invoked and contains the required parameters.

[0156] The outcome of contract execution can alter the contract's storage, i.e., its world state. Furthermore, the transaction's execution result or related information can be recorded in a blockchain receipt. Specifically, the contract execution result / related information can be represented as events within the receipt. An event's structure might look like the following format:

[0157] Event:

[0158] [topic][msg]

[0159] [topic][msg] ......

[0161] In the example above, there can be one or more events. Each event can include fields such as topic and data. The format of the events output during transaction execution can be specified in the contract. Through the built-in SDK, blockchain clients or blockchain nodes can listen for events on specific topics, and upon detecting events on a specific topic, retrieve the content of the corresponding message, and perform preset processing after listening for certain content from a specific topic or the corresponding message.

[0162] Through this event mechanism, nodes can store execution results in the `msg` field corresponding to a specific topic, allowing listeners of that topic (i.e., clients with the built-in blockchain SDK or blockchain nodes) to obtain the corresponding execution results. In S620, a node can transmit the generated public verification parameters to the blockchain network by initiating a call to the first function in the DKG contract (e.g., a function named Broadcast, which may include parameters, including public verification parameters). One result of the blockchain network executing this transaction is that the public verification parameters are placed into the `msg` field corresponding to the specific topic in the receipt. Nodes listening to that topic can then obtain the content of the `msg` field, i.e., obtain the public verification parameters. This completes the on-chain contract broadcast.

[0163] You can register events to listen for with a blockchain node via an SDK. Specifically, the blockchain node can bind a hook function to the generated events in the running blockchain platform code (the hook function can be edited along with the platform code during the development phase). This hook function is a callback function that can be called when the listened-for event occurs and can execute certain processing logic. The listening code can include, for example, listening to the transaction content of blockchain transactions, the contract state of smart contracts, receipts generated by contracts, or one or more other things. After registering the listening events with the blockchain node via the SDK, the blockchain node can maintain a mapping relationship between the listened-for events and the listeners (e.g., the network connection of the client / node that has embedded the SDK and initiated event listening, which generally includes information such as IP address and port number). For example, it can maintain a mapping relationship between listening to a specific event of a specific contract and the listeners. When the hook function detects that the corresponding event topic has occurred, it can be called, and the hook function can then query the mapping relationship and push the listened-for event to the network connection. In this way, the SDK that initiated the listening can obtain the listened-for events through the maintained network connection. Contract execution is also implemented in a similar way through on-chain contract broadcasting. Specifically, the execution results of the contract and other transactions in the same block are stored in a transaction result cache area of ​​the blockchain node. Once all transactions in the blockchain have been executed and organized into a block, the blockchain platform code can listen to the receipts in the transaction results and broadcast the monitored events to the SDK that initiated the listening. Here, through this listening mechanism, nodes can listen to registered events for specific topics, and when such events occur, they can obtain the corresponding message (msg) for that topic through the maintained connection, thus obtaining the content of the message, which includes public verification parameters. In short, the blockchain's event mechanism can be used to broadcast public verification parameters, and the event listening mechanism can be used to receive the broadcast content.

[0164] Thus, the result of broadcasting the public verification parameters generated by each node on the blockchain can be as follows:

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

[0166] Consensus node 2 has a different secret share S generated by different nodes locally. 12 S 22 S 32 S 42 and verification parameters 20 A 21 A 22 > and can obtain public verification parameters from the chain. 10 A 11 A 12 >, 30 A 31 A 32 >, 40 A 41 A 42 >;

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

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

[0169] ​​​​​​​​​​​​S630: Each consensus node verifies each received secret share and its corresponding public verification parameters.

[0170] Each consensus node can receive secret shares from any other node and receive public verification parameters broadcast by the on-chain contract.

[0171] As mentioned in S610 above, each consensus node generates n secret shares S. ij Each node retains one copy and sends its n-1 secret shares, encrypted, to the other n-1 nodes via a P2P network component. As mentioned in S620 above, each node generates public verification parameters corresponding to its own secret share and broadcasts them via an on-chain contract.

[0172] If the secret share issued by each node and the corresponding public verification parameter belong to the same polynomial, then the following equation should hold:

[0173]

[0174] As mentioned before, t = quorum - 1; when n = 4, quorum = 3, and at this time t = 2.

[0175] Based on the property of formula (5), this formula can be used to verify each received secret share and public verification parameter. 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 check whether the node that generates the secret share and the corresponding public verification parameter has engaged in malicious behavior. A typical malicious behavior is, for example, a node generating S based on the first polynomial. ij However, A was generated using different polynomials. ik (k = 0, ..., t).

[0176] The above verification, specifically:

[0177] When j=1, that is, consensus node 1 can verify the following:

[0178] i=1: (In fact, consensus node 1 does not need to verify whether this equation holds, because the secret share S) 11 and verification parameters 11 A 12 A 13 >All are generated by themselves)

[0179] i = 2:

[0180] i = 3:

[0181] i = 4:​

[0182] When j=2, that is, consensus node 2 can verify the following:

[0183] i=1:

[0184] i = 2: (In fact, consensus node 2 does not need to verify whether this equation holds, because the secret share S) 22 and verification parameters 20 A 21 A 22 >All are generated by themselves)

[0185] i = 3:

[0186] i = 4:

[0187] When j=3, that is, consensus node 3 can verify the following:

[0188] i=1:

[0189] i = 2:

[0190] i = 3: (In fact, consensus node 3 does not need to verify whether this equation holds, because the secret share S) 33 and verification parameters 30 A 31 A 32 >All are generated by themselves)

[0191] i = 4:

[0192] When j=4, that is, consensus node 4 can verify the following:

[0193] i=1:

[0194] i = 2:

[0195] i = 3:

[0196] i = 4: (In fact, consensus node 4 does not need to verify whether this equation holds, because the secret share S) 44 and verification parameters 40 A 41 A 42 >All are generated by themselves)

[0197] ​​​S640: After each node passes each verification, it records the node number that passed the verification.

[0198] After each verification is successful, each node does not immediately send the verified node number (i.e., the number of the node that provided the public verification parameters) to the DKG contract via a transaction. Instead, it only records the verified node number locally, thus storing the set of verified node numbers locally. For example, the set of verified node numbers can be stored in memory.

[0199] In S650: When each node meets the preset rules, it sends the set of recorded verified node numbers to the contract; wherein, the contract determines the node set based on the node numbers sent by each consensus node.

[0200] Each node may send a transaction to the blockchain to invoke the DKG contract when it determines that at least one of the following rules is met, in order to send a set of node IDs to the DKG contract:

[0201] The number of verified node IDs recorded by a node has reached n-1, meaning that the node has received all the common verification parameters sent by all n-1 nodes and has successfully verified all n-1 common verification parameters.

[0202] If a node does not receive a secret share from other nodes within k consecutive blocks, the node will terminate its waiting after a preset time (in blocks).

[0203] Each node could be, for example, a function that initiates a call to DKG to verify the success of the node (e.g., named confirm(v), where the parameter v is, for example, a set of confirmed node numbers).

[0204] For example, after consensus node 1 determines that the preset rules are met, it can initiate a transaction to call the DKG contract. The transaction to call the contract includes a set of verified node numbers, such as the numbers of node 2, node 3, and node 4, to indicate that the secret shares and corresponding public verification parameters issued by node 1 to nodes 2, 3, and 4 have passed the verification. Similarly, it can initiate a call to the confirm(v) function in the DKG contract.

[0205] After consensus node 2 determines that the preset rules are met, it can initiate a transaction to call the DKG contract. The transaction to call the contract includes a set of verified node numbers, such as the numbers of node 1, node 3 and node 4.

[0206] After determining that the preset rules are met, consensus node 3 can initiate a transaction to call the DKG contract. This transaction includes a set of verified node numbers, such as the numbers of node 1, node 2, and node 4.

[0207] After determining that the preset rules are met, consensus node 4 can initiate a transaction to call the DKG contract. This transaction includes a set of verified node numbers, such as the numbers of node 1, node 2, and node 3.

[0208] In this way, the DKG contract can collect confirmations from at least quorum (e.g., 2f out of n participating DKG nodes, where f is the number of malicious nodes allowed according to the PBFT algorithm) nodes that node 1 has passed verification. Therefore, it can be assumed that the secret share issued by node 1 and its corresponding public verification parameters belong to the same polynomial. The DKG contract can similarly determine whether the secret shares issued by other nodes and their corresponding public verification parameters belong to the same polynomial.

[0209] In the embodiments described in this specification, after each node successfully verifies a secret share, it does not immediately send a confirmation transaction to send the verified node number to the DKG contract. Instead, it first collects a set of verified node numbers locally, and then sends all node numbers in the verified node number set to the DKG contract in a single transaction. Compared to related technologies, this significantly reduces the number of transactions in the blockchain. For example, the set of verified nodes can include at most n-1 node numbers. Compared to related technologies that send each node number separately through n-1 transactions, this embodiment only requires one transaction, thus reducing the number of transactions by n-2.

[0210] Furthermore, the contract can determine the node set based on the node numbers sent by each consensus node.

[0211] For example, the DKG contract can determine the node set based on transaction verifications sent by each consensus node. Specifically, for a given node, if the DKG contract receives confirmations from at least quorum of other nodes, then the DKG contract adds the confirmed node to the node set. This set could be, for example, the QUAL set.

[0212] For example, if the DKG contract receives confirmation from at least two of nodes 2, 3, and 4 regarding node 1, then the DKG contract adds node 1 to the QUAL set; similarly, if the DKG contract receives confirmation from at least two of nodes 1, 3, and 4 regarding node 2, then the DKG contract adds node 2 to the QUAL set; similarly, if the DKG contract receives confirmation from at least two of nodes 1, 2, and 4 regarding node 3, then the DKG contract adds node 3 to the QUAL set; similarly, if the DKG contract receives confirmation from at least two of nodes 1, 2, and 3 regarding node 4, then the DKG contract adds node 4 to the QUAL set.

[0213] After the execution of the above contract, the QUAL set will include, for example, a node set of {1,2,3,4}.

[0214] When executing a transaction that calls the DKG contract for confirmation, the DKG contract determines the node numbers of the quorum of nodes in the node set. The DKG contract can then confirm that DKG can proceed to the next stage. Therefore, the DKG contract can record an end event in the receipt of the transaction to instruct each node to carry out the subsequent steps (i.e., step S660).

[0215] It's important to note that in blockchain networks, due to the semi-synchronous or asynchronous nature of the network, contract execution doesn't necessarily occur within the same block. Instead, it may be performed in parts across different blocks. In such cases, a state machine can typically be set up within the contract, allowing the state machine to transition as a part of the execution is completed, or until the state machine reaches a certain final state. Each step of the state machine execution can be triggered upon receiving a transaction. Therefore, the set of nodes determined by the DKG contract in this step may span multiple blocks.

[0216] S660: Each node obtains the node set, calculates its public key share based on the verification parameters and the node set, and calculates its own private key share based on its local secret share and the node set.

[0217] After each consensus node detects the DKG's end event from the blockchain, each node can calculate its public key share locally based on the verification parameters and the node set in the contract. This public key share can be calculated using the following formula:

[0218]

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

[0220]

[0221] Similarly, the public key share calculated by consensus node 2 could be:

[0222]

[0223] Similarly, the public key share calculated by consensus node 3 could be:

[0224]

[0225] Similarly, the public key share calculated by consensus node 4 could be:

[0226]

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

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

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

[0230]

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

[0232]

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

[0234]

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

[0236]

[0237] It is evident that the private key shares calculated by nodes 1, 2, 3, and 4 are not the same.

[0238] 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:

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

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

[0241] Thus, for example, consensus node 1 can calculate the total public key as follows:

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

[0243] Similarly, for example, consensus node 2 can calculate the total public key as follows:

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

[0245] Similarly, for example, consensus node 3 can calculate the total public key as follows:

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

[0247] Similarly, for example, consensus node 4 can calculate the total public key as follows:

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

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

[0250] The aforementioned 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 earlier, each public key share can be used to verify the signature share generated by the corresponding private key share. Moreover, a complete signature recovered by the recovery function from the signature shares generated by at least quorum private key shares can be verified by the corresponding total public key.

[0251] By using the above method, on the basis of ensuring the overall consistency and synchronization of the blockchain network through the consensus mechanism, distributed key generation is achieved by combining blockchain smart contracts. This ensures that the generation of distributed keys is achieved by the cooperation of various participants, and that the generated results are consistent and reliable. This eliminates the strong dependence of distributed key generation outside the original blockchain on network synchronization and solves the problem of unreliability of the generated results in this case.

[0252] Figure 7 This is a flowchart illustrating a method for implementing distributed key generation on a blockchain from the perspective of a single node, as described in the embodiments of this specification. The method, for example, is executed by a first node and includes:

[0253] In S710, the first node generates n secret shares, keeps one secret share for itself, and provides the other n-1 secret shares to the other n-1 nodes respectively;

[0254] In S720, the first node generates public verification parameters corresponding to its own secret share and broadcasts them through an on-chain contract.

[0255] In S730, the first node receives the secret share generated by other nodes and receives the corresponding public verification parameters through on-chain contract broadcast.

[0256] In S740, the first common node verifies each received secret share and its corresponding public verification parameters;

[0257] In S750, after each verification is successful, the first node records the node number that has passed the verification.

[0258] In S760, when the first node meets the preset rules, it sends the set of recorded verified node numbers to the contract, so that the contract can determine the node set based on the node numbers sent by each consensus node.

[0259] In S770, the first node calculates the public key share based on the verification parameters and the node set, and calculates its own corresponding private key share based on the secret share and the node set.

[0260] The first node can also calculate the total public key based on the verification parameters and the node set.

[0261] The first node receives the secret share generated by the other nodes through a P2P network component.

[0262] The first node also performs signature verification on the secret shares generated by other nodes.

[0263] The first node receives the corresponding public verification parameters via on-chain contract broadcast, including:

[0264] The first node receives public verification parameters through the blockchain's event listening mechanism.

[0265] Figure 8 This is an architecture diagram of a blockchain node in a blockchain system according to an embodiment of this specification, including:

[0266] Generation unit 81 is used to generate n secret shares, retain one secret share for itself, and provide the other n-1 secret shares to the other n-1 nodes respectively; it generates public verification parameters corresponding to its own secret share and broadcasts them through on-chain contract;

[0267] The receiving unit 82 is used to receive secret shares generated by other nodes and to receive public verification parameters corresponding to the secret shares through on-chain contract broadcast.

[0268] Verification unit 83 is used to verify each received secret share and the corresponding public verification parameters;

[0269] Recording unit 84 is used to record the node number that has passed verification after each verification is passed;

[0270] When the preset rules are met, the sending unit 85 sends the set of recorded verified node numbers to the contract, so that the contract can determine the node set based on the node numbers sent by each consensus node.

[0271] The calculation unit 86 is used to calculate the public key share based on the verification parameters and the node set, and to calculate its own private key share based on the local secret share and the node set.

[0272] This specification also provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform actions such as... Figure 6 or Figure 7 The method shown.

[0273] This specification also provides a blockchain node, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements... Figure 6 or Figure 7 The method shown.

[0274] The above-mentioned solution provided in this application, based on the consensus mechanism to ensure the overall consistency and synchronization of the blockchain network, combines blockchain smart contracts to realize distributed key generation. This ensures that the generation of distributed keys is achieved by the cooperation of various participants, and that the generated results are consistent and reliable. This eliminates the strong dependence on network synchronization for distributed key generation outside the original blockchain and solves the problem of unreliability of the generated results in this case.

[0275] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0276] The controller can be implemented in any suitable manner. For example, it 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 Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0278] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0279] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0280] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations 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, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0281] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0282] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0284] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0285] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0286] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. 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, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0287] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0288] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0289] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A method for implementing distributed key generation on a blockchain, comprising: Each node generates n secret shares, keeps one secret share for itself, and provides the other n-1 secret shares to the other n-1 nodes respectively; Each node generates public verification parameters corresponding to its own secret share and broadcasts them through an on-chain contract. Each node verifies each received secret share and its corresponding public verification parameters; After each node passes verification, the node number that passed verification is recorded. When each node meets the preset rules, it sends the set of recorded verified node numbers to the contract through a transaction, so that the contract can determine the node set based on the node numbers sent by each consensus node. Each node calculates its public key share based on the verification parameters and the set of nodes, and calculates its own private key share based on its local secret share and the set of nodes. The preset rules include at least one of the following rules: The number of verified node IDs recorded for the node has reached n-1; The node has not received any secret share from other nodes in k consecutive blocks.

2. The method as described in claim 1, wherein the node is a consensus node, and the n private key shares and corresponding public verification parameters generated by the node include n values ​​generated by the same t-degree polynomial for constructing a random elliptic curve as n private key shares, and public verification parameters obtained by exponentiation of the coefficient terms of the polynomial; wherein t is (quorum-1), and quorum is the quorum majority in the consensus algorithm.

3. The method of claim 1 or 2, the providing, by each node, the other n-1 shares of the secret to its other n-1 nodes, respectively, comprising: Each node generates a first transaction, which invokes the contract and includes the ciphertext of n-1 secret shares out of the n secret shares it generates. The ciphertext of the n-1 secret shares is generated by encrypting them separately using the public keys of the other n-1 nodes. The first transaction is then sent to the blockchain to provide the other n-1 secret shares to the other n-1 nodes respectively.

4. The method as described in claim 1 or 2, wherein each node provides the n-1 secret shares to the other n-1 nodes, including sending them using a P2P network component.

5. The method as described in claim 1 or 2, wherein each node provides the n-1 secret shares to the other n-1 nodes, comprising: Each node signs the n-1 secret shares and sends them to the other n-1 nodes.

6. The method as described in claim 1 or 2, wherein broadcasting public verification parameters via on-chain contract includes: Broadcast public verification parameters are achieved through the event mechanism of blockchain.

7. As described in claim 1 or 2, each node further calculates the total public key based on the verification parameters and the node set.

8. The method of claim 2, wherein the contract determines the set of nodes based on the node numbers sent by the nodes comprises: When the contract receives the number of the first node from at least t nodes, it adds the number of the first node to the node set. ​ 9. The method of claim 8, wherein the contract further comprises: determining the set of nodes based on the node numbers sent by the nodes. When the contract determines that the set of nodes includes at least t+1 node numbers, it stores end information in the blockchain to instruct each node to calculate the public key share and private key share.

10. A method for implementing distributed key generation on a blockchain, executed by nodes in the blockchain, comprising: Generate n secret shares, keep one secret share for yourself, and provide the other n-1 secret shares to the other n-1 nodes respectively; Generate public verification parameters corresponding to its own secret share and broadcast them through an on-chain contract; Receive secret shares generated by other nodes and broadcast the public verification parameters corresponding to those secret shares via on-chain contract; Verify each received secret share and its corresponding public verification parameters; After each verification is successful, record the node number that passed the verification; When the preset rules are met, the set of recorded verified node numbers is sent to the contract in a single transaction, so that the contract can determine the node set based on the node numbers sent by each consensus node. The public key share is calculated based on the verification parameters and the set of nodes, and the private key share corresponding to itself is calculated based on the local secret share and the set of nodes. The preset rules include at least one of the following rules: The number of verified node IDs recorded for the node has reached n-1; The node has not received any secret share from other nodes in k consecutive blocks.

11. The method of claim 10, wherein receiving the corresponding public verification parameters via on-chain contract broadcast includes: Receive public verification parameters through the blockchain's event listening mechanism.

12. A blockchain system comprising a plurality of nodes, wherein: Each node generates n secret shares, keeps one secret share for itself, and provides the other n-1 secret shares to the other n-1 nodes respectively; Each node is used to generate public verification parameters corresponding to its own secret share and broadcast them through an on-chain contract; Each node is used to verify each received secret share and its corresponding public verification parameters; Each node is used to record the node number that has passed verification after each verification is successful; Each node is used to send a set of recorded verified node numbers to the contract in a transaction when a preset rule is met, so that the contract can determine the node set based on the node numbers sent by each consensus node. Each node is used to calculate its own public key share based on the verification parameters and the set of nodes, and to calculate its own private key share based on its local secret share and the set of nodes. The preset rules include at least one of the following rules: The number of verified node IDs recorded for the node has reached n-1; The node has not received any secret share from other nodes in k consecutive blocks.

13. A node in a blockchain system, comprising: The generation unit is used to generate n secret shares, retain one secret share for itself, and provide the other n-1 secret shares to the other n-1 nodes respectively; it generates the public verification parameters corresponding to its own secret share and broadcasts them through the on-chain contract; The receiving unit is used to receive secret shares generated by other nodes and to receive public verification parameters corresponding to the secret shares through on-chain contract broadcast. The verification unit is used to verify each received secret share and its corresponding public verification parameters; The recording unit is used to record the node number that has passed the verification after each verification is passed; When the preset rules are met, the sending unit sends the set of recorded verified node numbers to the contract in a single transaction, so that the contract can determine the node set based on the node numbers sent by each consensus node. The calculation unit is used to calculate the public key share based on the verification parameters and the node set, and to calculate its own private key share based on the local secret share and the node set. The preset rules include at least one of the following rules: The number of verified node IDs recorded for the node has reached n-1; The node has not received any secret share from other nodes in k consecutive blocks.

14. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of claim 10 or 11.

15. A blockchain node comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of claim 10 or 11.

Images